• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

Component Diagram...what's legal

 
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
All,

I would reallly appreciate your advice.

Is aggregation or composition in a Component Diagram legal UML? I have seen so many sites now and none with it...yet no books or sites which exclusively forbit it.

Thanks VERY much in advance
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What would aggragation or composition mean in a component diagram? Do you even have associations in it? Please provide examples.
 
Bil Bob
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the reply!

Essentially, I can understand relying more upon dependencies in the example:

such as a customer component needs/depends on a Credit card (or visa versa)

but i guess i was wondering...in the case of a composite entity like above (ie. a customer with a credit card and an address) is it then relevent that a customer HAS a Credit Card within its entity structure (thus aggregation...in fact composition as CC required a customer)?

Please advise
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The function of Component Diagrams is to show *physical* dependencies between components, such as compile time dependencies or deployment dependencies. Typically they show systems at a much more coarse level than classes - jar files, for example.

For those reasons, associations, aggregations and compositions are irrelevant for Component Diagrams, as far as I can tell.

BTW, I think you got the meaning of composition wrong - see http://faq.javaranch.com/view?AssociationVsAggregationVsComposition
 
Bil Bob
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks your thoughts. I see your point and will lean towards that approach.

I think the FAQ has some agreement with how I view composition...but just describes a more specific view. I am going to look into it more just to be certain.

Have a nice day
 
Beware the other head of science - it bites! Nibble on this message:
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic