作为作业的一部分，我必须为现有代码创建组件图。我理解组件图是什么以及它呈现的信息，但是我不确定在查看代码时要遵循的流程来制作组件图。我也没有出售组件图，如果我看到组件图，将帮助我实现系统。
答案 0 :(得分：2)
也许看看Scott Ambler的UML 2 Component Diagramming Guidelines和Introduction to UML 2 Component Diagrams。这些是恕我直言的两个很好的资源，解释了如何以及何时可以使用这样的图表。
答案 1 :(得分：2)
您说明了两个不同的问题：如何从代码到图表，以及如何使用一个作为实现系统的指南。如果您正在绘制现有代码，我认为第二个问题不适用。
如果你正在设计新的代码，那么组件图可以是1）一个有用的抽象，用于理解代码的重要部分，减去所有的干扰，以及2）与他人沟通的好方法。
如果您正在查看现有代码，那么现有的组件图（或其他几个UML工件之一）可以作为代码的指南，这尤其有助于维护：可以更容易地识别错误的位置，主要职责等。
如果没有图表，那么通过阅读代码来制作一个图表是一种熟悉自己的好方法。在继承复杂的代码库时，我在很多情况下都这样做了。因此，我有几页应用程序和数据库的图表，一目了然地告诉我有关其主要组件的有趣信息。在任何时候，我都会非常熟悉某些领域，而不是其他领域，这取决于我正在做什么。这些图表很好地提醒了如何使用应用程序的各个部分。当他人加入团队时，他们会很有帮助;他们在走完图表半小时后更快地理解代码。
要使用现有代码，您需要仔细阅读它，识别正在使用的主要类，然后追溯以了解它们用于协作的依赖关系和接口，方法签名和数据结构。如果它是一个由数据库支持的应用程序，那么查看数据库的描述会很有帮助，因为它应该体现应用程序的主要问题。
有一些用例可以指导调查，因为对于事件驱动的应用程序，您需要了解用户正在执行的操作以便跟踪代码。如果没有现有的用例，那么首先自己编写一些简单的高级用例。然后按用例查看代码，并确定使用中的主要对象。希望您可以在程序中找到主要的类来管理您识别的主要用例。例如，如果应用程序是具有管理用户界面的基于Web的电子商务应用程序，那么您将识别许多最终用户和管理用户用例，并且应该期望看到一些特定于每个用例的类。这些家庭，以及整个过程中使用的通用和实用类。
保持高水平，避免诱惑你遇到的每一件事。
正如Pascal所说，Scott Ambler是实用UML知识的重要资源，并且具有可以尽可能少用或少用的guildelines。具体来说，请参阅Introduction to UML 2 Component Diagrams。不过，他为编写新代码的人写的东西比记录现有代码的代码要多得多，所以你必须适应他讨论的一些内容。
答案 2 :(得分：2)
Martin Fowler的“UML Distilled"仍然是你能得到的关于UML的最好的书。它的主要优点是它很薄 - 密集的信息。
答案 3 :(得分：1)
对我来说，UML主要不是帮助我设计一个系统（尽管它确实有帮助）。它是通过给我们一个共同的语言/符号帮助我将设计传达给他人。
它使对话更容易，因此我们不会浪费时间尝试在不同的参考框架之间进行转换。
答案 4 :(得分：1)
Scott Ambler是另一个现成的标准答案。但是，在组件图的情况下，我发现（Section Creating Component Diagrams）下的建议很好，但很长，与您的文档需求无关。从Scott的列表（创建组件图）我会真正关注（1,4,5,13），因为许多建议都是设计最佳实践。我将在下面添加更多我自己的内容。
Martin Fowler的书在很多方面都很出色，但对于Component Diagrams或Co来说并不是很深入。大量的7页，它向你展示了他在写作时优先考虑的地方，因为类图得到18页或者如此。
我同意你的看法，你应该能够意识到何时使用UML图。 UML 2.2规范本身表示它是为面向组件（服务/接口）的系统构建的。采用基本的MVC GUI应用程序并推入组件图/模型确实没有意义。还有几种方法可以图解组件关系，Scott Ambler's site在图1中显示它们。对于大型多系统实现，我发现这些图非常有效，例如：大量的接口和大量的系统抽象。
我的建议：（我经常使用组件进行建模，并阅读有关此内容的UML规范）
使用端口获取HL组件图，它们用于分组，虽然它们在Scott Ambler的图表中看起来很有趣但是你没有从中获得很多努力。
避免陷入内部组件结构。只有在高度复杂的情况下需要清晰时才这样做。
不要让大多数“类”成为组件。
专注于接口和存在真实边界的地方，线索是公共接口，包分组，WSDL，外部系统交互。
对于你的前几个我会自上而下开始。首先进行所有外部系统交互之一，然后进行下一级别，如果需要，使用端口和复合结构，但我不喜欢它们，它们很混乱，因为复合结构实际上是Parts，一个UML对象是一个类或组件的实例，命名变得复杂等。
一般选择一种表示法，使用球窝连接进行紧耦合，只切换到组件和提供者之间的使用/依赖线，以便松散耦合，实际可以切换组件（接口实现），两者混合在Scott Ambler的图1中（上面链接），左边是松散的，右边是紧耦合。 UML规范还在UML 2.2超结构的第8节中提到了这一点。
答案 5 :(得分：0)
来自VS 2010 Ultimate文档中的以下主题：
UML组件图：指南：http://msdn.microsoft.com/en-us/library/dd409393%28VS.100%29.aspx
绘制组件图有几个好处：
关于主要块的设计思考有助于开发团队理解 现有的设计并创造一个新的。
将您的系统视为具有明确定义和要求的组件集合 接口，您可以改善组件之间的分离。这反过来使设计更容易 在需求变化时理解并更容易改变。
Component diagram http://i.msdn.microsoft.com/Dd409390.UML_CompOvReading(en-us,VS.100).png
.png){kind=link}