Talk:Component diagram
 | This article has not yet been rated on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
| ||||||||||||||
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.