UML图是否是模拟软件的唯一方法

时间:2011-10-27 05:08:24

标签: uml class-diagram

我经常在一张纸上绘制数据流。甚至我的小工具的计划都是在纸上完成的。

存在UML。 问题是 - 我不喜欢它。我使用过的所有工具(Visio和许多在线编辑器)都不灵活。使用铅笔,您可以轻松地绘制形状并连接它们,描述它们。

您可以建议以最快,最自然,最简单的方式创建数据流,序列图等图表,除非计算机上的不是纸张< / strong>:)

****评论中发布的有用链接:** SO Link #1 SO Link #2

现在我对 2 事情感到好奇,其中一个很久以前就出现在我脑海中了:

1) Mindmap - 我前段时间尝过,非常喜欢它但被遗弃了。不过会再试一次

2)白板。这将是最简单和最自然的方法,除了拍照并将其存储在计算机上的某个地方会使这个过程重复和枯燥。

有没有其他有趣的想法?我真的很想听听其他人用来设计他们的软件及其进展的方法。

非常感谢!

7 个答案:

答案 0 :(得分:4)

为什么你要手绘UML,无论是在纸上还是在电脑上?

我同意你需要一个模型来代表设计。但即使在大约500个人月的大型项目中,我发现只有3-4个序列图真正重要,并且有可能在应用程序的整个生命周期中存活。这3-4个序列图(以及表示其静态时间关系的类图)通常代表应用程序的高级设计。

或者,这样看:

任何体面的企业应用程序都不会有20个不同的呼叫流程。将有一个或两个通用(或抽象)调用流程,所有具体用例都实现。我们来看一个简单的Struts / EJB应用程序。通用流程就像 - 一个动作类调用一个验证器,然后调用一个无状态会话bean,后者又调用一个域类,它将调用一个DAO。应用程序的所有用例只是使用特定于该用例的具体类来实现此流程。

你同意吗?

如果您不这样做,我希望了解有关20个不同呼叫流程的应用程序,并在首次发布后存活5年。

如果您同意我的意见,即使是包含数千个类的大型企业应用程序,我们也可以深入到3-4级和序列图。为什么绘制和维护这3-4个图表是一件大事?

您可能会说要记录所有用例以进行培训或记录。在我真正的企业软件世界的14年经验中,我不记得看到“维护”的UML文档。首先,好的文件难以制作,而且经常没有找到。其次,它们大多数时候与代码不同步。我的大部分经验都是大型银行,保险公司,汽车公司等。这些环境太忙乱,资源有限(真的吗?我们是在谈论银行吗?是的,很难相信,但却是真的)“维持”良好文档。

我建议我们摆脱UML吗?

没有。我们需要可视化模型来表示复杂系统。在处理视觉效果时,人脑似乎处于最佳状态。 visual cortex负责处理视觉图像,是人脑中最大的系统。

那么,轻松生成和维护UML模型的合理解决方案是什么?

  1. 可能我们最好使用当前的UML工具来绘制3-4个高级UML图。如果您不喜欢使用它们,请查看下面的选项3.
  2. 对于下一个抽象级别的图表(任何有用的模型应该具有不同的抽象级别),从源代码生成UML。您可以生成类图和序列图。
  3. 在这个敏捷方法的时代,为什么不编写shell类并生成3-4个高级UML类和序列图呢?这样就根本不会有任何UML维护。
  4. 源代码是事实。

    你能反对这种说法吗?如果没有,为什么不从源代码本身生成模型?顺便提一下,我并不是建议往返工程。我只是建议单程旅行 - 从代码到模型。

    生成的UML有两个主要问题。

    1. 当我们手绘类图时,我们会显示场景中涉及的类之间的关系。大多数现有的类图生成工具允许用户将Java类(源代码)放入工具中,该工具会自动显示类之间的关系。这里的问题是,如何知道场景中涉及的类?
    2. 第二个问题是生成的图表的冗长。有一些工具可用于为场景生成运行时序列和类图。但是这些图表通常非常冗长并且破坏了模型的目的,其目的是突出重要方面并过滤掉不重要的细节。
    3. 良好的UML生成工具应解决上述两个问题。 Java域中有一些工具可以解决这些问题。请查看以下讨论:

      What tools should I use to visualize structure of my code

      Are there any tools for detecting architectural and design patterns in code?

      我希望我回答了原来的问题:

        

      有没有其他有趣的想法?我真的很想听听别人用的东西   设计他们的软件及其进展。

      我是运行时UML生成工具MaintainJ的作者,但我试图以客观的方式解决原始问题。欢迎您提出意见。

答案 1 :(得分:2)

有各种工具可以让您根据文本输入创建图表。有一些前期学习,你需要学习语法。然而,这并不难。一旦你有了,创建图表可以非常快。有一些缺点;在大多数情况下,改变布局/风格的能力有限。这取决于你是否喜欢他们的风格。

有越来越多的数字,这里有一些你可能想看的内容:

第h

答案 2 :(得分:2)

我喜欢使用白板和相机。为了获得更大的灵活性,请在白板上使用便利贴。

我使用ER图表(在白板上)对我的数据建模,并使用消息序列图表(在白板上)来建模数据流。我还将在白板上快速模拟UI页面。

除此之外,我使用Ruby / Rails在客户端编写服务器端和HTML / CSS / jQuery / JS。

答案 3 :(得分:1)

如果即使Visio不够灵活,我建议使用白板软件的数字白板或触摸屏。在一些住宿之后你可以使用一个简单的平板电脑(没有显示器) - 它们真的很便宜。

关于纯软件:我们正在尝试使用UML Lab实现“笔式”输入法,但它目前仅支持类图...

答案 4 :(得分:0)

我认为应该使用类图混合UML和代码。您使用类图(例如包,类等等)对您的体系结构进行建模,然后在代码和模型之间进行多次迭代编码您的业务。

我认为UML应该更多地面向代码,而不是专注于文本输入。

答案 5 :(得分:0)

标准语言(例如UML)的问题在于您必须投入大量精力来学习语言和建模工具。这些语言由专家联盟定义,例如OMG,提出了一种语言规范,适用于特定领域中设计问题的最大重叠。

为什么不定义适合您的需求和特定问题的语言?这些语言被称为域特定语言(DSL)。您不必投入学习复杂的语言,而是投入到完全符合您需求的语言定义中。

有许多方法支持DSL的定义。最普遍的是Generic Eclipse Modeling System (GEMS)。就个人而言,由于其多功能性和使用图形转换自动化工作步骤的可能性,我在GrGen方面获得了很好的经验。

答案 6 :(得分:0)

没有。还有其他各种方式。 UML只是一个选项。 Pen and Paper Prototyping也是一个很好的选择,它不必遵循UML。 思维导图是另一种很棒的方式。

对于更多自适应软件过程,鼓励使用UML尽可能减少。比如,练习敏捷或XP的团队倾向于使用UML,他们宁愿更多地依靠非正式手段来概念化软件。在一个僵化的结构化公司中,可以严格遵循UML。