上次我们初步了解了UML、这次我就带大家详细说下UML10个图的第一个图、用例图。
用例图就是对系统进行建模、把系统看成一个黑盒子、不考虑内部结构、只考虑接口、分析各个阶段开发的工作、从用户的角度描述功能、画出各个功能的执行者、强调谁在使用系统、主要用来描述“用户、需求、系统功能单元”之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。
用例图
【用途】:帮助开发团队以一种可视化的方式理解系统的功能需求。
用例图所包含的元素如下:
1. 参与者(Actor)
表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
2. 用例(Use Case)
用例就是外部可见的系统功能,对系统提供的服务进行描述。用椭圆表示。
3. 子系统(Subsystem)
用来展示系统的一部分功能,这部分功能联系紧密。
4. 关系
用例图中涉及的关系有:关联、泛化、包含、扩展。
如下表所示:
a. 关联(Association)
表示参与者与用例之间的通信,任何一方都可发送或接受消息。
【箭头指向】:指向消息接收方
b. 泛化(Inheritance)
就是通常理解的继承关系,子用例和父用例相似,但表现出更特别的行为;子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为,也可以重载它。父用例通常是抽象的。
【箭头指向】:指向父用例
c. 包含(Include)
包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。
【箭头指向】:指向分解出来的功能用例
d. 扩展(Extend)
扩展关系是指用例功能的延伸,相当于为基础用例提供一个附加功能。
【箭头指向】:指向基础用例
e. 依赖(Dependency)
以上4种关系,是UML定义的标准关系。但VS2010的用例模型图中,添加了依赖关系,用带箭头的虚线表示,表示源用例依赖于目标用例。
【箭头指向】:指向被依赖项
5. 项目(Artifact)
用例图虽然是用来帮助人们形象地理解功能需求,但却没多少人能够通看懂它。很多时候跟用户交流甚至用Excel都比用例图强,VS2010中引入了“项目”这样一个元素,以便让开发人员能够在用例图中链接一个普通文档。
用依赖关系把某个用例依赖到项目上:
然后把项目属性的Hyperlink(链接)设置到你的文档上;
这样当你在用例图上双击项目时,就会打开相关联的文档。
6. 注释(Comment)
包含(include)、扩展(extend)、泛化(Inheritance) 的区别:
条件性:泛化中的子用例和include中的被包含的用例会无条件发生,而extend中的延伸用例的发生是有条件的;
直接性:泛化中的子用例和extend中的延伸用例为参与者提供直接服务,而include中被包含的用例为参与者提供间接服务。
对extend而言,延伸用例并不包含基础用例的内容,基础用例也不包含延伸用例的内容。
对Inheritance而言,子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系;
一个用例图示例:
表达的用例,下图的表给大家提供一个参考:
用例(Use Case)——粒度
用例图粒度的粗细、就是用例图描述事物是否详细、越粗就宏观、越细就越微观、那用例图粒度粗好还是细好?
以最熟悉的登陆作为例子,用户登陆,这是一种粒度的描述;用户输入用户明、用户输入密码,这是另一种更细的粒度的描述。那么粒度是否需要细化的这个地步呢?需要的,因为用例粒度越细越好。假如我们觉得罗唆没有给出细粒度描述,只给出“用户登陆”这样的粒度描述,那么后期的设计开发怎么来处理这个“用户登陆”呢?这时候,经验主义跑出来说,当然是处理用户名和密码了;没错,这在大多数情况下的确如此,可这种经验主义的想当然合理吗?如果客户的意思还包括输入验证码,还包括USB锁安全认证,那么从一句“用户登陆”又怎么能反映出来呢?
反之还是登陆窗体、写的非常详细、但是其实根本不用写那么详细、写的多反而让用户头疼…………其实粗细的好坏没有绝对的、如果粗不能描绘清楚、那就粒度就细一点、如果觉得细乱、那就分层、这样用户好理解了、也没有漏掉用户的意思。
————最近长智齿……牙疼、请我吃饭的能推后一个月不……———chenchen