UML建模—用例与需求

用例与需求

1. 系统边界和参与者的确定
系统边界指的是所涉及的系统涵盖的范围到达的边界。
参与者指位于系统边界、与系统有着功能或行为上的关系的任何事物。
（参与者是指：在系统之外，透过系统边界与系统进行有意义交互的任何事物http:/www.umlchina.com）

需要注意的是：
a.参与者位于系统之外，不是系统的成分。
b.参与者可担当多个角色。
c.系统存在着直接参与者和间接参与者。从业务建模角度考虑间接，而系统建模则只考虑直接参与者与系统之间的有意义的交互行为（这里的有意义指所涉及的系统所需要关注的东西）。

参与者的确定思路：
..谁使用系统的主要功能？
..谁改变系统的数据
..谁从系统获取信息
..谁需要系统的支持以完成日常工作任务？
..谁负责维护、管理并保持系统正常运行？
..系统需要应付（处理）哪些硬设备？
..系统需要和哪些外部系统交互？
..谁（或什么）对系统运行产生的结果（值）感兴趣？
..时间、气温等内部外部条件
考虑以上各个方面基本能够确定所设计的系统所有的参与者。

2. 在参与者基础上列出事件
参与者确定了，那么参与者会通过系统执行什么样的操作，或者会发生什么样的行为？
事件分为外部事件和内部事件。
外部事件往往由于参与者的主动行为导致；内部行为往往是当时间、温度等变量达到某一条件时由系统触发。
列出事件可采用头脑风暴法。
表述的格式通常为： “主语＋动词(＋宾语)” 。如：会员+提交+用户名、密码

3. 识别用例
用例：用例实例是系统执行的一系列动作，这些动作将生成特定主角（参与者）可观测的结果值。一个用例定义一组用例实例。
用例的要点：
..可观测-->用例止于系统边界
..结果值-->用例是目标导向的
..系统执行-->结果值由系统生成
..由参与者观测-->业务语言，用户观点：从用户的角度考虑。
..一组用例实例-->用例的粒度

用例的命名： （状语＋）动词＋（定语＋）宾语
用例确定时常见错误：
..把交互的某个步骤当作用例
..把系统活动当作用例（而非用户视角）
..“四轮马车的错误”：CRUD：Create，Read，Update，Delete
如：把管理员的用户管理划分为四个用例，添加、修改、删除、查询。
系统建模蜕变成关系数据库的建模。“系统就是数据的增删改查”。这是常犯的错误，先关心数据的存储和维护，反而忽略了用户的目的。
注意粒度适度原则，如果CRUD不涉及复杂的交互，一个用例“管理××”即可。如果存在比较复杂的部分，如添加操作，可以把它独立成一个用例，extends-->管理用户用力。

4. 书写用例文档
略
5. 识别用例间的关系
用例间的三种关系：
（1）扩展(extends)：用例B extends 用例A，表示用例B是用例A在某种特定情况下可能会出现的扩展用例。例如：老王进城办事，2小时就可以回去，在这2小时内内急时就会去上厕所。上厕所用例是进城用例的扩展，因为不上厕所老王进城办事也可完成。
（2）包含(includes)：用例A includes 用例B，表示没有了用例B，用例A本身也就不完整了。例如：还是老王进城，他从海南来北京办事，3天才能回去，那么这种情况下进城用例与上厕所用例的关系就应该是包含关系了。
（3）泛化：泛化关系指的是同一业务目的的不同技术实现。例如：老王进城，他可以坐飞机，可以坐火车，还可以走路，那么进城用例就泛化为坐飞机、坐火车和走路三个用例了，它们之间存在层级关系。
总的来看，扩展可以“冻结”基本用例以保持稳定（因为扩展用例通常是不确定的）；包含可以提供公共交互，提高“复用”；泛化是同一业务目的的不同技术实现。用例之间除了上述三种关系不再有其他关系，用例之间不能通讯。

类图

用例图描述了系统的外部接口、系统与参与者的交互行为；类图则描述系统的运行机制与内部协作关系。

分析类图的步骤：

一、识别类及其属性

从用例文档中抽取名词，分析这些名词，从中识别出哪些名词是类、哪些名词是类的属性。

分析中需要注意甄别：去除冗余的同义词；去除系统责任之外的名次；明晰模糊名词；排除行为性名词。

二、审查属性

（1）属性要在系统责任之内

（2）某一个类的属性应该只描述这个类的对象的特征

（3）同一个类的属性之间不能出现交叠

（4）对于具有复杂结构的属性可考虑建立新的类，再与原类形成关联

三、确定类之间的关系

1. 泛化

类之间的关系包括泛化(——|>)、关联(——)和依赖(------à)三种。

泛化指的就是继承关系，它是从父类（超类）的角度来讲的。

泛化的特征：

（1）is-a原则：子类是一种超类。所有子类都必须是超类的成员。

（2）100%原则：超类的定义（包括方法和属性）都不必须100%符合与所有子类。

泛化的缺点：

（1）超类的改变会影响到子类；（2）多重继承会引起命名的冲突。

怎样识别泛化？

（1）根据领域知识：如，生物>动物>哺乳动物>猫科动物>虎

（2）自上而下

含义：现在已经定义了一个类，分析发现这个类的对象有的具备一部分属性，而有些对象又具备另一些属性而没有这部分属性。这时可分解只属于部分对象的属性和操作形成子类。自上而下就是指由父类分解得到子类。

（3）自下而上

含义：与自上而下相反，自下而上指从子类中提取共有的属性和操作形成父类。

（4）考虑领域范围内的复用

如现钞取款机类，为了方便复用，可从中抽取出取款机类，再让现钞取款机类继承取款机类。

审查泛化

（1）是否同处一个领域

例如，温度、质量、高度、压力等量都由实数表示，但是不能把它们设计成实数的子类。

这是一种典型的泛化误用，“见人就叫老爸”！这样的后果：两个领域的类高度耦合，父类的子类无数，子类里的属性和操作无数，隐藏着巨大的危险；如果需要再用另外的操作时，还得再认一个老爸。

（2）子类之间的差异是否可以超类的属性值的不同来加以区别

这可以避免定义过多的子类而是问题复杂化。例如，人作为父类，再定义了中国人、美国人，其实这种差别可以通过在人这个类里添加一个国籍属性就可以实现了。

（3）如果子类没有自己特有的属性和操作，则取消这个子类的定义（子类上移）；如果超类只有一个子类，则取消掉超类（超类下移）。

2. 类之间的关联

关联的含义：通过属性来表示一个对象对另一个对象的静态依赖关系。

首先，关联是对象间的；另外，关联是一种静态的关系，而不是通过操作。

关联的三种表现形式：

连接：—— 最弱的关联，表示两个类的对象之间有导航关系，即。

聚合：A◇——B 表示对象A包含一个对象B。

组合：◆—— 强语义耦合，如果整体消失则部分也消失。

聚合与组合比较：

（还没有找到合适的例子来解释）

审查聚合或组合

（1）作为部分的对象的属性有多少。比如汽车，单独定义一个轮胎类，汽车◇——轮胎。这里轮胎类里的属性过少，反而使设计不够清晰。应把轮胎合并到汽车类中。

（2）业务上是否有真正的聚合关系？


6. 对用例进行优先级排序