摘要：BoUML都收费了，argoUML半年没更新了，而startUML六年多没更新了，免费的UML工具里就数VP的社区版还不错了。唯一的缺憾就是输出图片有浮水印，虽说咱们也四处宣传VP，但输出的图片实在不方便。VP 9已经将浮水印贴满整个背景，影响导出图片的可读性。不过，SVG导出功能还在！(这是我唯一还在坚持VP的理由!) 我写了一段脚本，帮助去除VP输出SVG图片中的浮水印，并转成PNG。这个PNG转换的功能依赖于Inkscape，没有的话去SourceForge.net下吧。 注意安装后要把Inkscape的安装路径放在PATH中去。Inkscape支持命令行，如下: inkscape -f 阅读全文

摘要：在写这篇博客之前，把thinking in UML的这一部分又看了看。这一部分叫做UML的核心元素，也就是组成整个软件过程中的砖和瓦。我想说的是，在做完了项目，然后把书看过一遍后，再去总结，感觉在这个过程中对UML在软件过程中的应用的认识在一点点的加深，能映射到机房收费系统中去。这让我联想到了在做机房收费系统中的几个要注意的地方。首先就是关于用例粒度的问题，这个问题，在我们和七期开会的时候也讨论了，而且还很激烈。当时我们有的同学，一些的粒度很细，几乎一个insert语句就是一个类了。我想这样是不好的设计，因为如果细到这种情况，那么抽象也没有什么意义了。所以，比如好的做法是一个用例是一个类，这个 阅读全文

摘要：通过开发机房收费系统，从个人开发vb.net版到合作开发，自己对项目的认识也在一点点的积累着。当我们做过项目之后，再回头去看看那些关于关于面向对象、软件架构、面向对象分析的书的时候，那种感觉是很美妙的。接下来，我将用一个系列文章来讲述对UML在软件过程中的思考。我们在开发项目的时候，我们首先会想到需要分析，然后呢，会想到用UML中的用例图来捕获需求；接下来呢，我们会根据自己的需求分析，然后结合自己的用例图，就开始了对类的抽象；接着是对给类添加方法，接下来呢，我们最常用的会是时序图，用来表示一个个的用例实现，好象这一切都是自然而然的事，在对类进行抽象的时候，更象是一拍脑门”嗯，就是这样的... 阅读全文

摘要：一、用例图概述用例图，是一种客户与开发者之间可以沟通、理解的表现形式。可以认为用例图是开发者与客户之间的可视化契约。我认为最主要的一点就是，在这个用例模型中，一直是以用户的角度为主的，做为开发人员也要时刻站在用户的角度来看待整个系统。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的. 阅读全文

摘要：粗略地使用了一下VP-UML社区版，其UML绘图功能可以满足工作需求。重点是它的跨平台和UML 2.0的支持。1. VP-UML可以视为一个较为完整的设计工具，UML Drawing只是其中一项功能。因为主要用于绘图，所以先将UI设置到合适的视图下:2.从Use Case画起容易上手。就是关系的连线设计不太好，有时会感觉线条不在Action或Use Case上。如果是手动调整位置，程序会提示这个调整只是临时的调整，下次在移动对象时还会自动调整。如果需要固定调整后的结果，可以在选中关系后，点两边的图标，如下：单击是设置或取消固定，双击则是自动调整。3. 对于Class Diagram, 每一个类 阅读全文

摘要：最近读了《设计原本》，其中下面这句话，让我感触颇深: 设计师的主要任务乃是帮助客户发现他们想要的设计。以前，我就遇到过一件事。老板早上一来，递了张名片，就说这个老板需要我们给他们开发一套定制的进销存系统。下面要做的事，一定是要弄清具体的需求了。所以设计和需求分析应当是不断迭代的，或者是平行进行的，也就是所谓的共同演化模型。具体的需求如果把握准了，剩下就是如何分解问题、逐一求解，然后再串起来进行设计模拟，以评估设计。个人觉得Top-Down的方式在许多情况下都表现的不错。在<<设计原本>>，作者提到设计者应当有整体的规划能力，并且一个的设计往往比一个团队强。我对这句话的理 阅读全文

摘要：使用BoUML可以轻松绘制用例图. *注意扩展关系的箭头(扩展了谁?),详细的有关箭头方向，可以参考:http://blog.csdn.net/TangZhongxin/article/details/4640248有些书上的箭头方向都会指错，读的时候要小心! 阅读全文