首先和大家说声对不起，由于本人第一次重头开始做项目，所以期间遇到了好多好多，多种多样，样样都能难道我的问题，在这里还要感谢扬哥的大力援助，让我一瘸一拐的终于走到了又一个革命性的阶段——设计阶段，说来也有些惭愧，之前由于我对基础知识的了解少之甚少，所以造成对好多知识点理解有偏差，所以我从上周四开始，我就每天抽出几个小时的时间，对UML（Unified Model Language）和RUP（Rational Unified Process）的基础知识有了更全新的理解，所以今天（2014年4月2日修改）对之前写的东西进行修改重构，我这里先说一下RUP吧，因为RUP是软件工程的过程，先给大家看一张图片
RUP中包含了很多非常有效的一些经历过验证的开发方法，其中有六个最佳的有效部署，即迭代开发，需求管理，使用基于构建的体系结构，可视化的软件建模，验证软件的质量，控制软件的变更。图片中的横轴代表了制订开发过程时的时间，体现了过程的动态结构。它以术语周期（cycle）、阶段(phase)、迭代（iteration）和里程碑(milestone)来表达。纵轴表现了过程的静态结构：如何用术语活动（activity）、产物(artifact)、 角色(worker)和工作流(workflow)来描述。我们做的需求分析设计从阶段来说，应该属于初始阶段与细化阶段，从工作流来说应该属于需求工作流与分析设计工作流，我们做软件只要遵守RUP，就可以把大多数风险控制在可控的范围内，并且提高效率，按阶段完成开发任务。
首先就是结构问题，我为什么总是在这里强调结构，但是有好多有经验的程序员，大概也都了解，结构没有什么特殊的要求，只要能让程序员看明白就行了，但是MDA（模型驱动架构，有不懂的可以谷歌一下）是未来的趋势，所以希望以后建模都能形成一定的格式，这样，到自动生成代码阶段就不会遇到这样或者那样的问题了，所以我希望大家也能按照固定的结构去画图。我是这样设计的结构，首先在上一步的分析中，我们写了分析用例，找到了支持软件运行的几大模块，我将模块作为一个最上层的包（就是一个文件夹），然后将模块下的用例分别作为一个包，在这个包下面去画设计模型。
说到分析设计建模，无外乎就是把“Somebody do something”的这种模式用一种客户和程序员都能看懂的方式表达出来比如生活中的一些简单的例子“客户取款”、“商家卖东西”，我们做的系统也不例外，拿这个题库管理模块为例，首先要找到系统的使用者，然后使用者能做的什么事，我们姑且将这个疑问放一放，谜底将会在之后的描述中被揭开。
我们揭晓来了解一些用例分析的注意事项，首先第一点，就是一个用例只能描述一件事，有的人习惯用“万能” 用例，也就是所谓的“上帝用例”，我并不推荐，这样会使人误解的，就好比你去饭店点了“水”，这个水的概念可以是矿泉水，可以是茶水，也可以是饮料，所以你要定位，给我一杯“白开水”。第二点，简单原则，通俗易懂，能简捷准确的说明某项功能，不给别人任何瞎想的空间，我再举一个反面的例子，就好比“两元店”里的宣传语“买啥都两块，两块钱你买不了吃亏，也买不了上当”，但是你进去之后发现，并不是像广告语里说的那样买啥都两块，还有贵一些的物品，第三就是唯一性，每一件事或者每个场景只能出现一次，但是可以使用“引用”的方式进行组合。
结构图形
其实对于需求的分析就好比是玩汉诺塔，拼n阶魔方，把n阶通过一定的方法进行降阶、拆解变成n-1阶，最后变成一阶并解决问题，从宏观到微观。
有时候我们会发现在需求定义的场景中，有一部分场景，他们的工作背景和工作方式都比较类似，彼此之间有着某种特殊的联系，那么这些用例就可以组成一个封闭的区间这就是用例的边界，我们有时候会用参与的角色来区分用例的边界，例如，我们要做的这个题库管理模块，“测评师”可以进行“添加题目”、“删除题目”、“查询题目”、“修改题目”这几个用例就可以看做是一个边界，因为他们都是对题库进行操作。如下图
所以我们有时候可以把这个边界抽象内聚成一个用例即下图所示，也就是我之前说过的设计用例。当然里面的用例也就是我前面说过的实现用例。
当然我们根据需求“测评师”可以对“题目分类”进行“增删改查”操作，所以这又是一个边界。
这时候我们先只考虑“做什么”，等到下一步在研究“怎么做”，先找出“做什么”，才能进行下一步“怎么做”。所以我们做出了下面的设计模型，实现为设计用例，虚线为实现用例。
实现的为设计用例，虚线的为实现用例
说完了“做什么”，接下来就是“怎么做”，这里我们使用了一种UML的经典图形Activity（活动图），我这里面所画的图全部都是用EA画的，大家还可以试试Rose，还有VS201*，当然我认为用EA话Activity是最爽的，因为EA中有一个叫做甬道的东西，可以直观的看出参与者和系统之间的交互，活动图说白了，就是把用户和系统进行的交互活动用线穿起来，必须有起始点（这里别忘了，注意一下）。你可以把自己想象成用户，然后怎么操作，系统应该怎么处理我的操作。这样就可以很容易画出下面的活动图。下面的活动图就是对添加分类操作进行的设计。画活动图还有一个重要的因素就是最后要推导出相应的对象（后面构建阶段可以用于数据库表格的建立，还有例如java中的bean对象），这里我们推导出了《题目分类》这样一个对象，同时我们要把推导出的这个对象加入到对象模型中。
这个是题库管理模块中题目分类管理中的添加分类的实现用例的活动图。仅供大家参考，禁止用于商业用途。分析设计建模就先聊到这里，如果大家发现我哪里说得不对，可以尽管留言，我会继续改进的。