## 产品设计体会(四七)——UML学习摘录(下)
接上回,下层的图描述的是一个用例内部的事务(用例内部不一定是“单个用例”内部,也可能有用例之间的关系),主要有:
Ø **时序图**(**顺序图**):描述事情变化在时间维度上的先后顺序,善于表达对象(比如多个页面之间)的交互。玩的好可以完全替代UC中对流程的文字表述。
[![时序图 举例](https://box.kancloud.cn/2016-04-22_571a0927b712f.jpg)](http://blufiles.storage.live.com/y1p3O4KBNpz6AUhC5w_FKZp98pRJsTCO_D0aOsWBd4sPz7ASfg-Zb5OUKuxtnUTmzqS4ivbUZxul2Q)
Ø **活动图**(比较接近传统意义上的**流程图**):描述各种动作如何引起系统变化,善于表达泳道较多、分支较多的情况。
[![活动图 举例](https://box.kancloud.cn/2016-04-22_571a0927c9353.jpg)](http://blufiles.storage.live.com/y1p3O4KBNpz6AWyDoV63XSkbB1yiF-KYeBYwEvsFFRwD_-GROo-y7zFKd7lTl6UnhO7cc0ipJocEoI)
Ø **协作图**:表达不同对象之间是怎么互相影响的,这个图团队里用到的不多,就不画了,理论上他和时序图是可以等价转换的,时序图关注交互在时间上的步骤,协作图关注交互过程中各个对象间的关系。
这些图我们都是用Rational Rose画的,它最好的一个点是可以在不同层次间的图穿透,比如从用例包穿透看到用例图,再穿透进某个用例看活动图,再穿透进活动图的某一步看具体的时序图。
很多时候多种图都可以描述同一件事情,只是从不同的视角去表达一个系统,选用哪个关键是看针对特定的系统,从哪个角度来描述更容易让受众理解。另外还有表述软件实施的**构件图**、描述硬件结构的**部署图**,暂时用处不大,遵循性价比的原则直接跳过了。
融入了UML标准图元素以后,一个功能模块的UC文档大约就是这样的:文档说明、类图+用例图(需求描述部分);一个个的UC,UC里包含时序图、活动图等等(需求分析阶段)。整块的需求规范化工作最近也在做,以后有机会再整体整理出来。
最后感慨一下Rational Rose真的太强大(建立了整个软件工程的RUP,Rational Unified Process,包括分析、设计、编码、测试、部署等等一切),想找一个轻一点的工具,折腾了半天Visio,发现总是缺点什么,谁有更好的方案?
- 前言
- (一)——变态吧,开始帖周报了
- (二)——数据分析
- (三)——性价比:做不做?
- (四)——需求管理
- (五)——有关流程
- (六)——再谈流程
- (七)——需求探针
- (八)——产品与项目
- (九)——关于学习
- (十)——团队合作
- (十一)——市场扫描
- (十二)——少而精
- (十三)——再说需求分析
- (十四)——做过的几个项目
- (十五)——PM、PD、UE与UI
- (十六)——Feature List
- (十七)——PD的几种文档
- (十八)——概念设计
- (十九)——UPA年会的流水账
- (二十)——有关改版
- (二二)——封闭开发
- (二三)——用户研究
- (二五)——当交互设计遇到敏捷开发
- (二六)——PD就是出来卖的
- (二七)——大产品设计
- (二八)——细节之文案
- (二九)——产品设计的五个层次
- (三十)——“体会”导读的思维导图
- (三二)——零散的体会
- (三三)——用户大会
- (三四)——土老板破冰必杀技
- (三五)——QA与测试
- (三六)——再理解“敏捷”
- (三七)——可用性测试
- (三八)——项目外包!=开发外包
- (三九)——CSDN专访精编版
- (四十)——销售渠道
- (四一)——用户创意无限
- (四二)——又是零散体会
- (四三)——说说评审会
- (四四)——项目外包不适合“敏捷”?
- (四五)——外行眼中的技术分工
- (四六)——UML学习摘录(上)
- (四七)——UML学习摘录(下)
- (四八)——资源战争与BRD
- (四九)——产品市场化
- (五十)——终点:Matrix
- (五一)——敏捷的估计与规划
- (五二)——MS Office使用心得
- (五三)——产品文档与规范
- (五四)——PD招聘广告词
- (五五)——项目Kick Off
- (五六)——《需求工程》培训记录
- (五八)——《项目化管理》培训记录