Messages

1

General Board / Auto counter for UML Profile stereotypes

« on: September 30, 2006, 12:36:27 am »

Following up on an earlier thread (http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=general;action=display;num=1093308726;start=) that describes a way to model business rules within EA using UML Profiles, I have created a basic profile with stereotype 'BusinessRule' that extends a class metaclass and has several tagged values that together describe the business rules.

Now I need to use the Auto Counter feature to automatically prefix a 'BR' with a number to each element I create off the UML Profile.

However, the drop down list of types shown in the 'Auto Element Naming' screen does not include my stereotype after I have imported the UML profile in my EA model.

What am I doing wrong?

2

General Board / Re: Creating shortcut to a model on a server

« on: July 16, 2006, 10:29:34 pm »

Open your SQL Repository in EA, then use "File -> Save Project As...".  This will prompt to save an EAP file which will behave as a shortcut to your SQL repository.  

HTH.

That worked. Thanks!

3

General Board / Creating shortcut to a model on a server

« on: July 15, 2006, 11:08:07 pm »

How can you create a shortcut to directly launch a model stored on an SQL Server database?

4

General Board / Need an argument in favor of EA over Visio

« on: June 13, 2006, 07:19:24 am »

Hi guys

I will soon conduct a demo on EA in my company for fellow developers and analysts. Since our company is Microsoft-oriented, everybody's just used to using Visio for all diagramming needs, including UML. So inevitablly I'm going to be asked to describe the advantages of EA over Visio and why is it worth the learning curve and licensing cost.

I know there are many things in which EA far exceeds Visio but I need to forumulate and articulate these things so they'll sound convincing and everything.

Any pointers?

Thanks!

5

General Board / Re: Annoying little quirk in EA

« on: June 06, 2006, 07:42:27 am »

You know, in terms of UI, I think EA has still has a way to go and could really benefit from two broad concepts:

1. Consistency in the design of the UI. For example, I have noticed that some dialogs employe keyboard accelerators (e.g., Alt+letter) for dialog elements while others don't for no apparent reason.

2. Sticking to the Windows UI design guidelines as much as possible for the Windows version of EA. These guidelines will most likely ensure a product that is so smooth to operate for users who will be using this product extensively (as in my case).

6

General Board / Annoying little quirk in EA

« on: June 06, 2006, 07:05:19 am »

Did anybody notice and was annoyed by this behaviour:

When you have any modal dialog open in EA (i.e., a dialog that you must dismiss before returning to the main EA screen), if you switch to another running application and then switch back to EA, only the dialog will show and the main EA interface will not show until you dismiss the dialog.

Try this behaviour in Word and you'll be able to switch back to Word from another application and still see both the modal dialog and the main application in the background.

Sometimes while having a modal dialog open (say UC properties) I need to switch to another application, do a little thing, and switch back to EA and still be able to see both the proeprties dialog and the main EA interface.

It's kinda trivial but still annoying.

7

Uml Process / Re: Assembly link versus interface dependency

« on: July 20, 2006, 12:29:54 am »

So, AL, I plead a slip of the mind....

FWIW, in my view, the dependency should be directed from the required to the provided interfaces.

Paolo

Well that puts me in a peace of mind. You know what, I'm just gonna stick with the tried-and-true interface dependency links, especially that I have all my interfaces figured out and everything.

8

Uml Process / Re: Assembly link versus interface dependency

« on: July 19, 2006, 11:09:04 pm »

And to make matters worse, the Payment interface isn't even provided.

9

Uml Process / Re: Assembly link versus interface dependency

« on: July 19, 2006, 11:05:33 pm »

Yeah I guess that makes kinda sense. Though refering back to the example above, how could AccountDetails interface have a dependency on a required interface (Payment)? This semantic isn't making sense to me  

Oh I'm sorry, did I say semantic? I really meant the syntax.

My confusion, referring back to the above diagram, is how could a provided interface depend on a required interface (in our case, the AccoundDetails interface depends on the Payment interface).

I always thought it should be the other way around.

10

Uml Process / Re: Assembly link versus interface dependency

« on: July 19, 2006, 07:42:09 am »

Hi AL,

FWIW, as I understand UML 2, when the names of the interfaces at both ends are the same, you can use the ball-and-socket form (because they are (both sides of) the same interface).

Where the names are different, you must use the more conventional dependency.  However, it's really just a rendering issue.  There's still a dependency between the ball and the socket, even in the ball-and-socket form.  You just can't see it!

Paolo

Yeah I guess that makes kinda sense. Though refering back to the example above, how could AccountDetails interface have a dependency on a required interface (Payment)? This semantic isn't making sense to me  

11

Uml Process / Assembly link versus interface dependency

« on: July 19, 2006, 07:08:46 am »

Hi

I'm at this stage of my project where I've defined my functional and user interfaces and I'm trying to develop a component diagram in order to package these interfaces.

Reading in Component Diagram article in the EA documentation, I've come across two notations for specifying interface dependencies between components. Check out the following diagram:

I'm having some sort of consfusion as to when should we use the assembly link (which is supposedly new in UML 2) versus the good old interface-to-interface dependency link (seen in the above diagram as the dotted link).

Could someone clarify the difference for me please?

12

Uml Process / Re: UML Profile: Self-tagging

« on: October 01, 2006, 02:34:38 am »

UPDATE:

I found a way around it. The solution was to extend the stereotype off a Class rather than a Requirement element.

But I still have one more question to go:

How can I make it so that the tagging link allows me to pick more than one element. When I click the little "..." button in the Tagged Values window, it displays the 'Set Element Classifier' dialog which only allows single selection.

13

Uml Process / UML Profile: Self-tagging

« on: October 01, 2006, 01:29:41 am »

Hello

Alright so this term might sound weird coz I just made it up. What I mean by self tagging is the ability to create a stereotype in a UML Profile and have one of its tag point to itself using a tag connector. Theortically, this should create a tag property for the element which displays all elements of the same stereotype in the model.

Take a look at this:

This is what I have on hand. However, when I export/improt the profile and I drop one element of such stereotype, the tag selector for the 'RelatedRules' tag property displays no elements even though there are other elements in the same diagram with the same element stereotype.

Any pointers?

14

Uml Process / Re: Recording detailed use case

« on: June 06, 2006, 04:39:44 am »

Another hint which I found useful for documenting detailed Use cases is to use named flows instead of numbers.  This way instead of referencing a number in an alternate flow or other use case (such as at step 5 of Basic flow), I mention the location of the flow (such as at [request customer details] of basic flow).  The obvious advantage of this is that in case I introduce an extra step in the flow during use case review then I will not need to renumber all the referenced location since the name remains the same.

Hope this helps.

After much debate about how to document my UCs, I've decided to go with this method you've proposed. It sounds like the most intuitive and reduces maintaince work, especially now that I'm under heavy time constraint in order to push the project down to developement.

15

Uml Process / Re: Question on UC Generalization/Specialization

« on: June 19, 2006, 05:41:16 am »

Firstly,  getting back to Request a Service - you should only create extension UseCases when there is an essential behavioural difference.  If there's no essential behavioural difference, then the main use case should suffice...

So, with respect to Print Client Report we can apply the same concept...

There should be as many UseCases as there are essential behavioural differences.  In this case, I suspect there won't be.  (Select Menu Item, Select Report, Enter Parameters, Execute Report)  You'll be able to create a hierarchy of classes corresponding to the different types of reports.

Does that help?
Paolo

So the keyword to look for here is essential behavioural difference. My interpretation of this is the following:

Only use extending (and rarely specializing) use cases when the extending or specializing use case essentially alters the course of the basic path scenario of the main use case. This is as opposed to when the main use case can be repeatedly applied to multiple cases where the variation has more to do with the application of the use case rather than on its essential defined behaivour.

If that's the right conclusion, then yes you've been very helpful.