您为ASP.NET应用程序创建了哪些UML图？

Question

我在一家中型公司担任高级开发人员，并致力于开发相当大的项目（至少1年以上）。 这里的大多数架构师认为创建UML图并不能证明所涉及的时间是合理的（尽管我们总是有一个ERD和一些非正式的流程图，所有项目都有一个图表）

我希望至少为我工作的项目创建UML图。 根据我的快速研究，似乎有以下内容：

1. 用于创建逻辑模型 - 对象角色模型（ORM
2. 用于创建物理模型 - 组件，类，序列，活动
3. 对于数据库模型 - ERD

问题：

1. 您在公司中创建了哪些UML图？
2. MS Visio是否有能力创建上述所有图表？
3. 是否根据正在开发的应用程序的类型选择UML图？

Answer 1

＃1您在公司中创建了哪些UML图？

我们使用UML定义的整套图表。 我们特别大量使用用例图，类图，序列图和状态机图。

＃2 MS Visio是否有能力创建上述所有图表？

确实如此，但我们通常不会使用Visio，因为有很多工具更适合这项工作。 就个人而言，我赞成允许我快速创建图表的工具，没有太多麻烦和麻烦。 强制执行UML规范的工具（或者更糟糕的是工具供应商对规范的解释）的工具让我烦恼。 我发现特别有用的工具之一是Pacestar的UML Diagrammer 。

＃3是否根据正在开发的应用程序类型选择UML图？

UML可用于描述任何应用程序的各个方面。 但是，应用程序的性质会影响您选择使用的图表的类型和数量。

这里的大多数架构师都认为创建UML图并不能证明所涉及的时间是合理的

UML图不需要花费太多时间来创建。 关键是通过开发“足够好”以满足您需求的模型来避免收益递减。 正如我上面所暗示的那样，我将我的建模工作集中在捕获系统的显着方面，而不是严格遵守UML规范。 此外，我毫不犹豫地使用非UML图表（或简单的文本）来模拟系统的各个方面，如果这样做，我可以更好地传达感兴趣的系统方面。

Answer 2

我使用UML是因为它是在90年代发明的，并且已经在大大小小的公司中用于各种各样的目的。 我将UML用于两个基本目的：作为思维的便笺 （有时我不知道我的想法，直到我看到我画的东西;）以及记录和交流设计的方式 。 这是我如何使用它和我的一些经验法则。

当其他工具不足以进行可视化/建模时，我使用UML。 因此，如果您使用的是SQLServer数据库，则可以使用内置设计图并将其打印并粘贴到文档中。 这里不需要UML。

在考虑设计问题时，我经常从一个墙到墙的白板开始，一旦设计结晶，我转向UML图表（或从显示器到墙壁来回移动）。

JavaScript和Ajax开发 。 工具和可视化支持很弱。 我使用UML进行思考并展示复杂JavaScript应用程序的高级设计。 （如果您正在使用Java应用程序，则可以使用大多数Java IDE中内置的工具来可视化您的代码。另一方面，如果您正在使用JavaScript应用程序或使用不良工具，那么这很难做到，所以UML可以填补空白。）

基于Web的应用程序的信息体系结构和导航 。 我使用UML在网页上显示网页，它们的关系和信息组件。 这同样适用于任何类型的GUI中的屏幕（它曾经被称为用户体验模型）。 我在基于Web的应用程序中使用REST URL。 所以我注释我的页面对象以显示实际的REST URL。 这样，我正在考虑通过REST部分，因为我正在布局页面。 根据我的经验，这是最有用和最少使用的图表类型之一 - 也许是因为它不是标准的。 它捕获信息体系结构（作为页面/屏幕集合体验的域模型）和应用程序的概念作为一组可导航视图。 通常，最接近用户的此模型与应用程序域模型或数据库模型之间存在不匹配。 能够拥有这个模型可以解决问题。 我参与了每个人都有自己的应用程序模型的项目：可用性人员，开发人员，数据库人员，企业架构师。 但没有人拥有正确的模型，用户体验模型充实了他们没有看到的东西。

基于代码的模型 。 我使用Java并对代码库进行反向工程并创建图表来记录设计。 但是，因为Java工具非常成熟，所以我很少需要进行逆向工程来理解代码。 我正在使用廉价的Enterprise Architect，它允许您对新代码进行反向工程，并使用基于旧代码的UML图表进行同步。

我将所有这些不同的图表放在一个项目中，它将系统的总体设计描述为一组视图 。 我还将我的UML项目导出为XML并将它们存储在我的版本控制系统中。 图表在Intranet上发布并插入到文档中。

组件图，永远不会。 如果我想描绘组件，我只需使用类图并使用构造型注释它：page，view，table - 来表示我正在描绘的对象的类型。 这让我很简单。 我大量使用刻板印象 。 它们允许我基本上创建自己的图表类型，但仍坚持使用大多数类图。

我不经常使用序列和活动图 ，但它们有时是必不可少的和强大的。 在计算对象的交互时，设计阶段的序列图。 交互越复杂，您就越需要序列图。 （当序列图太复杂时，这个事实可能表明您需要简化设计。）我发现序列图在逆向工程我继承并需要快速加速的新项目时最有用。 我发现他们可以在理解系统方面给我一个竞争优势。

最后，我倾向于选择准物理模型 。 模型基于要写入的实际代码或实际系统，但有些抽象和调整用于通信目的。 介于“架构宇航员”的通风抽象和复杂的基于代码的模型之间，它们具有太多的细节，而且价值低于IDE的大纲视图。

所以总结一下。 当需要更好的可视化和其他工具不足时，我使用UML进行思考，记录和交流设计。

Answer 3

前言

我认为UML用例图对于映射应用程序的整体用户和功能区域非常有用。 从技术上讲，这是业务分析师的工作，但是如果不存在或者这个细节水平不存在，那么这项工作只需要很少的时间来完成，并且具有巨大的价值，可以让您全面了解解。

序列图对ASP.NET开发也非常有用。 它使用例图中高级视图的组件易于分解并变为真实。

1.您在公司中创建了哪些UML图？

没有。 UML不是BAs，开发团队等等了解我目前工作的地方。 然而，考虑到我们所做的开发类型，价值确实不存在：快速和中等规模的战术解决方案。

2. MS Visio能否创建上述所有图表？

是。 http://softwarestencils.com/uml/index.html

我建议你考虑一个允许UML的工具 - > Code Gen http://www.visual-paradigm.com/

3.是否根据正在开发的应用程序类型选择UML图？

这是一个混合。 UML是一组工具，可以以适合用户的任何方式使用。 不同的图表类型（行为，结构和交互）及其子类型具有不同的目的。 经过多年与UML的交易（自90年代末以来），我几乎只看到了类，用例和序列图中的价值。 除此之外，它只是语义超载，而且我参与的项目价值不大。

Answer 4

在对象模型图之后，我发现用例图是最有用的。