育才学习网1.什么是 用例 usercase
下面逐一说明用例图中各种符号的意义：
小人：
对使用某系统的用户进行分类后，可以总结出使用本系统有哪些角色，不同的角色的工作责任不太一样，他们需要用到的系统的功能也会不太一样。
小人就是角色，它给了我们一个启示，我们思考某系统的需求时，可从不同角色的角度来思考。
例如：我们要做一个考勤系统，你会怎样思考呢？会一下子列出很多功能？比较好的方式，应该是先思考什么人会用这个系统，我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统，对于一般员工来说除了打卡，他还关注什么？对于前台，她是不是要做一些考勤的统计？而财务是不是要根据考勤情况来调整员工的薪金？这样的思考方式，会让我们更容易全面发掘系统的需求。
还需要特别说明的是：角色可能是人，也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某角色。
圈圈：
圈圈里面会有一段动宾结构的文字，也就是“动词+名词”这样的方式，这个圈圈+圈圈里面的文字，就是用例，这些用例表明了系统能做什么事情。
以考勤系统为例：有两个用例叫“打卡”、“查看自己的考勤情况”，这个两个圈圈分别用一条线连到了“一般员工”这个角色，我们可以按这样的顺序来读这个图：先读出角色的名字，然后读出用例中的文字。按着这样的读法，我们可以得到两句完整的句子：
“一般员工打卡”
“一般员工查看自己的考勤情况”
大家可以用这样的方式来检查自己用例图是否画得合适。
某用例不一定是只属于某个角色的，有不少用例是多个角色“共享”的。
大框框：
在所有用例的外面，有一个方框，这个方框只框住了用例，没有框住角色，这个东西就叫做系统边界，框框的上部会注明本系统的名字。
我们所做的系统，是不可能包括角色的，系统要发挥各种作用，要靠各角色“穿越”系统边界来使用本系统的用例。
系统边界能清晰表达出系统的范围，并不是所有的用例图都需要画出系统边界的，一般只需要在全局用例图中画出系统边界，当对用例进行细化时，不需要画出系统边界。
线条：
线条是指角色与用例之间的线条，线条有三种：无箭头的，指向用例的箭头，指向角色的箭头。无论是否有箭头，这些线条是用来联系角色（小人）和用例（圈圈）的，表示某某角色能“做”什么用例。
有箭头的线条，表示角色与系统交互的过程中，数据的流向，如果箭头指向用例，就说明角色需要往系统输入数据，如果箭头指向角色，说明系统往角色输出数据。
而没有箭头的线条，则没有明确表示数据的流向，一般情况下不需要明确表示数据的流向，只需要画无箭头的线条就可以了。
2.什么是 用例 usercase
下面逐一说明用例图中各种符号的意义： 小人： 对使用某系统的用户进行分类后，可以总结出使用本系统有哪些角色，不同的角色的工作责任不太一样，他们需要用到的系统的功能也会不太一样。
小人就是角色，它给了我们一个启示，我们思考某系统的需求时，可从不同角色的角度来思考。 例如：我们要做一个考勤系统，你会怎样思考呢？会一下子列出很多功能？比较好的方式，应该是先思考什么人会用这个系统，我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统，对于一般员工来说除了打卡，他还关注什么？对于前台，她是不是要做一些考勤的统计？而财务是不是要根据考勤情况来调整员工的薪金？这样的思考方式，会让我们更容易全面发掘系统的需求。
还需要特别说明的是：角色可能是人，也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某角色。 圈圈： 圈圈里面会有一段动宾结构的文字，也就是“动词+名词”这样的方式，这个圈圈+圈圈里面的文字，就是用例，这些用例表明了系统能做什么事情。
以考勤系统为例：有两个用例叫“打卡”、“查看自己的考勤情况”，这个两个圈圈分别用一条线连到了“一般员工”这个角色，我们可以按这样的顺序来读这个图：先读出角色的名字，然后读出用例中的文字。按着这样的读法，我们可以得到两句完整的句子： “一般员工打卡” “一般员工查看自己的考勤情况” 大家可以用这样的方式来检查自己用例图是否画得合适。
某用例不一定是只属于某个角色的，有不少用例是多个角色“共享”的。 大框框： 在所有用例的外面，有一个方框，这个方框只框住了用例，没有框住角色，这个东西就叫做系统边界，框框的上部会注明本系统的名字。
我们所做的系统，是不可能包括角色的，系统要发挥各种作用，要靠各角色“穿越”系统边界来使用本系统的用例。 系统边界能清晰表达出系统的范围，并不是所有的用例图都需要画出系统边界的，一般只需要在全局用例图中画出系统边界，当对用例进行细化时，不需要画出系统边界。
线条： 线条是指角色与用例之间的线条，线条有三种：无箭头的，指向用例的箭头，指向角色的箭头。无论是否有箭头，这些线条是用来联系角色（小人）和用例（圈圈）的，表示某某角色能“做”什么用例。
有箭头的线条，表示角色与系统交互的过程中，数据的流向，如果箭头指向用例，就说明角色需要往系统输入数据，如果箭头指向角色，说明系统往角色输出数据。 而没有箭头的线条，则没有明确表示数据的流向，一般情况下不需要明确表示数据的流向，只需要画无箭头的线条就可以了。
3.如何书写Use Case
什么是Use Case用例描述文档的书写是系统分析人员对用户需求的深刻理解的体现。
是后期时序图和实际开发的重要依据。也可以对作为项目估算的依据，以及根据UC复杂度和开发周期来衡量开发人员的工作效率。
因此UC的书写规范及其重要，就工作用的一些经验，比如书写格式、书写内容及其注意事项与大家分享。大纲图：一、前期准备？？ 对用户的问题要有非常深刻完善的理解？？ 确保能够解决用户的所有问题？？ 把用户的需求真正地反应到商业模型？？ 对以后的设计和开发过程提供说明和框架？？ 根据需求生成UI界面二、Use Case内容首先有用例名称：一般是模块名称或者模块中功能点的名称。
其次文档变更记录（Revision History），具体内容如下：1、基本描述（Brief Description）描述用例在系统中的作用。比如此用例的使用者是谁、使用者所要做的操作。
2、前置条件（Precodition）描述该用例执行前所要满足的条件。比如用例B执行前，必须先执行A，则用例的前置条件是执行A。
3、事后保证（PostCodition）此用例执行完毕后的条件4、主要流程（Basic Flows）用户操作该用例的基本流程，是后期时序图的主要参考5、选择性流程（Alternative Flows）在操作主要流程过程中，出现的一些分支流程，是后期时序图的主要参考6、特别需求（Special Requirement）对一些细微功能点进行描述，比如用户身份验证规则、订单号码产生规则、是否需要SSL加密等等7、使用界面（User Interface）美工根据需求制作的UI，及其对UI中栏位进行的说明。
4.如何书写UseCase
Use Case是用例描述文档的书写是系统分析人员对用户需求的深刻理解的体现.是后期时序图和实际开发的重要依据.也可以对作为项目估算的依据，以及根据UC复杂度和开发周期来衡量开发人员的工作效率.因此UC的书写规范及其重要，就工作用的一些经验，比如书写格式、书写内容及其注意事项与大家分享.大纲图：一、前期准备？对用户的问题要有非常深刻完善的理解？确保能够解决用户的所有问题？把用户的需求真正地反应到商业模型？对以后的设计和开发过程提供说明和框架？根据需求生成UI界面二、Use Case内容首先有用例名称：一般是模块名称或者模块中功能点的名称.其次文档变更记录（Revision History），具体内容如下：1、基本描述（Brief Description）描述用例在系统中的作用.比如此用例的使用者是谁、使用者所要做的操作.2、前置条件（Precodition）描述该用例执行前所要满足的条件.比如用例B执行前，必须先执行A，则用例的前置条件是执行A.3、事后保证（PostCodition）此用例执行完毕后的条件4、主要流程（Basic Flows）用户操作该用例的基本流程，是后期时序图的主要参考5、选择性流程（Alternative Flows）在操作主要流程过程中，出现的一些分支流程，是后期时序图的主要参考6、特别需求（Special Requirement）对一些细微功能点进行描述，比如用户身份验证规则、订单号码产生规则、是否需要SSL加密等等7、使用界面（User Interface）美工根据需求制作的UI，及其对UI中栏位进行的说明.。
5.怎么让switch语句循环
C语言还提供了多分支选择的switch语句， 形式为：
switch（表达式）{
case 常量表达式1： 语句1;
case 常量表达式2： 语句2;
…
case 常量表达式n： 语句n;
default： 语句n+1;
}
其语义是：计算表达式的值。 逐个与其后的常量表达式值相比较，当表达式的值与某个常量表达式的值相等时， 即执行其后的语句，不再进行判断，继续执行后面所有case后的语句。表达式的值与所有case后的常量表达式均不相同时，则执行default后的语句。
在使用switch语句时还应注意以下几点：
在case后的各常量表达式的值不能相同，否则会出现错误。
在case后，允许有多个语句，可以不用{}括起来。
各case和default子句的先后顺序可以变动，而不会影响程序执行结果。
default子句可以省略不用。
转载请注明出处育才学习网 » usercase怎么写