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 - Englisito

Pages: [1]
General Board / Re: Default Diagram
« on: February 08, 2004, 06:28:20 pm »
It doesn't seem to work like that, not for me anyhow (build 658).

As I said, it seems to ignore the ordering of the diagrams, and even selects diagrams hidden within elements (if they are alphabetically first).

General Board / Default Diagram
« on: January 18, 2004, 06:32:26 pm »
I've been trying to find a secure way to define the default diagram that gets opened in packages or composite elements, with little success.

I've worked out that the diagram is chosen alphabeticaly (not by the sort order), from all diagrams in a package/element (including diagrams hidden within sub elements).

So, if I name diagrams correctly I can control which is the default diagram, but this is a messy solution and gets even worse when the stereotypes get involved with a diagrams name.

Has anyone descovered a GOOD way to assign default diagrams!

General Board / Re: Moving things around is slow
« on: January 16, 2004, 12:57:23 am »
I found if I switched on "Objects Snap to Grid" (Tools-Options, Diagram Behavour) then everything went realy slow.

Switch it off and see if things are better.

General Board / Re: Importing MySQL data model
« on: January 16, 2004, 12:19:55 am »

I just did an import today so its fresh in my head:

  • First setup the ODBC data source on your machine.

  • Create a package to put it in and a class diagram. I used the default deployment view, its deployment model and deployment diagram.

  • Open the diagram.

  • Select Project->Database Engineering->Import from ODBC.

  • Set the database name using the "...". It should be in the 'Machine Data Source' tab of the dialog.

  • Then Import.

  • Here you can select the Tables you want then OK it.

The table elements etc. are created and displayed in your diagram.

I think it works out its MySql automatically and uses the data types as defined in Configuration->Database Datatypes.

The only problem I had was it seemed to lose some data type definitions and I could not work out how to edit things like field length. Looking into both of these.

Once this is solved I should be able to use the models to generate DDLs.

Hope this helps

Uml Process / UP/SPEM modeling in EA
« on: January 18, 2004, 08:18:35 pm »
I've been working on modeling our development practices (based on UP) using the SPEM profile provided by EA, and was wondering if there are any "best practices" :) out there.

My main objectives are to provide an easy way for us to document and later find "how to do things".  This means I want it easy to add/alter WorkDefinitions, and at the same time make it easy to navigate and find information in the area of work the developer is currently working in.

I found the examples with the SPEM profile did not provide what I wanted so I've played around a little.

This is what I came up with. Any comments would be appreciated, especially as I'm new to a lot of this.

This is an example of the package structure I'm using. Points of interest:
the leaf nodes are WorkDescriptions (UseCases) which can contain a diagram and any elements specific to the description. Activities can be very simple and only contain text in the notes of the activity.

I package every WorkDescription. Several reasons for this. Better documents (headings) and composite WorkDescriptions (easier control of default diagrams if everything is packaged seperately!).

Note, the default diagram for a package will be the diagram for the WorkDescription within it.

The standard diagram for a WorkDescription follows this format:

Points of interest:
I add the WorkDescription for the diagram to the top left of the diagram. As well as a reminder of what the diagram is about, it can show any Roles or WorkProduct involved and provides direct access to any information within the element (notes, relationships etc)

The rest of the diagram is flexible, it could be based on other WorkDefinitions, state diagrams etc.

Other things:
I put all the Roles in a Roles Package and all the WorkProducts in a WorkProducts package.

I have ProcessComponent packages to store other disciplins. These could include "Using EA/UML", programming tips in "Javascript", ".NET" etc.
This is so the processes are directly findable and can be pulled into other processes as required. A example would be that any UML Diagram based workProduct would be linked to the "How to..." WorkDescription on that type of diagram.

I think thats enough for now  ;)

Pages: [1]