UML 太极建模口诀（建模向导与助手）

UML 太极建模口诀（建模向导与助手） 我从 1998 年起开始学习 UML、Use Case 和 RUP。过去十年来，一直听到国内外有人说，UML 太复杂，RUP 太复杂，果真如此么？ 对此，我很不以为然。 为什么我一直觉得 UML、RUP、Use Case 很简单呢？过去十年来，我也一直在思考这个问题。其实任何优秀的技术都是既简单，又复杂，你既可以说它简单，也可以说它复杂，关键看你站在什么角度。学习 任何一门技术，如果掌握了它的规律，看穿其本质，那么就会很简单。 我学习 U3 十年的经验大概可以用这 16 字来概括： 太极建模口诀 由外而内， 层次分明； 动静结合， 逐步求精。 这个口诀不但适用于 UML 建模，也适用于 Use Case 建模和软件架构设计。 主要有这么几个作用。首先，它揭示了 UML 建模的整体流程和步骤。我经常对我的学员们，以及我自己说，当你不知道下一步该做什么的时候，可以想一想、背一背太极口诀，看到阴，想一想阳，看到阳，想一想阴，UML 建模就这么简单。 其次，可以用它来检验 UML 模型的质量，防止出现结构性的设计问题，看看建模的结果是否完整，以免漏掉了重要的模型内容。 下面我们逐一解释一下这四句话。 由外而内 UML 建模的第一步是什么？划地为界，先设定我们的讨论范围。 有两个最主要的范围边界，业务边界对应于业务建模，软件|系统边界对应于软件建模（需求与设计）。 由外而内，由大到小，典型的边界依次是：组织（企业），部门，应用系统（软件），子系统（模块），构件，类 ... 外代表了组织、客户和用户，所以外决定内。UML 和 Use Case 建模体现了以客户和用户中心的设计思想。 层次分明 软件是分层的，模型也是分层的。层次可以有水平和垂直之分。 动静结合 UML 建模任务反复出现的一个主题是：动态行为与静态结构。 逐步求精 软件开发整体上是一个由粗到精的过程，从模糊到清晰，由抽象到具体，这是人类认识事物的一个基本规律。 软件需求可以从粗粒度到细粒度，系统设计可以从 OOA 到 OOD 再到 OOP。 UML 建模的基本流程和工件 太极建模参考了 RUP，依据阴阳太极的辩证思想，对 RUP 进行了裁减和简化。 业务建模 业务过程（用例）模型（动）、业务对象模型 业务用例模型 = 业务用例图（边界图、关系图） + 业务用例文本描述 + 业务用角图 业务对象模型 = 业务用例实现模型（动） + 业务领域模型（静） 软件需求建模 用例模型 + 补充规约（非功能需求） 用例模型 = 用例图（边界图、关系图） + 文本用例描述 + 用角图 OOA 用例分析模型（动） + 分析类模型（静）+ 非用例分析模型 OOD 用例设计模型（动） + 设计类模型（静） + 非用例设计模型 ... [ 本帖最后由 张恂 于 2009-12-18 12:00 编辑 ]

__________________ 软件本太极， 阴阳演乾坤。 知名的非著名 70 后独立软件工程顾问 迭代与敏捷过程改进、项目管理和 OO 技术教练 资深 U3（UML、Use Case、UP）、业务建模和需求分析、软件架构设计模式专家 太极软件工程（太极敏捷、太极建模、太极编程、太极项目管理...）创始人 系统分析/UML坛    敏捷圈 项目过程坛 项目管理坛 我的空间： 太极.敏捷.对象 我的主页： http://www.zhangxun.com Email: info # zhangxun.com