步骤：
1。识别参与者(*)---在系统之外，透过系统边界与系统进行有意义交互的任何事物.
系统外---参与者不是系统的成分.
系统边界---责任边界，非物理边界.(用户和系统的接口).
系统边界---直接与系统交互.(游客,旅行社,订票系统----*旅行社是边界*).
有意义交互---属于目标系统的责任.
任何事物---人、外系统、外部因素、时间.
参与者类:属性---姓名:String,性别:Integer,电话:String,用户名:String,密码:String,首次登陆:Boolean
方法---验证用户名和密码()，取参与者信息(),取未结帐订单(),检查是否第一次登陆().
地位:----------------------- ------------------------------------
\---------------------------------/
识别用例之前重要 开始书写用例文档以后---不重要 测试部署阶段---重要
有助与识别用例-宁多勿少 涉及的参与者太多 需要从参与者的角度考虑
2.识别用例(*)
定义:参与者使用系统达到某个目标.
用例要点: 可观测---用例止于系统边界(描述交互，而不是内在的系统活动)的。
结果值---用例是目标导向的.(系统的存在是因为:参与者有一些需要使用它来满足的目标)
系统执行---结果值由系统生成.(不同的拥护，得到不同的结果)
由参与者观测---业务语言(非技术语言),用户观点.
一组用例实例---用例的粒度.
注意：用例要有路径,路径要有步骤.而这一切都是"可观测"的,最常犯的错误:粒度过细.
常见错误:
1.把交互的某个步骤当作用例.eg：会员---->输入用户名.
2.把系统活动当作用例： 建立数据库连接
查询订单 ---/
传送sql语句
暂时无法判断时，宁粗勿细
3.四轮马车的错误: "系统就是数据库的增删改查"，这是常犯的错误，先关心数据库，反而
忽略了用户的目的.
4.crud(增、删、改、查)掩盖业务: (我的理解:有的用例超出了本身的功能范围).
-------------------------方法--------------------------------------------------
5.如果CRUD不涉及复杂的交互,一个用例“管理**”即可.
不管是crud,都是为了完成“管理“的目标.
甚至很多种基本数据的管理都用一个用例表示.
6.灵活处理CRUD: 管理员---------管理用户----《extend》--------增加用户.
也可以把包含复杂交互的路径独立出去形成用例命名时尽量不要用CRUD词汇.
最现实:业务人员提供素材，开发人员写用例文档.
/*用例---用户的观点，功能---系统的观点.*/
3.书写用例文档(*)-----写:可观测的(eg:系统按照查询条件搜索零件)、体现客户利益的文字（这才是“需求”）
用例模版: 用例编号，用例名，用例描述，参与者
前置条件，后置条件，
基本路径：1。。。。。。(核心的核心:客户最想看到、最关心的路径).
2。。。。。。
3。。。。。。
扩展:2a.........(系统要处理意外)
2a.........(参与者的选择,另一条成功路线，系统进行验证)
补充说明
待解决问题
路径交互步骤的描述:
1.只书写"可观测"的(体现客户利益的文字).
2.使用主动语句.（eg:会员提交用户名和密码，系统验证用户名和密码）
3.句子必须以参与者或系统做主语.（eg:参与者****,系统****）
4.程序逻辑的处理.
a.判断
b.循环
5.不要涉及界面细节.
4.识别用例关系:(不要滥用用例关系)
用例关系:---------------------<extend>------------------->扩展
扩展:分离复杂部分和易变部分.(o--去城里(基本用例本身是完整的)，o---上厕所(扩展用例,意外情况)，当然不上厕所也能赶路).
何时使用扩展关系:
a.扩展路径步骤多. b.扩展路径内部还有扩展点--扩展之扩展
c.扩展路径容易变化--分离以"冻结"基用例.
---------------------<include>------------------>包含
包含:提取公共交互,提高复用.(基本用例路径本身是不完整的(把上厕所考虑在内了，不上厕所就不完整了),包含用例)
eg:o---下订单-----------《include》--------->o---提供客户信息.
何时使用包含关系:
a.某些交互步骤可以被多个用例复用.
b.用例的交互步骤较多时，可以用Include简化.
------------------------------------------------>泛化
泛化:同一业务目的的不同技术实现.
eg: o--识别用户
/ \
o--验证口令 o--扫描视往膜
--------------除此之外，不能有别的关系---------->
注意:用例之间不能通讯.
开发过程第0步，业务建模.
5.对用例进行排序和分包
排序原则:
以下情况的用例优先级最高:
a.对类图有重要影响.
b.包含丰富的业务过程信息和线索.
c.有开发风险、时间紧迫或功能复杂.
d.涉及到重要核心技术或新技术.
e.能直接产生经济效益或降低成本.
f.代表本系统的核心流程.
按参与者分包，按主题分包，按开发团队分包，按发布情况分包.
*可以先按主题分包，主题内再按开发团队和发布情况分包.
补充需求规约： 软件需求
| | |
非功能需求 功能需求 设计约束
非功能需求:可用性，可靠性，性能,可支持性.
设计约束：用oracle数据库平台,用PB开发.........
软件必须符合ISO... 标准........
本质上不是需求,只是从商业、行政、技术上的约束.
下一步:
需求<----->用例----->面向对象分析设计、结构化分析设计、其他方法、自己的方法.---->系统
用例和oo
1.“发明”与oo的环境.
2.从外部actor的角度描述系统功能(和对象的消息类是).
3.不暴露内部结构.
4.oo设计的最好开始，但.....
5.用例可以用在非oo的开发过程中.
6.oo理论不需要懂得和使用用例.
我的qq：8201726 验证：java ，愿你我共同面对所有的问题！
-------------------------------------类图,我的理解---------------------------------------------------------------------------------------------------
1.识别类及其属性.
a.阅读需求文档,抽取对应于业务实体或事件的名词.
b.将名词进行分类、抽取出合适的类.
2.识别类之间的泛化.
3.识别类之间的聚合/组合.
4.识别类之间的连接.