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 ... 70 71 [72] 73 74 ... 85
Uml Process / Re: Direction in operation parameters
« on: November 04, 2015, 11:27:07 pm »
Hi Phil,

From what I can read in UML 2.5, 9.4.4 Notation, you are indeed correct.
A Parameter is shown as a text string of the form:
<parameter> ::= [<direction>] <parameter-name> ’:’ <type-expression> [’[’<multiplicity-range>’]’]
          [’=’ <default>] [’{’ <parm-property> [’,’ <parm-property>]* ’}’] where:
    · <direction> ::= ’in’ | ’out’ | ’inout’ (defaults to ’in’ if omitted).
    · <parameter-name> is the name of the Parameter.
I don't think the C-flavoured '*' notation can be derived from that; 'in', 'out' and 'inout' are literals which in this clause may be omitted, but not augmented or replaced.

Mind you, the sales blurb for EA doesn't say "UML 2.5 compliant", it says "Based on UML 2.5 - plus", which means about as much as it does in Hollywood's "Based on a true story."

Certainly the star notation takes up less space in diagrams, but you can't really make that argument without the corollary "and anyway the standard is only a recommendation."

A shave and a haircut, my good man.


Uml Process / Re: How to link requirements to process flow
« on: August 17, 2015, 11:04:29 pm »

Regarding new/existing, all elements (but not connectors) have a "Status" property, which can be searched for, reported on in documents, and used in diagram filters. Depending on how you pull information out of EA, the diagram filters may cover your needs.

The status can also be displayed directly in diagrams, but this really only works for requirement-style elements; for others the status is displayed in the element shadow on the diagram which is very hard to see.

The set of available statuses (Proposed, Implemented, etc) can also be modified as required. For more details, check the help file under Modeling Basics -- Reference Data -- General Types -- Status Types.

You can of course simply change the colour manually, but unless your model is minimal and will be thrown away, this isn't a good idea. The colour of a UML element is not intended to carry information, so EA does not treat it as a fundamental property of the element, which means you can't test for it in document generation etc.

The best alternative is to define your own stereotypes and write shape scripts which change the colour based on the status or on a tagged value you define, as qwerty suggests.

This is more work, but worth it if you're in a medium-to-large scale project.



Uml Process / Re: Three types of UCase?
« on: February 27, 2015, 07:50:06 pm »
To my knowledge, these aren't use case types that EA knows anything about. Try using stereotypes.


Uml Process / Re: Workflow question:  UseCases from Documents -
« on: February 04, 2015, 02:33:34 am »

It all depends.

If the Word documents are well structured you can write a script or two, either in Word or in EA, to import the Word contents. This would be one-way.

You can copy the contents of the documents into document artifacts in EA. That way you can at least trace to the documents.

You can drag-and-drop text from Word into EA, and create elements of a type appropriate to the diagram (so create a use case or requirement diagram first). Works out of the box, simple, manual, repetitive, boring, one-way.

If you've got tables in Word you can massage them in Excel and import them into EA using CSV Import. This can be used both ways; once the use cases have been re-exported from EA they've got GUIDs and subsequent re-imports will update them.

The left side / right side thing is kind of achievable using EA's specification manager, which shows you a document-style layout of a hierarchy of (requirement) elements.

As for linking into external documents, provided there are viable link targets in the documents you can create hyperlinks in diagrams as well as "file" links in elements.

You should also check out an add-on product called eaDocX, which may be of use here. I'm not affiliated but I know some of the eaDocX people are on this forum too.

Over to you, Phil. :)



Uml Process / Re: Why Association without arrowhead?
« on: February 02, 2015, 07:55:30 pm »
Also, the UML standard includes both undirected and directed associations so it's not an EA thing as such. Only the default behaviour is EA-specific and, as noted, that can be changed in the options.


Uml Process / Re: how can I add operator to Actor
« on: February 02, 2015, 07:52:19 pm »
If you go to the properties window (not the properties dialog) you can change the type to Class, add attributes and operations, and change it back when you're done. EA (11 at least) will display the attributes and operations in the diagrams.

As noted, while this approach will work it clearly is not intended use. Tagged values might be a better fit.


Uml Process / Re: files and package organization
« on: July 03, 2014, 07:09:30 pm »
I usually recommend structuring a project by content type, which often-but-not-always coincides with the teams on a development project. Structuring by diagram type is to me just nonsense, the equivalent of dividing a Word document into chapters based on which font is used.

So there'd be a root node each for
- Business analysis
- Requirements analysis
- High-level design
- Detailed design
- Implementation
- Deployment
- Testing

In general, any connectors between these main branches are traces and realizations from lower-down branches to higher-up ones.

The structure within each branch would also follow the same dependency rules, so the structure within your detailed design package would depend on the result you've arrived at in your high-level design.



Uml Process / Packaging Components vs UML
« on: March 31, 2009, 06:25:44 am »
Hi there!

The new Packaging Components in 7.5 solve a number of problems for me, particularly relating to CM - a pedestrian subject of which the lofty ideals of the UML specification remain serenely aloof.

However, I would like to be able to counter the arguments from the UML purists (of which I am one, as it happens). So how does the Packaging Component relate to the UML elements? Specifically, how does it relate to Package and Component? Which characteristics does it take from which?



Uml Process / Component interface realization / usage lollipops
« on: February 09, 2009, 06:39:15 pm »

In 7.1, if you drew a Realization from a Component to an Interface, the Interface would also appear on the Component as a (non-selectable) "provided" lollipop. However, a <<use>> from a Component to an Interface would not result in a "required" lollipop.

I was hoping to see this in 7.5, but instead the automatic "provided" lollipop has been removed.

Can anyone straighten this out for me? Is there a way to get auto-lollipops in 7.5 (or auto-"required"-lollipops in 7.1)?



Uml Process / Re: Code Generation and Associations
« on: April 22, 2008, 09:24:53 pm »

Yes, it's all understandable, except the big one - why? ;)

The macros to find the source and destination classes of a connector are there. All %class*% macros are available in the %connectorSource(Dest)Elem*% macros.

So if you're after the source class name you use %connectorSourceElemName%, if you want the destination class full name it's %connectorDestElemQualName%.

Inside your Connector template you're still (also) in a Class context, so %className% is valid. Which means you can check f'rinstance
%if className == connectorSourceElemName%
which will make sure the rest of the template is only executed at the source end of a connector.

However, I'm pretty sure (though I haven't tested this) that you're never in an Attribute context when in a Connector template. But UML-wise I'm not sure that having connectors with the same role names as attributes is a Great Idea[size=8]TM[/size] anyway.
There is no conceptual difference between an attribute and an association, so having both in the same class is the same as having two identically-named attributes - probably not what you want.
The association is a more explicit notation and also has more power in the CTF so I'd go with that.


Uml Process / Re: Code Generation and Associations
« on: April 21, 2008, 08:22:49 pm »
Hi again Leene,

You're in luck - there is.


... by which I mean to say this feature is not, strictly speaking, documented.

You can pass parameters between templates using the special variables $parameter1, $parameter2, etc in the called template. In the calling template you use a standard comma-separated ()-enclosed list of arguments. These can be values or macro references as in %myTemplate("someString", className)% (assuming you're calling from a Class template where %className% is meaningful).

This works well for single-call situations, but I haven't been able to pass a parameter into the %list% macro.
However, I'm not sure what it is you're trying to do. When you say your connectors reference a special class-attribute, what do you mean? Since connectors are between classes, I don't quite see what's going on.
Unless you mean the source or destination roles, which are available as macros.


Uml Process / Re: Code Generation and Associations
« on: April 18, 2008, 05:54:25 pm »
Hi Leene,

I believe you're after the Connectors. An association is, as far as the CTF is concerned, a connector of type Association.

You can add code templates of type Connector, and within a template you can use the connector* macros (eg. connectorName, connectorType, connectorStereotype).

Hope this helps,


Uml Process / Re: Class Diagram HELP!
« on: April 06, 2008, 09:29:04 pm »
Hey there,

Are you sure this isn't an assignment from OOD 101? It certainly reads like one. If it is, this is a forum for professional software engineers using a specific tool and you really should be doing your own homework.  ;)

If not, I think you're attacking the problem from the wrong angle. If you're discussing terms like employees, pay and leave requests, you're looking at business process modelling, not class modelling.
There's quite a few steps between analysing the problem domain and designing the implementation-level entities, and the set of classes you eventually end up with bear little resemblance to the real-world (domain) entities.


Uml Process / Re: Profiles Multiple Values for taggedValue
« on: October 17, 2007, 08:10:10 pm »
Hi there,

There's nothing stopping you from creating multiple taggedValue connectors with different names from one stereotype to another.

Another way is to create the tags as Attributes in the Stereotype and not use the taggedValue connector. If you need a large number of same-type tags, this might be preferable from the visual perspective.

The ordering of tags, though, cannot be enforced AFAIK.

However, since you say the tags must be ordered I'm assuming you'll be wanting to generate code out of this (since ordering of attributes within a class carries no meaning in UML).
And in your code generation template, you are free to do things in any order you like.

Hope this helps,


Hi John,

Could be a JavaScript issue possibly?
The generated HTML contains a truckload of JavaScript.


Pages: 1 ... 70 71 [72] 73 74 ... 85