Talk:Component diagram

I take issue with the assertion that "files" and "headers" are physical objects. The person who wrote this is a programmer who is used to thinking of the different diagrams through an analogy to physical space. It is more likely that the author intended to say "functional" or "sovereign".

I removed the term physical. —Preceding unsigned comment added by 193.78.112.2 (talk) 12:19, 8 January 2008 (UTC)

This entry does not really say anything and what little it says is erroneous (physical components?? The physical manifestation of Components are Artifacts). This requires a complete rewrite and I propose to do that in the coming days.

Kishorekumar 62 (talk) 08:01, 22 January 2009 (UTC)

When is the right version coming? —Preceding unsigned comment added by 12.17.120.141 (talk) 20:58, 28 January 2009 (UTC)

I disagree that the example diagram is indeed a component diagram. There is a confusion between instances and component definitions in the example diagram. They should be separated more clearly. This is not actually a component diagram, but a composite structure diagram afaics. The whole point of component diagrams is reasoning on what a component requires functionally from other subsystems, then separately satisfy that need by instantiating a component that provides it. This is the base for allowing substituability of a component by another realization of the same interfaces.

In other words, either you represent component definition (required & offered interfaces), or you represent component instantiation (composite structure), but both should not be mixed.

YannTM 132.227.64.140 (talk) 08:40, 12 September 2011 (UTC)