2、任务流程图通常指的是确定了业务流程图中某一固定主体的具体操作流程图，通常是业务流程图的简化版。
3、页面流程图
总结：任务流程图注重不同系统之间的交互和逻辑关系；任务流程图注重某一个具体的任务操作流程。对于一个产品来说，发现已有流程中的问题，或者是创造一个逻辑严谨、操作简便的流程图尤为重要，业务流程图示根据任务流程图梳理出不同角色和不同状态下的呈现效果，页面流程图是对业务流程图的聚象化体现。
2、权限划分--用例图
a：用例图（Use Case Diagrame）：描述了人们希望如何使用一个系统，将相关用户、用户需要系统提供的服务以及系统需要用户提供的服务更清晰的显示出来，以便使系统用户更容易理解这些元素的用途，也便于开发人员最终实现这些元素。
b：为什么要画用例图--用户并不关心系统的实现和内部结构，只关心产品所呈现出来的外部特征动态。而用例图恰好就是描述软件产品外部特性的视图，它从用户的角度而不是从开发者的角度来描述需求，分析产品的功能和动态行为。
c：用例图包括三方面内容：参与者（Actor）; 参与者、用例之间的关系，用例（Use Case）;。用例图模型如下图所示，参与者用人形图标显示，用例用椭圆形表示，连线描述之间的关系。
a：参与者：
1、参与者是系统外部的一个实体，它以某种方式参与了用例的执行过程，在UML中，通常用名字写在下面的人形图标表示。
a：真实的人，即用户
这一类是最常用的参与者，几乎在每个系统中。在命名这一类参与者时，应该按照业务而不是位置命名，因为一个人有可能有多重身份。
比如：汽车租赁公司的客户服务代表，通常情况下是客户服务代表，但在她有租赁行为时，就变成了客户。因此，按照业务而不是位置命名可以获得更加稳定的参与者。
b：其他的系统
在有的系统中，还需要建立与其他系统的接口，依然以汽车租赁系统为例，它可能要与外部应用程序建立联系，比如：说外部信用卡应用程序，这时候外部信用卡应用系统就是一个参与者。
c：可运行的进程
以时间为例，当经过一定时间触发系统中的某个时间时，时间就成了参与者。比如：在汽车租赁系统中，到了还车时间客户仍未归还，系统便会提醒客户代表致电客户。由于时间不再在人的控制内，因此它也是一个参与者。
2、参与者间的关系：
对于一些参与者来说，它既扮演者自己的角色，同时也扮演更一般的角色，在案例图中用泛化关系来描述他们（此点与上一节类图中介绍的泛化关系类似）。
b：用例：
1、概念：是对系统的用户需求（主要是功能需求）的描述，用例表达了系统的功能和所提供的服务，描述了活动者与系统交互中的对话；以汽车租赁系统为例，客户向系统发出租赁请求，并向系统中输入数据（姓名等信息），系统响应活动者的请求，进行相应的处理，并且将结果返回活动者。
2、用例与事件流---用例分析处于系统的需求分析阶段，这个阶段尽量避免考虑系统实现的细节问题。但若要建立系统还需要更加具体的细节，这些细节可以写在事件流中。
事件流描述的是一个系统做什么，而不是怎么做，举个栗子，在汽车租赁系统中用例“用户登录”可以采取一下方法：
- 主事件流：客户输入自己的用户名和密码时，用户开始。输入的用户名和密码被提交后，服务器判断密码是否正确。如果正确，则用户成功登录，系统为其展示租赁页面。
- 异常事件流：用户名或密码错误，不能登录，用例重新开始。
- 异常事件流：在提交密码前，用户清楚用户名或密码，重新填写。
c：参与者、用例之间的关系
1、关联关系；--这是最常使用的关系，用带箭头的实线来描述。以汽车租赁系统中的“客户”参与这以及和他交互的3个用例（预定、取车和换车）为例。
2、泛化关系--一个用例可以被列举为多个子用例，这就被成为用例泛化，这与类间的泛化关系类似。在用例泛化中，子用例表示父用例的特殊形式，可从父用例处继承行为和属性。泛化关系的图形用空心实线箭头表示，箭头指向父类。
如下图所示是汽车租赁公司用例图中的用例“预定汽车”，该用例有两个子用例“预定大巴中巴”和“预订小车”。
