以前也做过一些小的东西，主要是web方面的，但是没有做过系统分析。
虽然学过UML系统建模，相关的工具也会用，最近要写论文可是在系统分析过程中总觉得茫然，思绪纷乱，怎么个分析法
用例到底是一个什么样的概念，貌似可大可小。。。
比如一个会员注册系统，那么提交注册表单，添加注册会员，删除会员，修改会员等等都可以作为用例
可是如果我是一个综合的系统呢，就是说包含了诸多功能模块（会员注册，产品管理等等），那么每一个功能模块又可以当作一个用例？？
然后每个功能模块里的操作又可以再分为用例？？？？
极度困惑。。。
------解决方案--------------------------------------------------------
I give one suggest,you can download a book called <software architeture in practices>
or you can just search UML 2.0 from internet.
normaly, you just treat 会员注册系统like a system. If you want to do it easy. it just can be one big componet. and another component can be data.
Otherwise 会员注册系统 as System, others can be subsystem and all of them deal with Data
------解决方案--------------------------------------------------------
理论上说用例不能过多
如果是采用RUP，用例驱动的话，每个用例都对应一个控制类
边界类对应表现层
一个用例对应一个控制类
实体类对应数据库表
一般的OOAD思想应该是先明确Actor（系统参与者），这样方便确定系统边界，并对系统的权限设计很有帮助
之后才是识别用例，粒度不能过小，一般不要超过50个用例（理论上讲超大系统也只有50几个）
用例主要是描述，并不是画用例图
描述的时候就要把流程描述清楚可以辅助以活动图等
------解决方案--------------------------------------------------------
没有古典的和现代的，只有适合的不适合的或者有效的无效的
用例的确可大可小，可记录组织的业务过程，也可记录软件的行为需求。
而具体用例粒度的确定，取决于你用例的目的以及范围
------解决方案--------------------------------------------------------
包含了诸多功能模块（会员注册，产品管理等等），那么每一个功能模块又可以当作一个用例？
--------------------------------------------------------------------------
用包图表示模块
------解决方案--------------------------------------------------------
你这么理解也可以
actor->系统登录 include 身份验证
先识别actor，之后再确定主要的功能，再细分功能，但不要分得过细了，用例要控制在50个以下，小系统十几个就差不多了
注意每定义一个用例要对应一个控制类