Messages

1

General Board / Re: Importing XMI from Altona UModel

« on: November 06, 2006, 07:55:46 am »

I think its probably fairer to say that the ability to reimport exported xmi is a highly desirable (i.e. effectively necessary) but not sufficient indicator of good xmi interchange.  EA certainly has this ability.

However in any xmi interchange there are two parties, and both must agree before interchange can happen.  If interchange doesn't happen you don't know from just this fact which end is at fault.  Is the following statement true: "I claim I can speak French well, and I certainly understand myself, therefore if I speak French to someone who claims to understand French and they don't understand it, it is their fault.  Also if someone speaks what they claim is French to me and I don't understand it, it must be their fault."?

Have you tried any/all variations in XMI format that UModel can export?  EA generates "windows-1252" encoding in its generated XMI (in the very first line of the xmi file), it might be worth checking that UModel generates the same?  If its encoding is different, try editing the xmi file in a text editor (notepad?) to read windows-1252.  You could always look at a xmi file generated by EA for an example of this.

On a more cheerful note, why don't we start a mynorca (acronym backwards) competition on XMI: I reckon it stands for eXtremely Minimal Interchange  

HTH
Barny

2

General Board / Any success with EA XMI export into any othertool?

« on: October 17, 2006, 02:00:50 pm »

Hi

I'm doing a job at the moment which involves taking EA's XMI (preferably 2.1) output and importing it into another tool.  I'm struggling.

Has anyone had any success at all with any version of XMI exported from EA, importing to any other UML tool?

TIA
barny

3

General Board / Re: Big proj. + Src Ctrl (Pb w/ export XMI)

« on: July 27, 2004, 03:49:14 am »

I'm not sure if replicas are the 'only' way to split for large projects, but we used them on a 20-user project and they are a bit hairy.

Replicas don't actually split a project, they replicate the whole master model (database) file into a replica model (database) file; users can seperately edit their own copy of the replica, then send it back to a central administrator for merging into the master.  Anything deleted/modified/added in the replica is deleted/modified/added in the master when the replica is merged in.  We used replicas because the a) the company does not have IT infrastructure/willpower to have a server for its global users(!) and b) many users needed to do offline editing, e.g. while travelling.

EA replicas are based entirely on Microsoft Access database replication, so the basic technology works, but EA could provide a better layer of model management on top of it.

Some of the difficulties we had (on EA 3.60) :

1. If you don't use locks, anyone can change anything in any replica, and their changes, wanted or not, get merged back into the master.  You have to keep an eagle eye out for 'helpful' users who thought the replica file was too large so they deleted everyone else's packages and compacted the file to make it smaller so they could send it by email!

2. If you use locks, the locks only work for a single named user; you can't allow more than one username to access one part of a model.  We ended up letting several people use the same username when we used locks.

2a. If you use locks extensively, when the administrator needs to make model changes as he manages merging, he has to undo and redo locks on any packages he needs to tweak.  This is a *real* pain.

3. As successive replicas get merged, EA (Access actually) decides what happens if the same element got changed two different ways in two different replicas.  It does claim to give you a list of 'conflicts' which might help you spot where this happens, but I was never convinced about this enough to trust it.  We had to try to manually enforce single-user editing of each package, which wasn;t always successful!

4. One replica got corrupted when the users' laptop crashed while he was using EA.  He didn't realise it was corrupt, and it got merged into the master.  The master had the same corruption for a while until we realised.  Managed to recover by exporting the affected package to XMI, deleting it and re-importing, but I felt very lucky when this worked.  EA does have model consistency checking, but it doesn't give much more than 'element 101232342 corrupt' level of error message, and won't let you fix individual problems it finds.  I raised this to support at the time, don't know if it has been improved.

We ended up with a tightly run process for managing replicas, which involved keeping a copy of every master model and of every replica which we merged into it, so that at any point we could roll-back if needed.

My own conclusion is that EA is very good for the price, but it is really a single user product which is being stre-e-e-e-etched to fit a largely multi-user market.  Replicas should be used with extreme care, and you may well still have problems! EA+Replicas is a poor substitute for a proper multi-user repository UML environment with proper access control.  You may save money on the tools only to spend more on administration, management, hassle and hair-replacement.

What is the value of your model after 20 users have spent 6 months working on it? 20 users @ $50/hour (=$400/day=$2000/week=$8000/month=$48k/6months)= $1m!  Now, spending $100k on tools looks cheap; think of it as insurance.  It would mean that it is much less likely that one laptop crash or a dozy user could corrupt your $1m investment.

Sorry, this seems to have turned into rant.  Its just that replicas made me very nervous.  We did get them to work for us, but it felt very seat-of-the-pants stuff.

Oh, and we never even thought about doing version control, that looks like another 'interesting' area of EA's feature-set.  Doesn't look very scalable to me.

HTH
Barny

4

General Board / Re: Export Tag Values and Links to CSV

« on: July 09, 2004, 01:35:44 am »

I don't think you can export relationships in CSV; you will have to use the automation interface, which could also export the tags.

HTH
Ian

5

Uml Process / Re: UML "port" sense

« on: June 11, 2004, 09:05:53 am »

The EA help does a pretty good job of defining what a port is, but then doesn't give a very helpful example.

Ports have their roots in ROOM (a predecessor of UML from the early/mid 90s, only implemented in IBM Rational Rose RealTime AFAIK), and in ITU Z.100 SDL gates, from the early 80s.

For me, port makes most sense when used on a composite element; they represent (the only) communication points for that assembly with the outside world.  A composite element can be assembled into another composite element (as a part), which is the same thing as saying that a composite element may itself be an assembly of other composite elements (as parts).

Ports realise interface class(es), which specify and constrain communication through the port.  Putting a required interface (socket symbol) on a port specifies communication out of the port to the environment, realised (lollipop symbol) specifies communication into the port from the environment.

In principle a composite element is then fully defined in isolation from the environment, something you couldn't do in UML 1.x, because 1.x didn't have the concept of 'required' interface, you ended up modelling a required interface as an association with an abstract class, then using inheritance from that class when you realised this in code.  Same effect in the end, I suppose, but fairly opaque.

In other words, along with composite elements, ports allow you to model hierarchical decomposition of a complex system into subsystems, subsubsystems, etc, communicating through well-defined interfaces.  Voila, Architecture in UML!

The bottom line for most people is how this turns into code.  The short answer is, it doesn't AFAIK unless you use Telelogic UML 2.0 tools where they have full code-generation, i.e. into a framework which understands ports and architecture.  I guess this is what Rose Realtime did from ROOM+UML 1.x.  It certainly doesn't map onto vanilla C++.  I don't know how EA generates it (if it does at all).  Anyone help?

HTH
Ian

6

Automation Interface, Add-Ins and Tools / Re: Thoughts on add-in to visually compare models

« on: November 02, 2006, 06:43:38 am »

Sorry for not replying earlier, been on holiday  

In Rhapsody 7.0 (and in earlier versions I believe), there's a DiffMerge entry in the Rhapsody installation, i.e. under Start->All Programs->Rhapsody 7.0->DiffMerge.

This does 2-way or base-aware (3-way) compare/merge of the model and of the diagrams.  You can set it to ignore layout differences, e.g. where a symbol has been moved.

Comparing the model means showing all added/deleted/changed things, whether elements, connectors, issues, risks, requirements, etc., and attributes of all these things.

Looks like a complicated project you're taking on  

HTH
Barny

7

Automation Interface, Add-Ins and Tools / Re: Thoughts on add-in to visually compare models

« on: October 17, 2006, 12:48:29 pm »

Both Telelogic UML tools Tau and Rhapsody have full model visual compare and merge.  Tau has 3- and 4-way merge.

HTH
Barny

8

Automation Interface, Add-Ins and Tools / accessing details of a diagram hyperlink?

« on: November 02, 2006, 06:29:53 am »

Any idea how to get the target of a diagram hyperlink through the COM API?

They are Text elements, and the 'url' for the target diagram must be stored somewhere but I can't find it.  The Name and Alias can both be changed and the link still works, so it must be stored somewhere else.

barny

9

Automation Interface, Add-Ins and Tools / Note attached to connector?

« on: November 02, 2006, 06:25:00 am »

I'm trying to read a diagram using the AI, where the diagram includes a note attached to a composition relationship between two classes.

Scanning through the DiagramObjects, the Note symbol and its corresponding Element come across OK but I can't find out what it is linked to because there isn't a NoteLink for the line joining it to the composition.  For Notes attached to symbols, there is always a NoteLink.

This is sort of reflected in the GUI because I can't select the dashed line joining the note to the composition .

I've looked in CustomProperties of the composition and of the classes it joins, but I can't find anything relevant.

So, does anyone know how to determine the Connector the note is attached to?

TIA
Barny

10

Automation Interface, Add-Ins and Tools / Re: C# addin getting collection of requirments

« on: October 17, 2006, 10:40:43 pm »

This really confused me when I started using the AI, but once you use the right terminology it gets clearer.

Internal requirements (e.g. those edited using the Require tab of the element proprty dialog) are stored as EA.Requirements, and are accessed through EA.Element.Requirements for the element they are part of.

External requirements (i.e. those which you can show as symbols on diagrams) are stored in the model as EA.Element and don't need casting to access the information.  The text of the requirement is held in EA.Element.Name.

Because External Requirements are just EA.Element, to find what External Requirements are related to an element you have to scan its EA.Element.Connectors for EA.Connector.Type=Dependency stereotyped <<trace>> (or whatever) and check the EA.Element at the other end of the connector (which is identified in either ClientID or SupplierID depending on the direction the relationship was drawn) to see if its EA.Element.Type is 'Requirement'.

Working from a diagram means you can start from the DiagramLinks, get the corresponding Connector, find the elements which are its Client and Supplier and check their Type.

Don't forget that in general all the connectors for an element won't appear on any particular diagram - and need not appear in *any* diagram - so if you want to "check the Requirement relationships" in the model you probably need to check the whole model rather than just the diagrams.

/Barny

11

Automation Interface, Add-Ins and Tools / Re: Requirments Management Tool

« on: November 02, 2004, 04:32:34 am »

IMO EA is cheap and effective as a requirements modelling tool, i.e.  it does a good job of modelling individual requirements and their relationships to each other and to other parts of the model, but it falls far short as a requirements management tool.

Requirements management is about managing and controlling a body of requirements.  RM tools such as Telelogic DOORS (which is the global market leader) and DOORS/Analyst (which allows embedding UML 2.0 models with the requirements) automate all those manual, error-prone and tedious management activities such as:
* What is affected by requirement/s change?
* What higher-level requirements(s) is this requirement trying to satisfy?
* What is the change history of this/these requirement/s?
* Automatic generation of traceability matrices
etc.
* Detaching part of the requirements structure for remote updating
* What part of the documentation structure/requirements hierarchy has not yet been updated following a requirements change?
* How many requirements contain the word 'shall', how many 'should', how many 'may'?
* How many of my requirements have been complied with?

And of course many aspects of requirements simply cannot be captured using UML, particularly non-functional, performance, regulatory, contractual, etc. requirements.  Textual requirements, diagrams, tables, are all essential in any non-trivial project.

Smaller projects can get away with a lot (by using people instead of automation tools), but the larger the project the more important it becomes (because mistakes or omissions become more expensive) to use the right tool for the job; if you use a hammer (i.e. EA) when you need a screwdriver (i.e. a proper Requirements Management tool), the screw may well be driven home, but you are unlikely to be ever able to remove it for maintenance or to change the fixing.  To take the analogy to an extreme, if you have hammered a screw in, you may well have to go out and buy an electric drill to drill out the original screw to change it when time comes for maintenance.  This might not matter if it is only one screw, but if there are a hundred, or a thousand...

So, use EA for what it is good at (UML modelling, requirements modelling), but be aware that it is not designed for versioning of individual requirements and their relationships, for requirements management, for traceability and impact analysis,...

12

Automation Interface, Add-Ins and Tools / Re: Converting projects from EA to Rose and back

« on: July 28, 2004, 03:53:15 am »

Your only chance is XMI, but the time I tried it (not to Rose, though) it didn't work once (never mind repeatedly), although the problem might have been in the XMI export from EA or the XMI import at the other end.

Suggest you search all the forums (fora?) for XMI because there have been questions posted about this before.

HTH
Barny

13

Automation Interface, Add-Ins and Tools / Re: Does package element support stereotype ???

« on: June 11, 2004, 07:51:53 am »

I'm sure I've answered this one before...

every EA.Package object has an Element property which, like any other EA.Element, can have a stereotype.

So, the stereotype is on p.Element, specifically its in p.Element.Stereotype.

HTH
Ian

14

Automation Interface, Add-Ins and Tools / Re: Access to system tables from Addin

« on: June 01, 2004, 03:11:57 am »

If you RTM:

EA Help
 Automation and Scripting
   The Automation Interface
     Reference
       Repository
         Reference

you'll find that the AI lets you access the reference lists you mention, so you can future-proof your app to some extent.  Also, search for GetReferenceList()

Stereotypes are the mechanism in UML for making extensions, and you can use them in EA.  Most obvious limitation I have seen (in 3.6 anyway) is that only one stereotype can be applied to an element.

15

Automation Interface, Add-Ins and Tools / Re: Access to system tables from Addin

« on: May 20, 2004, 10:09:07 am »

I'm not sure why you'd want to; the diagrams and connectors are all accessible through the automation interface, and this interface is a) documented and b) won't change (much) as EA develops.