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.识别类之间的连接.