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

Pages: 1 ... 43 44 [45] 46 47
Uml Process / Re: Composite vs Component
« on: September 16, 2005, 09:17:28 pm »
It (unlike the others) also has one or more Interfaces.
Can you elaborate on this?  What do you mean by "others"?  Structured Classes can, at least in Java, implement multiple interfaces too.

Uml Process / Re: Composite vs Component
« on: September 16, 2005, 09:39:23 am »
I read the two chapters but didn't come to the same conclusion.  However, I was squinting my eyes as I read past the examples and allusions that related to the context of their usage, to get a feeling for the underlying semantics.  Then, again, I may not have made my question clear.  I'm comparing Components to Classes having a composite structure.

Both Components and Composite Classes may have public interfaces, exhibit behavior, are assembled from other classes playing specific roles, if designed well can be substituted with others of the same type, are reusable, may be provided by third parties, can be 'wired' in at execution time, etc.   I just don't see a difference other than the notations used to diagram them and the context in which they are defined.

It seems that the major differentating features relate to their implementation & usage rather than their structure.  When I start to design an application, I should not have to be concerned whether I'm desiging a component structure or a composite structure.  IMO, that type of thinking should be deferred to development time.

I postulate that the subject two concepts had their genisis in two different areas of applied computer science and are now, perhaps, merging.

Could it be that UML maintains the distinction between the two to serve the commercial marketing interests of the corporations seated on the UML committee?  (I mean this in a kind and positive way guys ;)  After all, business is business, and I'm well aware, having 30 yrs in corporate software development, of the realities of that environment.)  Or, perhaps, with all the issues the UML committee has on its plate, they just haven't gotten to this issue yet...

Uml Process / Composite vs Component
« on: September 16, 2005, 04:57:03 am »
What are the essential or vital differences between a Composite and a Component?  Except fir scale and packaging, they look the same to me.

Uml Process / Re: Dependencys
« on: September 14, 2005, 11:45:24 am »
Are both A and B modeled on the same Diagram or are they modeled on different diagrams?

IMO, the dependency that A has on C is inherited when B specalizes A.

Now my question: should I show the dependency to C in the diagrams, or is it implicit?
Remember that a model is an abstraction of essential elements of interest from a real-world subject, and, that a model is a form of communication.  Thus, the answer to your question is "maybe", depends on how important it is to communicate B's dependency on C and what the probability is that your reader will get the implication.  There is no UML rule that I know of that requires either diagramming approach.  ;D

Uml Process / Re: Output in UML
« on: September 05, 2005, 07:55:49 am »
IMHO making an actor the output, not a consumer of the  output, kinda makes the output an end in itself.  It also negates analysis of output requirements and identification of the development project's stakeholders.

From the OMG UML 2.0 Spec. on Actors:
An Actor models a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data), but which is external to the subject (i.e., in the sense that an instance of an actor is not a part of the instance of its corresponding subject). Actors may represent roles played by human users, external hardware, or other subjects. Note that an actor does not necessarily represent a specific physical entity but merely a particular facet (i.e., “role”) of some entity that is relevant to the specification of its associated use cases.

I have difficulty thinking of output as a role.  Output is just a highly structured message [signal], perhaps with deep content, from the system to the actor.   I'm sticking with my use of the directed line from the system to the consumer as being the output, just as the information flows along the lines in an activity diagram.

However, another way to think of this is that messages are also objects that normally have structure.  These serialized objects move between systems and actors along the lines of which I speak.

Then, again, all of this discussion, so far, is moot if the question was asked within the context of Business Process Modeling.   Those models have their own diagramming elements...

Uml Process / Re: Output in UML
« on: September 02, 2005, 12:10:09 pm »
Output is really a message between two entities.  Ouput reports are the communication of information from the system to an actor.  I think you have a couple of options:

On a Use Case diagram, an association link (or Use) could represent an actor using the system to receive information.

Other possibilities might be the use of an AssociationClass or an Artifact.

Uml Process / Re: About association
« on: September 01, 2005, 02:56:34 pm »
Very impressive!  The world needs something like that.

I'm getting the feeling that EA has matured to the point where the developers need to spend so much time responding to issues raised by their clients that they don't have much time to move their product along its migration path.  Perhaps we can get them to Open Source the product like Sun has with theirs.  ;D

I would enjoy being a test user for you on this...I'm well known for breaking software  ;D

Uml Process / Re: About association
« on: September 01, 2005, 12:16:56 pm »
I'm not familiar with your project.  What is the input to your process?

Uml Process / Re: About association
« on: August 31, 2005, 09:48:05 pm »
I have evaluated many, many CASE tools over the years and have already come to that conclusion.  However, if a tool is given sufficient information (as we are able to do in EA), I do expect a reasonably robust forward generation of stubs and attributes.  (Having access to that feature is the primary reason I upgraded to my currentl level of EA.)  I'm not getting that yet out of EA, but I want to make sure the problem is not due to my understandings and is an opportunity for EA Enhancement.

Actually, I want to be able to render a rather complex OO design in UML and to teach my students to properly decode the model so they can realize the design in effective code.  (Obviously, textual design information will also be provided.)

From my perspective, it really does not matter if the code is machine generated or hand written, as the processes I teach are upstream of the coding process.  

Uml Process / Re: About association
« on: August 31, 2005, 07:32:02 pm »
That did it.  I just needed to move the association lines.

Now, I'm exploring the mysteries of the code generator's reactions to all this stuff I've just learned.  I'm getting a few surprises, but as I dwell upon them, I see a machine working logically behind the scenes.  I'm always surprised at the creativity of logic machines.

Now, I'm going to see if I can reconcile the machine's logic to the UML 2.0 spec.   ;D Might even get into the code generation templates too.  Wish me luck.  


Uml Process / Re: About association
« on: August 31, 2005, 11:43:36 am »

I thought a light bulb went on in my head as you explained that the three associations between Association and Property might not be redundant as they expressed different kinds of constraints on the relationship.  So, my discovery is that "more than one association line can be used to define a complex relationship"!  What a concept!  None of the UML books ever told me that.  Its kinda like association decomposition...

In another thread, you mentioned that you have multiple class drawings,  each articulating a different aspect of the class.  Again, wow!  The books never mentioned that either!  This is good stuff!

So I developed a model with two classes "A" and "B" such that A owned B.  Then I tried to add another association between them, but EA would not put it on the drawing!  It disappeared right after I released the 'clickndrag' button on my rodent???

How come??  :'(

Uml Process / Re: About association
« on: August 31, 2005, 06:18:21 am »
1) Ownership: I control you (including who can access you and who create and destroy you)
2) Nesting: You cannot be accessed, except through me
3) Containment: I hold you within me - but you are not of me
4) Collection: You are in a group
I love your allegories here.

So, in an association between two classes, the black diamond identifies the class which owns the association (including the end properties), but says nothing about who owns the associated class?  If true, I think this is good.  I'm thinking that Ownership, Nesting, Containment, and Collection are Structural issues then, not associative issues.

I can see then, that when a class which owns an association is immolated, it has an option to destroy the association link, but then again, it may not.  This seems to set up some referential integrity issues for me in that the objects being referenced no longer exist, but the link between them does?  Or worse yet, one object still remains with the association, but the other end is unconnected?  In Figure 12, the cardinallity of the association between Class and Property seem to allow this, or am I reading this incorrectly?

In Figure 12 again, I'm also bemused by the fact that both the association and the associated class may own a given End Property (as well ad the association itself) as both of them have black diamond ends on their links to Property.

All of this is making me wonder just what a Property Class represents?  The model says it is a specalized StructuralFeature, but does it exist in code somewhere or is it simply a concept that controls the generation of the code?  Are the terms End Property and Association End synonymous?

Who would have thought that a simple line on a diagram could be so complex?  ;D  Try explaining all of this to a first year college student!  ::)

I'm beginning to think we need to fork this thread into several sub-threads...

Here's hoping my questions are worthy of your attention.  ;)

Uml Process / Re: About association
« on: August 30, 2005, 06:07:13 am »
Thanks Paolo.  Your comments help, but I'm not there yet...  I'm (1) zeroing in on ownership; and, (2) wishing I could understand Figure 12, as well as the other metaclass diagrams,  better.

It is becoming clear to me that containment of an element does not imply ownership of it, nor does access to it.  So ownership of an element simply provides rights to exert control over its accessability by others, and the element's creation and destruction?

Can you help me to read Figure 12 better?

In Figure 12, considering the link between Property and Association, the ownedEnd of the link is attached to that which is owned (Property), and the owningAssociation end is attached to that which has ownership rights (Association).  But the question is "What is being owned here?", for when the Association is destroyed, something else is destroyed too.  Does the Association own the link between itself and Property, or is the link notation saying that Association owns a Property?  I guess the circular definition is confusing for a link is an association.

To my imperfect mind, of the three links between Property and association, the first is navigatable in both directions, the second is also (but adds aggregation to the mix) and the third is only navigatible from Association to Property.  These three links seem both redundant and contradictory to me.

And, looking below the Association, why is the type classifier not associated with the end property?  or, is that what the association element is doing, or is that what "+/endType {ordered}" means?  ???

I have more to ask, but I must deal with an unowned element called work.   ;D  Later.....

Uml Process / Re: About association
« on: August 29, 2005, 02:09:14 pm »
I'm still confused by that and this statement:
An end property of an association that is owned by an end class or that is a navigable owned end of the association indicates that the association is navigable from the opposite ends, otherwise the association is not navigable from the opposite ends.

Perhaps I don't understand the concept of owned.  How can an association own anything?  its a tuple referencing the end classifiers...

AND, how does an end class own an end property of an association?

AND, except for classes with internal structures, most associations are between classes, not within them?  How are they ever inside of a class?

I'm reminded of the Klein bottle.   ;D  Can you elaborate a bit more?

Uml Process / Re: Diagramming Artifacts
« on: August 31, 2005, 08:03:32 am »
Can somone tell me if this diagram is correct?
 Correct is the operative word here...

What are you trying to document|diagram?  You are using a Deployment diagram (how artifacts are allocated to physical nodes) to document a database structure and document associations!  And then, your textual comments document a work flow process.  ???

I'm confused...You need to clarify your thoughts I think.  At least, make your question more specific.

Pages: 1 ... 43 44 [45] 46 47