参照“与小婧同行”的资料整理而成
一、流程图
1.关于角色
跨职能流程图中这个泳道的意义是十分重要的，特别是在多角色参与的业务流程中。如果你将所有的角色都写在活动里，不仅画起来可能会有缺失，阅读性和理解性也不强。
现做干系人分析，制作干系人登记册，这些内容都有助于我们梳理业务流程。而且你的业务流程图不仅仅是和开发沟通，还要用于和客户沟通，在这个层面上说，倾向于使用业务角色作为泳道的部分。
并且我一直觉得信息系统的另外一大亮点就是，可以进行流程的优化。如果你不能将流程图画清楚，那么怎么做优化呢？
另外，进行角色的强调，也可以方便该角色的人关注在跨流程的业务中，自己执行的活动是不是这些。有助于BA进行进一步的分析。
2.关于阶段
在跨职能流程图中可以划分阶段，这个是可选的。好好的分析整个流程是否是可以划分阶段的。比如还书的流程，是否可以划分为：读者还书、逾期罚款、还书成功三个阶段？这样在讲解业务的时候，可以描述，当读书没有逾期时，逾期罚款的阶段可以跳过，直接还书成功。
3.关于流程分层
和我们做项目计划WBS一样，流程是可以分层的。对于一些很复杂的流程来说，我们最好分层来绘制。
根据小婧的经验，建议以下流程可以进行分层：
有子流程。这个很好理解。比如我们的还书流程中的预期罚款是个很复杂的子流程，包括设计财务系统等等多角色参与的，就可以将其“封装”为子流程。
可以复用。这里的道理和系统架构设计是一个道理，对于会被很多流程使用到的一个流程部分，可以单独“封装”后，进行调用即可。
4.关于流程和活动节点编号
小婧建议大家对每个流程都起个单独的名字以及简称，最好是英文的，可以使用驼峰命名法。比如：还书流程 Return Book，简称RB。然后对于每个活动节点以流程缩写打头，并且进行编号，如：RB_01 XXXX。
二、用例图
我们在画用例图的时候要尽量用业务的场景、业务的语言进行描述
比如：
图片源于与小婧同行
用例图与活动图的关联
其实我们可以从活动图很方便的绘制出用例图。
首先将泳道中的角色做一遍筛选，选出非系统的最终用户。
然后对这些用户进行抽象，比如有的活动图比较系会分成：科长、主任，但是其实他们都是在执行审批，那就可以在用例图中抽象成一个角色：领导。
然后将活动图中的活动节点进行抽离，非判断的基本上都属于用例，但是也要进行归纳和抽象，判断的部分需要你确定一下这个判断是系统做的，还是人做的，如果是人做的那就加到用例里。
比如：之前我们的还书过程中的逾期判断，是系统判断的，还书处的人其实只是收罚款而已。
三、类图
我们讲面向对象的需求分析，其中一个核心就是进行对象分析，分析的结果就可以用类图进行展示。类图肯定要讲什么是对象，讲什么是对象就要讲对象与属性的区别，什么时候这东西是做对象的，什么时候是做属性的。
举例：
我们都知道，动物有很多类型，比如鸟类。
我们如果是研究鸟类的话，就会以鸟类作为一个对象。
在研究具体动物个体时，可以将麻雀、鸡作为一个对象，翅膀、眼睛、爪子、羽毛都属于属性。
而如果你在研究某个具体特性的时候，比如飞行特性，就可能会需要将翅膀作为一个对象。
所以一个东西是对象还是属性，主要取决于你的业务目的。
回归到我们的实战案例上来，在山竹图书馆管理系统中，有哪对象类，这些对象类的关系是怎样的？如何来画类图？
其中有几个原则：
没有实现：我们的分析还是要以业务为主，做类图也是如此，可以作为SA或者开发的有效输入，但不是抢他们的活。所以我们画的类图不需要有调用方法、不需要有任务技术的描述。
大类不拆分：有的大类，比如鸟类，不要过早的拆分，只需要标明和麻雀的泛化关系即可。这样方便用户理解，有层次感。你要记住我们不是在做数据库设计，所以不需要把大类做过细的拆分。
我们的主要职责是理清业务对象的关系。
子类不合并
同类不抽象：抽象难免会涉及到技术实现的部分，还是那句话，这部分还是留给SA来做专业的设计。
总之，记得类图可以拿去给用户做讲解，也可以作为SA设计的依据，必须以业务为主，以业务为重。
画类图时根绝一下步骤进行：
首先，需要明确有哪些类。
读者和图书这个是很明确的。
但是我中间加了个“借阅证”的类，主要是考虑到一方面图书馆肯定是认证不认人的，另外一方面，我们的系统也包括了办理新借阅证的过程，所有的记录都是记录在借阅证中的。
同理，如果你是电商系统，用户可能分为VIP、普通，但是他们肯定都会关联一个账号。
“图书信息”这个类是我另外加上的，因为图书馆在采购图书的时候，不可能一本书就买一本（大部分情况下），所以我就加了这么个类。
其他的类大家应该都比较清楚了。
然后，需要明确类之间的关系。
显然，借阅证与读者的关系是：一个读者有且只能有一个借阅证，而每个借阅证肯定只能属于一个读者。
实际在阅读类图的时候需要分不同的对象。
网友评论