1.是否可以为系统中的每一个子系统做一个use case图。假设软件分为在客户机和服务器两部份。对服务器来说,客户机就是它的actor,可否这样做图。2.actor从定义上来说,应该在系统外部,和系统无关的。这样的话,研究actor的继承关系是否有必要。从实际应用上看,答案是肯定的。但是由于actor和代码无关,也就是说,继承关系并不能在代码中体现,那继承又有什么意义呢?

解决方案 »

  1.   

    1 为子系统作一个use case图?什么意思?
    use case和你的系统有什么关系 
    use case的基本概念你还要好好理解一下 它考虑的是系统外部的交互下午 而不是内部 同时角色也可以是人和系统外的任何东西 包括另一个系统
    2谁说actor和代码无关 无关你研究它干吗 
    那一个actor最后不落实到你系统中的实体类呢
      

  2.   

    1. 就是说如果软件分为客户机和服务器两部份。则为客户机程序和服务器程序各做一个use case图.  这样,对服务器软件来说,客户机就是一个actor.  不知我的理解是否正确。2. actor当然和系统无关。难道你要为你的用户都生成一个实体类?这样的话,actor说不独立于系统之外了。
      

  3.   

    1。use case代表人-机的一次交互,划分的粒度根据系统的大小和个人的经验
    2。actor是和use case交互的外部使用者
      

  4.   

    1.认为正确
    2.精确点说,应该是actor相对独立于use case(跟actor有关的use case),对一个系统来讲,一个actor可能就是系统的一个组成部分(划分的粒度)
      

  5.   

    1.我们利用use case进行需求分析、与用户进行交流,利用use case驱动整个软件开发过程。子系统是进行系统设计时对一个复杂的系统根据某种机制将类进行分组得到的。actor是一个强调与用况发生交互的概念,服务器与客户机是设计中C/S构架模式中的概念。
    2.actor是用况的使用者在与用况发生交互作用时所扮演的角色,应用系统是向用户提供一组有内在联系的用况的系统。actor最终落实到分析模型的实体类,采用OO方法对actor的研究也就是对与之相应的实体的研究。
      

  6.   

    1. 我也是这么想的。但是从单纯用户的角度来看,他并不关心你的C/S结构,对他来说,只看见一个总的系统,这时候就不应该单独分开C/S了
      

  7.   

    用户更关心软件的功能,关心软件的使用是否能提高其工作效率。
    难道你想利用use case图达到向用户展示系统的具体构架(譬如C/S)的目的?
    如果用户要关心这些的话你可以利用构架描述向他解释,但事实上没有必要。
      

  8.   

    谢谢诸位的回答。
    第一个问题我大概明白了,这样理解不知道对不对: 如果是给最终用户看的话,那么对整个系统有一个总的use case图就行了。如果是给自己做下一步设计用的话,就要为每个子系统做一个use case图。也就是说总共需要有两份use case 图。不同的use case图完成不同的功能。第二个问题还有点疑惑,如果象楼上所说的“actor最终落实到分析模型的实体类”,那么actor就是被包括在系统之中,与actor的本来含义有所矛盾。不知怎么解释。
      

  9.   

    我想你还没明白1、与用户交流的USE CASE模型就是你进行分析工作的输入,然后输出分析模型,分析模型是进行设计工作的输入,通过设计得出设计模型。
    2、并不矛盾,actor是系统之外,但对它的研究有助于与之对应的实体类的研究,譬如一个系统有系统管理功能,对角色的研究就有助于对系统用户实体类的研究。