Messages

1

Suggestions and Requests / Customizable reverse engineering

« on: October 16, 2006, 01:13:35 am »

Hi,

Forward engineering in EA is quite flexible, thanks to the code generation templates. Unfortunately, the reverse engineering in EA is, on the other hand, very inflexible: the code templates and language grammars used by EA for reverse engineering are not adaptable. This old post discussed this topic as well, and the word was that customizable reverse engineering was being worked on back then: http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=general;action=display;num=1090397634.

We're very much in need of more flexibility and customizability of the reverse engineering process. This way we especially hope to get more control over reverse engineering of collections and associations.

Can anything like this be expected anytime soon?

Cheers,

Pascal Lindelauf.

2

Suggestions and Requests / XMI 2.0 wanted desperately!

« on: July 26, 2006, 06:29:20 am »

It has been posted before, but now things are getting more urgent at my customer's site as well: we need XMI 2.0 support to move forward! Can anyone from Sparx give a hint as to when this is to be expected?

Thanx!

Pascal.

3

General Board / Re: EA 6.0 beta and VS 2005

« on: November 04, 2005, 07:43:50 am »

Are you sure? Jeez... that what I was hoping to test! Can anyone from Sparx Systems shed light on this? Could you also indicate when support will be included and how to customize VS 2005 is such a way that the EA project view will show up in the VS IDE?

Thanks!

Pascal

4

General Board / CVS and working offline - HELP!

« on: July 22, 2005, 02:47:11 am »

Hi,

We're working with geographically separated teams on a couple of projects and decided we want everyone to be able to work offline on the models we create. Therefore we're working with EA file-based instead of db-based. To share model updates, we want to use a central server to put our models on, managed by CVS.

Now we encounter three problems:
1. You can easily create controled packages below the project root node and manage them with CVS. But what about the project root, or the main EAP file itself? How can we perform version control on this from within EA?
2. We want to apply pessimistic locking on the packages, meaning that when user A checks out a package from the central CVS repository, the package shouldn't be editable by user B. This works fine when user B is online, but when he is offline, he cannot make a connection with the CVS server and all packages then become editable for user B. In short: user B doesn't know which ones belong to him and which ones were checked out by user A and should thus be readonly. How can this be solved?
3. It's seems the baseline option in EA is not really linked to the versions of packages stored in EA. What we want is to have the designers create a baseline of the set of current models and put that into CVS. The developers should be able to check out that baseline from CVS, while the designers move on with their work creating new packages. How is this established?

I hope someone can help us soon with these problems!

Thanks in advance!

Pascal.

5

General Board / Re: examples of scenarios

« on: June 08, 2005, 04:22:18 am »

Thanks for your input Thomas. I started with labels like this as well, but while I was creating these I found that apart from labels denoting exceptions, I also had to add labels denoting entry points to which alternate scenario's could return. My feeling was this made the use case somewhat less readable. But it's good to hear this works fine for you.

Pascal.

6

General Board / Re: examples of scenarios

« on: June 08, 2005, 12:19:46 am »

Not a reply to your message TrtnJohn (sorry), bat rather to my own post. I've puzzled around a little with my example and I've decided the nicest way to capture a use case like the "Login""  one in EA is this way:

Basic Path
1. System requests login information (username, password)
2. Actor enters the requested login information
3. The system verifies the login information and grants him access to all functionality available to the roles he is authorized to fulfill.

Alternate scenario "Forgot password"
2. The actor forgot his password:
 - The system request's the actor's e-mail address
 - The actor enters his e-mail address
 a1. The system does not know the e-mail address:
    - The system reports that the e-mail address is unknown
    - Continue with step 2.
 a2. The system knows the e-mail address:
   - The systems send the password, that is associated  to the entered e-mail address, to the e-mail address
   - The actor retrieves his password from the e-mail message that has been sent to him.
   - Continue with step 2.

Alternate scenario "Login failed"
3. The e-mail/password combination is unknown by the system:
 - The system reports that login has failed.
 - Continue with step 1.

I hope this helps you a little, Kimberly. If anyone uses some other variant, I'll be interested in reading about it.

Pascal.

7

General Board / Re: examples of scenarios

« on: June 07, 2005, 02:13:10 am »

I came across this post, since I ran into the exact same problem as Kimberly. I'm used to writing my use cases in Alistair Cockburn's style, where alternate scenario's are described as exceptions to the basic path. Therefore you'll have to reference steps in the basic path from alternate scenario's. Like Kimberly I was wondering how you guys do this elegantly in EA in such way that the scenario's stay manageable and readable for all stakeholders.

Here's a simple example of a "login" use case as I would normally model it. Who'd like to show us what you find the best way to capture this particular example in EA's "basic path" and "alternate path" paradigms?


Basic Path
1. System requests login information (username, password)
2. Actor enters the requested login information
3. The system verifies the login information and grants him access to all functionality available to the roles he is authorized to fulfill.

Alternate scenario's
2a. The actor forgot his password:
 - The system request's the actor's e-mail address
 - The actor enters his e-mail address
 2a1. The system does not know the e-mail address:
    - The system reports that the e-mail address is unknown
    - Continue with step 2.
 2a2. The system knows the e-mail address:
   - The systems send the password, that is associated  to the entered e-mail address, to the e-mail address
   - The actor retrieves his password from the e-mail message that has been sent to him.
   - Continue with step 2.

3a. The e-mail/password combination is unknown by the system:
 - The system reports that login has failed.
 - Continue with step 1.


Thanks in advance!

Pascal.

8

General Board / Your use case step labeling approach?

« on: June 08, 2005, 12:32:56 am »

I'd like to label the steps in my use cases' basic path, so that I can refer them from the alternate scenario's. I was wondering what you guys find the best labeling scheme.

Numerous people seem to use the sequential numbering scheme with increments of 1:
 1. Actor does A
 2. System replies B
 3. Actor does C
 4. ...

Inserting a step in this scenario leads to a renumbering nightmare, especially when you have quite a few alternate scenario's. A solution would be not to number sequentially, but arbitrary (only when needed for referral from the alternate scenario):
 - Actor does A
 1. System replies B
 2. Actor does C
 - ...

Inserting a step between 1 and 2 then yields:
 - Actor does A
 1. System replies B
 3. System asks D
 2. Actor does C
 - ...

Conceptually I think this is the best, but I think that users have a hard time understanding the logic behind this. Other options are using logical step names instead of numbers. I think that this clouds up the scenario description too much. Last but not least seems to me the old "Basic programming language" approach: number sequentially with increments of 10:
 10. Actor does A
 20. System replies B
 30. Actor does C
 40. ...

This leaves room for 9 inserts between all initial steps, e.g.:
 10. Actor does A
 20. System replies B
 25. System asks D
 30. Actor does C
 40. ...

Anyone care to share his use case step labeling approach?

Pascal.

9

Uml Process / Re: Use case versioning - Best practices?

« on: December 14, 2005, 02:22:46 am »

Rob,

Thanks a lot for pointing that topic out to me. Indeed, we will encounter this problem not only when modeling use cases, but with all model elements, so the mentioned solutions are very appropriate.

One thing I'm wondering: the thread is 1.5 years old so I'm guessing you've worked with the method suggested by yourself quite a bit since then. I can imagine that by now you've perfected your method. If so, can you share what new insights you've gained since then?

Thanks a lot!

Pascal.

10

Uml Process / Re: Use case versioning - Best practices?

« on: December 08, 2005, 02:08:10 am »

Bruce,

Thanks for your quick input! I can see how copying the release A use case to a release B use case and updating it with the new or changed functionality can solve this problem.

The only drawback I currently see with this is that dependencies other model elements have on release A of the use case, will, at some time have to be moved over to release B of the use case. I'm thinking of things like <<trace>> dependencies between the use case realisations and the use case. Then again (I'm thinking while I'm typing [who said men cannot do two things at once   ]), this is probably more of a benefit, since this helps the person doing the use case realisations to explicitely track if he has updated the realisations for release B. Hmmm....

I'd still be eager to hear if others manage this problem differently, though.

Thanks do far!

Pascal.

11

Uml Process / Use case versioning - Best practices?

« on: December 07, 2005, 02:39:07 am »

Hi,

One of the organisations I work at has EA running on a central repository. They now want to start using it for analysis in a serious project. An information analist will describe the use cases, based on which other project members will do their work.

Now the analist wants to add or change something in a use case others are working on. However, the others should not be confronted with this change until the next iteration.

My question: how do you best distinguish between these two versions of a use case (in order to let the analist work on his new version and the others work on the old version at the same time)?

Thanks!

Pascal

P.S. Version control is the first thing that came to my mind. I have not used it yet on a repository-based EA implementation, and I'm guessing that it is not possible for two groups of users to work on a different version of the same package, since everyone shares the same version of the whole repository, right?

12

Uml Process / Re: Own defined attribute types

« on: July 04, 2005, 04:03:16 am »

Hi Martin,

I checked your profile: that's indeed the way I do it. (I wasn't able to open your EAP file, BTW).

Paolo, I've only used the profiles for managing my custom stereotypes so far.  I haven't used it for setting default properties, for example.

Thomas, I'd be interested to know how you define default tagged values in your profiles in such a way that, when you drag the item from your profile, the tagged values are also included in the new instance. I've tried this with a stereotype I created for a use case, but the only I only managed to set a number of default constraints in the profile (and no tagged values, for example).

Pascal.

13

Uml Process / Re: Own defined attribute types

« on: June 08, 2005, 01:58:30 am »

Hey Martin,

I defined my attribute stereotypes by creating my own UML modeling profile (see the "Create a UML profile" topic in the help file).

Basically this comes down to this:

• Create a package (e.g. in the "Custom" package) with stereotype "profile"
  
• Insert a custom diagram
  
• From the "Profile" toolbox, drag a Metaclass onto the diagram and select the "Class" element
  
• From the "Profile" toolbox, drag a Stereotype class onto the diagram and name it "datatype"
  
• Create an <<extends>> relation from the stereotype to the Class metaclass
  
• Save the diagram
  
• Export the package to a UML profile file (XML), by right clicking on the "profile" package and selecting "Save package as UML profile"
  
• Switch to the "Resource view", right click on "UML profiles", select "Import profile" and select the XML file you just exported
  
• Once imported, you'll have the stereotype avaliable for typing your attributes.
  

One more thing: next to the <<datatype>> stereotype, I use the <<enumeration>> stereotype for my attribute types to denote this special kind of datatype holding a predefined number of values.

Of course you can also do this the easy way, by using the Configuration/UML/Stereotypes dialog. But I like the UML profile way, since it allows me to manage my own stereotypes in a seperate file.

Hope this helps!

Good luck!

Pascal.

14

Uml Process / Re: Own defined attribute types

« on: June 08, 2005, 12:48:27 am »

Hey Martin,

Now I understand what you mean!  

I stereotype my basic attribute types with <<datatype>>. I declare my datatypes in a package that is contained in the package that represents the scope in which I want the datatype to be visible. E.g. in all my logical models I'd like to use the datatypes Date, MonetaryValue and such; I have defined them in a package named "Shared Datatypes" in my "Logical view" package. On a more detailed level I have specified my components, which have their own set of specific attributes. E.g. say you have a "Customer Manager" component; I'll have this in "Customer Manager" package, which contains a "Datatypes" package for all datatypes used by classes within the "Customer Manager" component, like Gender, Zipcode, etc.

Hope this helps!

Pascal.

15

Uml Process / Re: Own defined attributes

« on: June 07, 2005, 07:34:28 am »

Hey Martin,

I'm not sure I understand your question... attributes are part of a class, so I'd suggest you add them to the attribute list of the class (press F9 when you've selected the class). Or do you mean something else?

Pascal.