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 ... 56 57 [58] 59 60 ... 85
General Board / Re: Redesign classes - best practicies
« on: October 07, 2015, 11:50:16 pm »
Hi again,

1) Yes, it's possible. You just need to "link to element feature" twice, once at either end of the connector.

2) No, it finds attribute and operation changes as well, but only added / deleted. Changed type etc doesn't show up (although operation parameter types are shown).


General Board / Re: Redesign classes - best practicies
« on: October 06, 2015, 07:30:17 pm »
Hi Michel,

First off, Geert is right in saying that maintaining two versions of the same model in the same project is essentially impossible. EA is not built that way.

If you only want to see differences between old and new, baselines work well -- but only if you will never be making any changes to the old version. With baselines, the old versions are stored in XML format, not as regular models, so they're essentially frozen in carbonite. You can compare the current model to a baseline, but you can't change what's been baselined.

If you want to actively maintain two different versions, work in two projects instead. If you want to see differences between versions in different projects, again baselines work (you can move baselines between projects), but you have to set the structure up to support this before you begin modelling (GUIDs for the baselined elements must be the same in the two projects in order for EA to compare them).

1) is there a way to mark attributes / operations ?
A simple way is to set a stereotype "new" / "old" / "deleted". Note that EA will by default sort attributes/operations first in order of stereotype. You can change this behavior in the options.

(Of course, keeping "deleted" attributes in the model means you can't do things like code generation from the model without modifying the code generation templates, but I'm assuming you're not doing that.)

If you create your own UML profile, you can write a shape script which displays the attributes/operations differently depending on tagged values. I don't think you can set text colours, but you could get something like
Code: [Select]
+ [N] myAttr: Integer
+ [O] myOtherAttr: Boolean
But I wouldn't recommend this for a small model or if you're new to MDG Technologies; classes are complex beasts and overriding their default shape script isn't easy.

2) The question: " Is it possible to create relationships on the attribute / operation level That means to bind the corresponding attributes ?" meet other modeling techniques (e.g. bind some attributes between two whole different classes)
Yes, by using the "link to element feature" function (right-click the connector near the class where you want the connector to tie to a particular attribute/operation).

Note that this is an EA-specific feature not supported by UML. Thus the attributes and operations themselves cannot have relationships; EA just displays them in the diagrams in a way that makes it look as if they do.

In addition to all that, EA has a function called Gap Analysis Matrix. This works on two parallel model structures and identifies / records gaps, ie differences between them. It might be worth a look in your case.



General Board / Re: custom tagged values for stereotype "table"
« on: October 06, 2015, 10:12:48 pm »
Hi Petr,

If you create your own UML profile you can extend existing stereotypes. When you specify the metaclass to extend, the metaclass selection dialog has a tab "Stereotypes" where you can select an installed profile (EAUML in this case) and then a stereotype to extend (table and column).

This should allow you to add tagged values to tables and columns, while still allowing EA to recognize them as its own. I haven't tried it myself, but it should work.


General Board / Re: Importing Rules (Requirements) into a Class
« on: October 01, 2015, 05:31:37 pm »
Hi ssands,

Internal requirements look similar to external ones (ie the ones that are proper elements), but they are in fact very different inside EA.

As I'm sure you know, you can turn an internal requirement into an external one (which creates a Requirement element), but it's a one-way street -- you can't turn an external requirement into an internal one. External requirements are proper elements and as such have far more information associated with them than a simple internal requirement, which only contains what you see in the properties dialog.

So no, there's no built-in function to import internal requirements, and there's no out-of-the-box solution to import them as external requirements and then move them to internal ones.

If you only have a small number of requirements, what you can do is drag-and-drop them from the document into the properties dialog of the class.

For some reason, the Requirement text field does not allow you to drop text into it (EA 11.1), but the Notes field does. So you can drop the requirement name there and then cut-and-paste it to the Requirement field.

Not a truckload of fun, I agree, but if it's only a couple dozen requirements and if it's only a one-off thing it shouldn't be too bad.



General Board / Re: Element location of element when copied to dia
« on: September 17, 2015, 08:55:03 pm »
Now THAT's good to know!  Thanks Simon!

What's not so good is that the keyboard shortcut doesn't work the same way as the menu item.

I view this as a bug.  >:( What do others think?

I don't actually. Pasting works differently with keyboard and mouse in Word too. The difference is that there's no cursor in a diagram.

With text editors (I mean in general now, ie Word, Notepad etc) there are two cursors involved, the text cursor and the mouse cursor. So when you just press Ctrl-V the text is pasted into the current location of the text cursor. When you right-click and select paste the mouse cursor location is used.

However, there is no "diagram cursor". So the choice that's been made is to copy the location from the old diagram on Ctrl-V, rather than use the mouse cursor location.

There are other options: always paste into a default location, or disallow Ctrl-V altogether because it can't work as it does in Word.

I'm fine with the choice that's been made, you and others may not be, but I wouldn't consider it a bug.


General Board / Re: Element location of element when copied to dia
« on: September 16, 2015, 11:50:44 pm »
You should also note that if you've moved the element in the original diagram and haven't saved it, the element will be placed in the last saved location, not the current one, in the new diagram.

So save the original diagram before you copy things out of it.


General Board / Re: Element location of element when copied to dia
« on: September 16, 2015, 11:36:22 pm »
Hi Stephan,

EA places the pasted element in the same location it had in the old diagram (with some small offset). Zoom and pan are not taken into consideration, so if you're in different pan/zoom in the two diagrams, you often find the pasted element is outside the visible part of the diagram.

I am not aware of any settings or options that affect this.



General Board / Re: Report on all interfaces
« on: August 12, 2015, 09:09:10 pm »
Hi Ernosh and welcome to the forum,

Document template design is a bit of a dark art, but in most cases you can get reasonable-looking documents out of most models.

I'm a bit confused about your model though. Could you clarify how interface, type, source and target are represented in your model please?



General Board / Re: Colouring Lines
« on: August 26, 2015, 06:06:39 pm »
Going back over your OP I see you actually mentioned MDG Technologies there. That's EA's way of packaging adaptations such as UML profiles, so you're already in the right place.

For specifics on shape scripts, refer to the Help file under Extending UML Models -- MDG Technology SDK -- Shape Scripts.


General Board / Re: Colouring Lines
« on: August 26, 2015, 06:02:14 pm »
Although we will seperate these into smaller related packages soon...I wanted to see if we could colour code the links so e.g. Associations were Blue, Trace were Red etc to be able to see at a glance what type of relationship they were.

I wanted to apply this across the Prioject as Standard

Does that make sense?  :)
Hi Guy,

Well, it does and it doesn't.

Telling an association apart from a trace is already simple -- associations are solid lines, and traces are dashed. Realization, another common relationship in requirement models, is also dashed but has a triangular arrow head instead of the open, plain V shape of trace and (directed) association.

So if that's all you're after, the colour won't add any information. Fundamentally, colour is not an information carrier in UML. The entire standard works in monochrome.

That said, there's nothing keeping you from adding colour to denote certain things in your own models. What triggered this response is really the last thing you said, about wanting to apply this colour-coding as a standard.

If you want that, you probably want any new or changed connectors to display the right colour automatically. The way to do that in EA is to create a UML profile where you define your own stereotypes for your connectors. In those stereotypes you specify the appearance of the connector, including its colour, by writing a shape script. You may also wish to create your own custom diagram type (with related toolbox pages) to facilitate creating these new connectors.

If you write an in-EA script, you have to run it manually every time you change something. For anything but a trivial model, this is unmanageable. Going the stereotype-and-shape-script route means EA runs the shape script for you whenever necessary (every refresh of the diagram).

Put another way, creating a profile is the proper UML way of doing it. If you want to create UML models, rather than draw pictures, that's the way to go.



General Board / Re: Exporting a model to HTML
« on: August 19, 2015, 01:36:12 am »
Hello and welcome to the forum.

First up, if you want an HTML export which is very different from what EA delivers, I think you're going to have to write your own. But I think what you describe can be achieved based on EA's built-in HTML generator.

I don't think XMI is the way forward. XMI is an OMG-standardized format, but large bits are outside the scope of the standard, and that includes the exact representation of the images. So EA's XMI image format, like every other modelling tool's, is proprietary and undocumented. Furthermore, I'm pretty sure that the image in the XMI format is just a bitmap with no reference to the elements it contains, so I don't think you could get a useful HTML page (with clickable elements) from an XMI file.

With EA's HTML exports you can modify the content that gets exported, but the fundamental structure is hard-coded in EA (and also undocumented). You can't change the file naming scheme, for instance. The actual clickability in the images is managed by a lot of JavaScript. You can modify this too if you like, but I don't think that'll get you very far either.

I think your best bet is to have EA generate the HTML, and then write your own set of pages which reference EA's and translate between your structure and EA's. Using the class name for a file name won't work though, because in EA having several classes of the same name in the same package is perfectly legal. In a file system, it is not.

The EA-generated HTML does contain a file per element. The reason the address bar doesn't change is that it is displayed in a separate frame, but if you check the frame properties you can see what file is being displayed in it. It will be something like ....../EARoot/EA1/EA7/EA105.html.

If you look into the EA-generated file structure, there's a top-level directory js/data full of XML files. You can use these to obtain translations between the names of the HTML files EA has generated and the names and GUIDs of the elements they contain.



General Board / Re: Plural for glossary terms
« on: August 18, 2015, 06:49:15 pm »
, the cost/benefit ratio is simply far too high.
No. As I said the current highlighting is not done via a semantic analysis but by simple string comparison. So just add the "s follows string" rule to underline also the "s". Simple as that. Works in more than 90% of all cases I'd say at almost no cost.


1) 90% - citation please.
2) You're assuming that 90% correctness is acceptable to most users. This is not usually the case when dealing with language issues.
3) The glossary is user-defined. You're not guaranteed that the terms are in English, and there's no way to specify which language it's in.
4) "Almost no cost" - weasel word. Unless you've actually worked on EA development, I don't think "how hard can it be" is an acceptable argument.


General Board / Re: Plural for glossary terms
« on: August 18, 2015, 06:16:09 pm »
Indeed, but the design of the glossary is sub-optimal...  

It should have the base term (singular) plus fields for the plural and singural (a concept I have created - "cow(s)" is the singural form of cow, encompassing both the singular and plural forms).  The glossary can then be populated however you like (we use our Onto-Terminological Model (OTM) to define the terms and concepts).  But the highlighter can use all three forms to highlight the right word and provide the definition as the tooltip.

Our Onto-Terminological Model holds the three spelling against each term and the concept provides the definition.  We automatically maintain the glossary - unfortunately 3 entries per term from our OTM as our OTM is updated.  This also allows us to define compound terms correctly:  Sergeant at Arms, Sergeants at arms, Sergeant(s) at Arms.

This actually sounds very interesting. Not because I have a customer asking for it, but simply out of personal interest.

Is this proprietary or something you could communityize? communify? communalize? release?


General Board / Re: Plural for glossary terms
« on: August 18, 2015, 06:11:20 pm »
And even more uncommon is pluralization of verbs ;D
I am sorry, but we are not in agreement. ;)

But seriously, while this would be a cool feature, the cost/benefit ratio is simply far too high. The glossary is, ultimately, a minor EA feature and it would be very hard to get a function like this up to an acceptable standard.


General Board / Re: Traceability/Relationship Diagrams
« on: August 12, 2015, 10:22:43 pm »

What you're talking about there is what I usually refer to as "inferred relationships", and UML (and thus EA) doesn't deal well with those -- you have to follow the links step by step.

Keeping track of that in a diagram, even a self-updating one, is indeed tedious and very quickly becomes unmanageable for anything but trivial sets of requirements (ie dozens rather than the thousands you get in any decent-sized project).

I'd write a browser script which follows the branching connectors backwards from the selected element and stops when it hits something that isn't a requirement. The exact details would of course depend on what connectors you use, but it shouldn't be hard to do.

You could also create a document template to generate full requirements tracing reports on your model.



Pages: 1 ... 56 57 [58] 59 60 ... 85