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

Pages: 1 ... 3 4 [5] 6 7 ... 20
General Board / Re: Dependency links to attributes?
« on: November 01, 2004, 10:00:03 am »

Does rather highlight a need in EA however - either (1) allowing attributes to have dependency relationships in order to track their individual use, or (2) improving the reporting functions to show attributes in, for example, a matrix view.

I'm more of the opinion that the UML should define a standard for the feature (externalizing attributes?) and that EA could then provide something on such a basis.

General Board / Re: Dependency links to attributes?
« on: November 01, 2004, 05:52:45 am »
G'day folks,

Here's what I've finally decided to do.

I'm setting up my domain model so that things that would normally be attributes (like "building name") are instead classes of their own.

So, anything in our system that references that attribute (say some field on a form, or some field in a report) has a dependency on the class that represents that attribute.

Now, if building name changes in any way (for example, the size of it), I can easily evaluate the impact of that change on the system by reviewing all dependencies, and find out all classes and components that will need to be resized.

Thanks again for the help.

General Board / Re: Dependency links to attributes?
« on: September 16, 2004, 05:03:21 am »
G'day g'day,

I'm sorry Mikkel, I dove right in on your first suggestion without giving the second one even a quick glance.  I'll have to go over some books to see if any of them give examples.

Much appreciated.

General Board / Re: Dependency links to attributes?
« on: September 15, 2004, 09:32:12 am »
G'day Mikkel,

I don't think that you can draw that kind of parallel between database model and software class model.

For example, say I have a table "Building" with the following attributes:
- bldg_name
- bldg_location
- construction_year.

Now let's say I have 5 reports/screens that only show bldg_name, 4 that show bldg_name and bldg_location, and 2 that show all attributes.

I really would not want to create three distinct tables to store each of those attributes separately.  That would make our applications and database administration so much more complicated.

General Board / Re: Dependency links to attributes?
« on: September 15, 2004, 05:04:40 am »
Top o' the mornin' to ya (I want to follow that up with "Have you had yer Lucky Charms?"),

The ability to setup dependencies on attributes would allow us to identify  the impact of change to an attribute: we could easily identify all components (screens, reports, etc.) affected by a change.

It's easy to document these relationships as independent or embedded notes, but notes would be a pain to maintain.

Maybe there is a way for me to get what I'm looking for, but I'm not seeing it.

General Board / Dependency links to attributes?
« on: September 14, 2004, 12:12:13 pm »
G'day g'day,

I have a report component that accesses many tables, several columns from each table.

Although I can easily show the component's dependencies on the tables, I'd like to show the specific columns the component depends on.

Is there a tidy way of showing dependencies to attributes?

Setting the source roles on the dependencies to the tables' attributes works, but I'm not quite sure that's the best way to go.

General Board / Re: finding invisible connectors
« on: October 14, 2004, 10:00:47 am »

My first thought is to use the Relationship Matrix to try and identify relationships that should not exist.

General Board / Re: business use case model
« on: October 18, 2004, 08:22:50 am »

In EA's help file index, look for "Business Modeling Stereotypes 1".

Kevin, are these the symbols you're referring to?

General Board / Re: Requirements solution description
« on: October 19, 2004, 05:20:24 am »
G'day Thomas,

How about tags?

General Board / Re: How to Create a Business Process Diagram
« on: October 08, 2004, 04:38:40 am »
G'day g'day,

I just don't understand what type of diagram to open to build my business process models on

Use the "Analysis Diagram," already built-into EA.

General Board / Re: Linking classes (Tables) in different packages
« on: September 30, 2004, 04:43:56 am »
G'day Stark,

How about setting up the diagram to "not" highlight foreign elements?  Check out "set appearance options" in EA's help file index.  The option will show/hide package name prefixes on the diagram.

General Board / Re: Linking classes (Tables) in different packages
« on: September 29, 2004, 11:03:18 am »
G'day Stark,

I quite liked the hyperlinked list of tables for each seperate module (package) within the HTML output

That's what I thought too at the start, until I realized that the one large list of all tables was more useful for our needs (i.e. one complete table directory to lookup table documentation).

For each of our packages, we wanted a diagram of the tables in the package.  We use the diagrams as the source for hyperlinking to table documentation when viewing documentation for a package.

One of our primary reasons for datamodeling within EA is the ability to link any software classes or components to tables so that we can at any time find out the impact on the software when/if we make changes to any table.

All that babbling aside, good luck to ya.

General Board / Re: Linking classes (Tables) in different packages
« on: September 29, 2004, 04:54:43 am »
G'day Stark,

First, don't put the tables in separate packages!  That's the first thing I did, and it really messes up any later synchronization;  database synchronization expects all the tables in one package.  (If I am wrong here and there is something I missed, please let me know!)

When you import the database in some package, leave the tables in that package (call it your import package).  This is important for future synchronization and also really nice when producing HTML documentation: you have available a sorted list of hyperlink database table names.

To split your model into packages, don't move the tables into those packages.  Instead, create a class diagram in each package and show in that diagram only the tables that pertain to the package.

I've found this setup the best.  Again, though, if anybody knows something that I've missed, then please point out the error of my ways!


General Board / Re: Data Modelling Strategies
« on: September 29, 2004, 04:45:23 am »
G'day g'day,

Thanks Simon.  

Is that link on your web site?  If not, your UML Tutorials page would be a great spot.

General Board / Re: Data Modelling Strategies
« on: September 27, 2004, 02:04:25 am »

Check out this article:

Sorry, I don't have any better answer than that ... still trying to figure things out myself.

Pages: 1 ... 3 4 [5] 6 7 ... 20