UML can be used in a light way in an agile context. The key is simply to be clear about its purpose and what you expect from modeling in your project.
Class diagrams and sequence diagrams are proven to be good candidates for helping teams to discuss points of concerns. It can express clearly ideas that are not obvious in the code (or scattered across many source files). Scott Ambler for example wrote a lot on agile modeling, based on UML. Of course, you will not use it for producing an exhaustive model with all classes and all properties. But you'd sketch the core with some relevant classes, and only a few properties that matter in the discussion (Ambler says "Just barely enough" modeling).
However, for architectural modeling (deployment diagrams and the like), UML requires a degree of precision that is not always possible in early stages. Here C4 models has established as a convenient and flexible alternative. But C4 relies on UML for the OOP design discussion. There is simply no alternative that allows to easily show classes and interaction between them, and that would be sufficiently widely known.
Conclusion: In an agile context, don't get misguided thinking that UML would require an exhaustive up-front design. Don't use it as for visual programming either, slavishly replicating details of the code. But use it as a communication tool to highlight key ideas and allow everyone to grasp the design and contribute productively.
发布评论
评论（1）
UML 可以在敏捷环境中以轻松的方式使用。关键是要清楚其目的以及您对项目建模的期望。
事实证明，类图和序列图非常适合帮助团队讨论关注点。它可以清楚地表达代码中不明显的想法（或分散在许多源文件中）。
例如，Scott Ambler 写了很多关于基于 UML 的敏捷建模的文章。当然，您不会使用它来生成包含所有类和所有属性的详尽模型。但是您将使用一些相关的类来勾画核心，并且只使用一些在讨论中重要的属性（Ambler 说“刚刚足够”建模）。
然而，对于架构建模（部署图等），UML 需要一定程度的精确度，而这在早期阶段并不总是可能实现。这里 C4 模型 已成为一种方便且灵活的替代方案。但 C4 依赖 UML 进行 OOP 设计讨论。根本没有其他选择可以轻松地显示类以及它们之间的交互，并且可以被充分广泛地了解。
结论：在敏捷环境中，不要误以为 UML 需要详尽的前期设计。也不要将其用作可视化编程，盲目地复制代码细节。但可以将其用作沟通工具来突出关键想法，让每个人都能掌握设计并做出富有成效的贡献。
UML can be used in a light way in an agile context. The key is simply to be clear about its purpose and what you expect from modeling in your project.
Class diagrams and sequence diagrams are proven to be good candidates for helping teams to discuss points of concerns. It can express clearly ideas that are not obvious in the code (or scattered across many source files).
Scott Ambler for example wrote a lot on agile modeling, based on UML. Of course, you will not use it for producing an exhaustive model with all classes and all properties. But you'd sketch the core with some relevant classes, and only a few properties that matter in the discussion (Ambler says "Just barely enough" modeling).
However, for architectural modeling (deployment diagrams and the like), UML requires a degree of precision that is not always possible in early stages. Here C4 models has established as a convenient and flexible alternative. But C4 relies on UML for the OOP design discussion. There is simply no alternative that allows to easily show classes and interaction between them, and that would be sufficiently widely known.
Conclusion: In an agile context, don't get misguided thinking that UML would require an exhaustive up-front design. Don't use it as for visual programming either, slavishly replicating details of the code. But use it as a communication tool to highlight key ideas and allow everyone to grasp the design and contribute productively.