第一步：从需求表述中找出用例，往往是动名词短语表示的抽象用例
第二步：描述用例开始和结束状态，用TUCBW和TUCEW表示的高层用例
第三步：对用例按照子系统或不同的方面进行分类，描述用例与用例，用例与参与者之间的上下文关系，并画出用例图
第四步：进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到结束的所有步骤列举出来扩展用例
B:项目用例与参与者分析
本项目采用权限管理方式进行后台维护，功能储存在acl_permission表中，通过设置用户角色来分配权限，我们可以给不同的用户分配不同的角色，也可以给不同的角色设置不同的权限，不同的角色下的权限是最大权限的子集，所以这里我们直接以最大权限做用例分析，主要功能有：
1对讲师的增删改查
2对课程分类增删改查
3对课程的增删改查
4对系统角色的增删改查
5对系统管理员的权限分配，增删改查
6对前台数据统计分析，查
7对前台订单购买数据，查
9对系统权限的增删改查
C：完整的用例图如下
3业务领域建模
A业务建模其实是一个从多方面描述系统的综合。大约要划分为四个方向：
1.是组织机构和人员模型。也就是信息化手段应用后对组织、机构和人员的影响和变化。包括工作内容，职责，以及因此带来的制度规范的变化。
2.是业务/处理模型，这里所谓的处理包含的是所有业务过程中的处理。例如把软件打包邮递出去，这个过程完全没有软件参与，但是它是整体工作流程中的一个环节。业务/处理模型，可以根据需要作层次化的细化，此处不再赘述。
4.环境模型。环境模型描述了软件系统所运行需要的环境。例如软件环境，OS,数据库，web服务器，也包括了软件的部署环境，部署安装方法。另外，不仅如此在某些软件中还要更加细致的描述环境环境。在这个时候，就必须把业务模型细化并和环境模型一起描述。例如3D软件中作一个宣染处理，总是要放在一个虚拟的场所中处理，每次处理既构成了一个渲染的处理步骤序列，也构成了用户未来观察3D软件制作出来的电影的每次效果观察。更广泛的对环境的描述，甚至还包括了行业规范，国家法规，技术标准等等一系列的东西。又或者是用户信息化素养，知识水平，意识等等，他们通常构成了软件应用环境的一部分，并进而影响到软件的功能，或者是那些隐形的约束。
B业务分析
本案例中主要通过user，role，permissiion以及userrole，rolepermission两张中间表来控制权限，以及权限下对讲师，课程，课程分类等进行增删改查，我们可以按照实际需求将上面最大权限动态分配到角色上面，然后将角色分配给user（管理员）以达到权限管理的功能。
主要实现功能是：
对平台讲师的增删改查，
对课程分类增删改查
对课程增删改查（以阿里云点播将表进行一对多，多对多的关联设计，课程对章节，章节对video等）
对权限管理
对前台数据展示，分析
C部分UML图（以权限管理五张表以及课程表）
4数据模型
user表
role表
permission表
userrole中间表
rolepermission中间表
course表
chapter表
video表
5概念原型
A概念原型
概念是人对能代表某种事物或者发展过程的特点及其意义所形成的思维结论，而概念原型是一种虚拟化的、理想化的软件产品形式。我们可以得到这样的公式：概念原型=用例+数据模型。
B项目中的概念原型
此处只列出主要逻辑，本项目涉及到从权限管理到数据管理，概念原型需要结合具体的用例与数据模型去分析，就好像程序是由算法和数据结构两部分组成的。
概念原型等于用例加数据模型，本项目涉及到用例可以是role的所有角色，我们这里列出主要部分，系统管理员，普通用户，角色管理员等等。
涉及到的数据模型包括，用户，角色，权限，讲师和课程表等等。