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

Pages: [1] 2
Suggestions and Requests / Re: Tree Style Orientation
« on: April 30, 2004, 07:42:50 am »
I second this suggestion and add that the tree style should be consistant for generalization and realization.

-- dave

Suggestions and Requests / Re: CRC card diagram
« on: April 30, 2004, 07:39:33 am »
The notion of CRC cards is important in MDA. CRC cards are a great tool to use when gathering domain knowledge for the platform independent model. It would be a great feature to be able to use a CRC template in EA to capture and retain the CRC information.

-- dave

Suggestions and Requests / Tree layout for realizations
« on: April 30, 2004, 07:37:17 am »
The tree layout for generalization really helps keep diagrams neat. But I don't see the same option for realization. Can 'tree layout' be made consistant for both generalization and realization?

-- dave

Suggestions and Requests / Requirements Mgt
« on: May 13, 2003, 09:55:15 am »
I'm having a bit of trouble getting started using the requirements modeling functions. When I double click on the built-in diagrams under custom->requirements, some of them open the Analysis toolbox and others open the Custom toolbox. Is this the correct behavior? Intuitively, I would think that all of them would open the Custom toolbox.

-- dave

Suggestions and Requests / Tree view extension for realizations
« on: May 10, 2003, 11:29:03 am »
Could we have the same "tree view" feature for realizations as exists already for 'generalization'?

-- dave

General Board / Re: N-ary association
« on: February 01, 2003, 03:40:12 pm »
Hi Ilja,
In build 3.51_600, the Class category in the Toolbox has the N-ary association icon.

-- dave

General Board / Re: Meta-types
« on: July 30, 2003, 04:13:56 pm »
I think I found an answer on my own. It appears that a profile might do the trick.


General Board / Meta-types
« on: July 30, 2003, 04:02:35 pm »
I would like to define a set of meta types with attributes; simple enough. But does anyone know how I can have the attributes of the meta types automagically become tagged values in a meta type instance?

Another way to look at it is, if you assign a stereotype to a class, the attributes of the stereotype should become tagged values in the instance. Is there a way in EA to have the attributes of the meta-type (that defines the stereotype) auto-populated in the instance?

General Board / Re: Business Process - Help Required Please
« on: May 10, 2003, 11:19:23 am »
Hi Matt,
I don't mean to be overly dogmattic but UML is not a process, its only a modeling language. Design and development processes use UML as a communication tool. Perhaps the conceptual misunderstanding is causing some of your confusion.

For business process modeling I usually depend upon "Business Modeling with UML" by Eriksson and Penker (OMG Press/Wiley). It has provided me with a much clearer idea of the principles of process modeling.

Fundamentally, a goal is symbolizes a desired state of a resource. Goals are achieved by processes and can be expressed by rules, almost like a post-condition. A goal object is usually drawn at the top of a process diagram and has a <<achieve>> dependency.

A supplying object is a resource that participates in a process. It is not consumed or refined. They are usually shown at the bottom of a diagram, below the <<process>> with a <<supply>> dependency.

Input objects are like supply objects except that they are consumed or refined. They can be stereotyped as <<physical>>, <<abstract>>, <<people>>, or <<information>>. They usually appear on the left side of the diagram in relation to the <<process>> and are connected to the <<process>> with a dependency.

The <<uses>> stereotype is worthless in my opinion. It is far to general to communicate anything of value. For instance, a <<process>> uses resources, but <<supplies>> takes care of the situation just fine. A <<process>> can also use a subprocess, but <<controls>> seems to fit the bill more concisely.

hope this helps.
-- dave

General Board / Using Requirements Features
« on: May 13, 2003, 10:58:01 am »
I'm having a bit of trouble understanding the Requirements features. I understand the modeling aspect, but I don't see a place where I can enter and organize requirements in a more conventional way.

The modeling aspect is nice, but I have found it difficult to organize in brainstorming sessions and requirements reviews. I usually begin modeling the requirements once the ancillary 'people' issues start to quite down. Consequently, it would be nice if I could manage requirements in a list oriented paradigm like the defects and changes lists.

It would also be very nice to have the requirements organized in a more conventional manner.  I couldn't find a report for requirements that gave me a matrix including the priority, comments, description, etc. There seemed to be only the RTF format with no specific template for a requirements matrix.

If I've overlooked something, would someone please fill me in on the details.

thanks in advance,
-- dave

General Board / Trees
« on: May 10, 2003, 11:27:22 am »
Recently there was a post that asked about displaying generalizations in tree format.  I wanted to use the same feature for a <<realize>> but didn't see the choice on the pop-up.  Could we have the feature added to the <<realize>> pop-up? Or have I overlooked something that is right in front of me?

-- dave

General Board / Re: Code Generation and Stereotypes
« on: May 03, 2003, 10:25:02 am »
I think the bottom line is the UML specification. If a Class classifier is stereotyped as an interface, the language mapping should be able to understand that. After all, an interface is a Class classifier with a <<interface>> stereotype.

In UML 1.5, the definition is a tad confusing because it defines an interface as "formally equivalent to an abstract class". This implies the conclusion that an interface is a class with modifiers making it abstract (stereotype and isabstract tag set to true).

However, in the same sentence the spec states that an Interface is "a peer of class within the UML metamodel (both are classifiers)". This implies that Class and Interface are peer instances of Classifier.

There is some clarification for tool builders in the Notation section of the definition. "An interface is a classifier.....shown using the full rectangle symbol....and the keyword <<interface>>". And again in the Mapping section: "A class rectangle with stereotype <<interface>>.."

I would lean toward implementing an interface more toward being an abstract Class. Meaning that I would not use two different classifiers to render Classes and Interfaces. An Interface is a Class with the keyword <<interface>> and the isabstract tag set to true.

my 2p
-- dave

General Board / Re: Change generated code format?
« on: May 03, 2003, 09:49:57 am »
IMO, it would be great if EA supported the current XMI and XSLT. If EA supplied a foundation of templates and leveraged an open source XSLT generator, users could simply export the model to XMI and run the XSLT generator. Users coudl augment templates to suite their style and language!. Lot's easier than trying to make changes to binary generators and keep up with feature requests.

my 2p

General Board / Re: Issues on build 609
« on: May 03, 2003, 09:44:25 am »
I'm more interested in the road map to support the current version of UML and XMI. Whether or not the interface supports the XP style is not very interesting to me.

my 2p

General Board / Change Request: UML Pattern enhancement
« on: February 17, 2003, 10:12:17 am »
Great strides in 3.51!! I started using the UML Patterns feature and was inspired to ask for this change. Could the pattern be dropped onto a diagram as a package template?

Here is my line of thought: Diagrams can get cluttered quickly. I have adopted a style suggested by the Agile Modeling folks that puts a soft limit on the number of classifier entities in a diagram. When the number climbs to around 10 or more, I begin to refactor the diagram into many diagrams each with a particular component of the whole. Patterns are a natural fit for defining reusable components. I'd like to drag a pattern onto a diagram as a package that realizes one or more interfaces.

Presently, a pattern reveals its internals when it is placed onto a diagram. This clutters the diagram and if approached from the component perspective the detail is not useful because the internals are defined in the pattern's own diagram.  The diagram that uses the package can trace to the diagram that defines the internals. The idea will probably remind some folks of an import, and there are some similarites. But, detailing a pattern as an import is not accurate.

Currently the EA pattern mechanism asks for the interface names that need to be 'renamed' for the instance of the pattern. This mechanisim can be extended in my paradigm as asking for the interfaces that will be revealed to the pattern user. This implies that the interfaces are realized by the package that encapsulates the pattern and are available for extension by the user.

As a last comment, UML 2.0 is moving toward this idea and details patterns as Package Extensions. There is also some interesting OMG work on profiles for component collaboration called EDOC. The pattern profile that EDOC defines is very much like what I have tried to describe above.

-- dave

Pages: [1] 2