设计用例
来源：互联网 发布：qq飞车爆天甲数据 编辑：程序博客网 时间：2024/06/07 18:10
@import url("http://www.csdn.net/ui/styles/public_header_footer.css");
一个消息管理系统。
http://www.hatfamily.com/a.jpg
请大家批评阿
我刚刚在FAQ增加了几个USECASE的内容，请参照看一下。（在需求里面）
可以你现在还不真的知道什么是USECASE。
Top
谢谢你的批评，
好的，我去看看，能否指点一下我的认识
错误在那里呢？我希望提高
Top
首先你要明白USECASE不是一种UML图，而是一种格式化文档。
如果你不把流程用文字或者图示的方法表示出来，就无法理解其所反映的流程到底要作什么以及怎么满足涉众的利益。光光那么一个USECASE DIAGRAM是不能说明什么问题的。
Top
我明白了，其时我只是画一个用例图出来了，
至于用例主执行过程，我没有进行描述
Top
你画一个用例图有什么用呢？除了说明有那么一些用例还能有什么作用吗？
Top
我以前学写用例时写的使用叙述，是作为场景描述给下一步的用例书写做准备的。一时找不到用例描述了，下次找到了在另发。给你看看，也希望oz6指正一下。
J2PM使用叙述
新一年的江西省自然基金课题申请开始了。
又是一个晴朗的早晨，江西省自然基金委员会的沈主任走进办公室，打开电脑，准备整理一下往日的自然基金申报项目。沈主任启动了数据管理工具J2DM，先将整个数据库进行了备份，然后删除了两年以前的数据。
这时，江西自然研究所的石研究员走了进来，他是来上交自己今年的自然基金课题的申报书的。沈主任把石研究员带来的申请书的MS Word电子文档拷贝进了电脑。然后，沈主任一边打开自然基金项目管理系统J2PM，选择将申报书的内容导入到数据库中。一边告诉石研究员，江西金融研究所的施办事员申报的课题由于不符合申请规定，被系统自动淘汰了。这时系统自动查询了与石研究员的申请课题相关的历史数据，确认该课题符合申请规定，提示通过。石研究员很高兴，在表示感谢后离开了。接着，沈主任又把昨天Email收到的南昌基金学院的一批申请书一次性导入了数据库。
提高办事效率是南昌市政府职能部门当前的重要目标。石研究员一离开，沈主任就开始为刚导入的申报课题选择审查专家了。沈主任在J2PM中定位到石研究员的申报课题，又启动了专家管理系统J2EM。专家管理系统自动定位到了和申报课题相关的专家类上。沈主任根据J2EM中的专家信息为申报课题选择了五位专家。同样，沈主任为J2PM中的其它课题选择了审查专家。
下午，沈主任把打印好的各个申报课题的审查函寄发给了相应的专家。
两个月后的一天，沈主任的桌头放上了关于石研究员的申请课题的审查专家的第一份回函。沈主任启动J2PM，定位到石研究员的申请课题，输入了专家的意见和评分。这时，电话铃响了，沈主任拿起电话，原来是南昌基金学院的肖院长打来的电话，肖院长想了解一下本单位今年已经申报了多少课题。沈主任打开J2PM，对南昌基金学院进行查询。系统返回了南昌基金学院的课题申报信息。沈主任根据结果向肖院长作了答复。肖院长表示感谢后邀请沈主任有空时到南昌基金学院参观。沈主任愉快地接收了邀请。
又过了四个月，石研究员的申请课题的所有审查专家的回函期限到了，但只有三位专家发回了意见。于是，沈主任在J2PM中根据三位专家的意见和评分为石研究员的申请课题生成了最终评分。
十月是收获的季节，也是自然基金终审的日子。沈主任根据各个申请课题的总评分进行了最后的排名。最终，各学科组分类的排名前十位的课题得到了立项，其余课题被淘汰。
经过基金委的讨论，沈主任为立项的课题分配了经费，并在J2PM中记录了该信息。
石研究员的课题也得到了立项，但她感到分配的经费不足。于是，石研究员向基金委提出了增加经费的申请。基金委经过讨论，同意了石研究员的申请。沈主任根据新的决定更新了石研究员的项目信息。
一年后，沈主任收到了石研究员中止课题的申请。原来石研究员收到了毛里求斯大学的担任客座教授的邀请，为援助非洲兄弟的伟大使命而申请中止课题。基金委基金委经过讨论，同意了石研究员的申请。沈主任根据新的决定更新了石研究员的项目信息。
撰写《使用叙述》的问题：
1． 难以把握描述的精确度。
2． 开发组对虚拟环境的交互。
Top
这不是一个场景，它包括了太多的元素。在你的阐述中包括了很多的用例，我先以一个来作例子讲一下到底怎么写用例。
比如我们先看第一个用例，叫－－备份数据。实际上这个名字也不是这个用例的最后名称，有多种不同的命名策略，但是“备份数据”这几个字是大家都会用到的。按照我的名字原则这个用例大概最后会叫－－用户备份数据，而用户这词我现在还没有把握，可能最后会有更加有针对的词，比如考虑到权限之类的因素的词。
然后我会看什么时候可以启动这个用例，当然是合法用户才可以使用这个功能，所以前置条件应该是已经完成登陆用例。大家注意这个时候很多人会考虑是不是有包含关系，我的看法是把它当作其前置条件更加符合实际情况。因为你不是每使用备份前都会使用登陆这个用例的，也许你早就登陆过了，完成了很多工作后才来备份的。而要是你使用包含关系的登陆往往就意味着，你在使用这个用例前必须先使用登陆用例，然后跟着开始备份。
确定前置条件后，马上就要确定启动场景，也就是什么时候这个用例开始启动。这个场景我描述为－－用户选择备份数据功能。大家注意，我没有使用用户点按钮或者菜单启动备份功能，这是因为用例是一种高层功能描述，不要和具体的实现绑定在一起。比如如果我用了绑定的办法，后来发现还可以通过使用快捷键方式启动这个用例，客户自定义在某个时刻启动这个用例，这个时候你就必须修改这个用例的写法，显然这是现在不必要的工作，我们会在具体如何实现这个用例的业务设计阶段去考虑这样的细节问题，现在还不是时候。
场景2－－用户选择要备份的数据。
场景3－－用户确认开始备份
场景4－－数据成功备份，显示备份成功。
场景4可以看作后置条件，它用来说明用例成功后的效果。
而上面我阐述的是用例的主流程，这是一个一切顺利的成功的流程。我们可以对其每一个场景最细化工作，比如场景3的确认可以细化为确认备份到数据库，备份到软驱，备份到磁带等，这些我们可以认为是场景3a、3b、3c等。
而同时我们还要考虑到一些意外的或者错误的情况。比如选择要备份的数据后，客户却觉得没有必要备份了。这个就是一个意外场景，我会命名它为－－！3。也可能是你选择备份到软盘，但是软驱中没有盘，这我可以认为它是一个意外，当然也可以认为它是一个错误，这不是太大的问题。而如果你选择的数据已经损坏，这显然就是一个错误，这就是一个错误场景，我会命名它为－－◎4。
上面这个例子只是为了说明怎么写用例，我要是真的去写则可能会把备份、删除、添加、拷贝等几个功能用一个用例－－客户维护数据。而同时大家也注意到，我们没有把主场景划分的过于细节，比如划分为15个场景。这样你会画太多的资源，因为每一个主场景都会涉及意外和错误场景，过多的主场景，会让你的用例描述过大，过于细节化，不利于理解用例的核心思想。
实际上写用例的过程，就是一个先明白大概要作什么，然后确定主场景，再以后你就可以去选择确定前置条件、后置条件、意外、错误，或者干脆就先细化一个场景，这个没有先后之分，只要你都作了就可以，什么先容易确定就先确定什么，只要你按照主流程场景为线索，把这些东西串起来就可以了。
Top
ozzzzzz(希望敏捷) :
你的讲解非常精彩。把我看编写有效用例的东西都进行了一个
串联。真诚的感谢你！
Top
看到你的讲解，我也想我的用例叙述贴上来，请ozzzzzz(希望敏捷) 指导，谢谢！
清晨，新贸公司的业务员小刘走进办公室，打开电脑，启动讯息通讯系统，
准备查阅公司的客户发来的消息。进入系统后。系统已经把发送给它的
新消息显示出来。他依次查看了这些消息。其中有一条是客户要求去市场上去
寻找“洗澡用的沐浴球的。他关掉讯息通讯系统。然后离开公司去了市场上去
找这种产品。他找到产品后。对产品进行拍照，询问了价格。然后回到公司。
将这个产品的资料和报价都整理成一份WORD文档。然后再次打开讯息通讯系统
搜索这条“洗澡用的沐浴球的”的消息。然后回复这条消息。将自己的在市场上
的情况写在消息中。在将其中的WORD文档附加在消息中。然后发消消息。中午。
当他再次进入讯息通讯系统时。客户的回复消息已经列在新消息中了。他查看了
消息。客户已经确认让他到市场上去采购。这时他要发送一条新消息给主管来
确认。于是他新建了一条消息。将情况都写在消息中。从部门列表中选择管理部
然后从管理部的人员列表中选择了BOSS。然后发送消息。中午他得到了主管的确认
他于是立即去市场上定货。
希望ozzzzzz(希望敏捷) 提出宝贵的意见。我对用例才入门，请你指点一下。
我的用例图分出来的用例是否正确。谢谢！！
Top
用例图的作用在我看来就是初期标示出有那些用例，这个是最重要的功能，所以这个时候的用例是一个一个排列，不相联系的。我这么作是为具体表现用例作分配工作的准备，因为一个系统不会让一个人去写所有的用例，那么先划分到底有多少用例就很有必要。而下一步我可能会生成一个和你给我的用例类似的整体用例图，用来给大家说明用例间的联系，从而人大家从整体掌握系统的功能要求。但是往往项目成员在看了前面的各个用例以后就已经理解了系统的梗概，所以这个整体用例图就显得没有必要了。而其实我还可能根本就不画一个图，只是给出一个名字，联ACTOR都不确定，就把它分配给用例编写人员，让他们去确定到底谁是ACTOR，目的为何。
你上面的阐述只是列举了多个场景，那些都不是用例，我们还要作提纯工作。所以你应该按照我上面的方法在这个阐述中提纯出用例。
而在上面我的例子中，你会看到我没有提出写用例目标。并不是我忘记写这个重要的部分了，而是那个例子实在不能很好的说明用例目标的作用。用例目标其实就是参与者，通过这个用例所要达到的目标，从这个意义上说所有的用例都有一个目标－－更好的完成工作。当然这样的目标没有说明具体的问题，而“完成数据备份，以保存数据到一个客户希望的介质”，这样的阐述用来作用例目标是合适的。但是其实这个阐述在我看来，还是可有可无的，因为这个例子都是在体现这个目标。而实际上，有的用例所体系的目标绝对不是一个，也不是一个角色的目标。这个时候是最需要明确用例目标的，不然那里流程就会显得不合逻辑。比如一个用例是－－用户登陆。
主要场景是
1，用户启动系统，系统提示登陆，
2，用户输入用户名、密码，并确认
3，系统显示登陆成功 进入操作
然而这往往不是真正我们在最后写的用例，最后的用例大概会是这样
1，用户启动系统，系统提示登陆
2，用户输入用户名、密码，并确认
3，系统提示上一次用户登陆时间，并自动记录此次登陆时间
4，系统显示登陆成功，并自动进入操作界面
我们看到这2个用例书写方式中最大的不同，在于后面的第三场景，这个场景中的自动记录数据和显示上次登陆时间，显然不是满足用户使用系统这个目的的，而它们又是那么必要。所以这个用例其实所要完成的目标就还需要包括－－帮助用户检查有没有非法使用系统情况。而同时记录用户登陆时间的目标还要更加多，它还满足了使用系统的另外一些人的目标，比如管理员可以使用这个数据，监督系统的使用情况。而如此说来，用例目标就不能只是考虑到ACTOR的目标，而应该考虑所有会和这个用例产生关系的人的不同目标。如果有些人的目标没有被考虑到，你就用可能遗漏很重要的东西。
你还是去写一个用例来给我看看吧。你上面那个不是用例。
Top
谢谢你希望敏捷。那我就把其中的一个用例贴在下面，请你多指点
用例： 发送消息
参与者: 公司职员
前置条件：用户已登陆
触发条件：用户选择消息发送功能
目的：将一条消息发送给指定的接收者
主执行场景：
1.用户选择系统中的消息发送功能
2.用户在用户列表中选择消息接收者
3.用户编辑消息
4.用户添加附件
5.用户确认发送消息
扩展场景没有填写，请希望敏捷批评
Top
好贴，顶＋收藏
Top
我这也有一个人力测评管理系统的用例描述，用例图就省了，大家看了下面的描述应该知道有些什么角色和用例，希望大家指正：
题库管理
1 题库类别管理
A 简短描述：根目录为：企业题库，根目录只有一个，不可新增，也不可删除，但可修改根目录名称；在根目录下，可新增、删除、修改子目录，子目录的层数至少能增加到三层，最好层数不限。
B 事件流程：系统提供新增，删除，修改目录的功能。选择根目录时，只提供修改和新增的功能；在选择其它目录情况下，可新增，删除，修改。
－ 新增：用户选定一个目录，系统默认这个选定目录为父目录，用户点击新增，系统自动新增一个子目录，并预设此目录名称为‘新目录’；系统提示用户为这个新目录命名，用户可命名或撤消操作，选择撤消，则系统自动删除这个‘新目录’；用户重新命名后，系统提示保存或撤消，选择保存则系统将判断这个新增目录是否与本目录下其他目录同名，如果同名，系统提示名称重复，要求用户重新命名，如果没有同名，系统将保存该新增目录；如果用户选择撤消，则系统自动删除该新增目录。
－ 删除：用户选定一个目录，点击删除，系统提示用户：将删除该目录下的所有子目录及该目录下的所有试题，删除后将不能恢复，请用户慎重考虑。如果用户选择确定要删除，系统将自动删除该目录及该目录下所有子目录及该目录下所有试题。如果用户选择取消，系统不做任何动作。
－ 修改：用户选定一个目录，点击修改，用户将可修改该目录的路径或名称。修改路径通过修改该目录的父目录编号来实现，如果用户填入的父目录编号不存在，系统提示：不存在该目录，撤消用户操作；如果用户填入的为该目录的子目录编号，系统提示：不可将该目录放在自己的子目录下，撤消用户操作；如果目标目录下有与该目录同名的目录，系统提示：目标目录下存在与该目录同名目录，系统将覆盖掉目标目录下同名目录及试题，用户选择确定，系统自动删除掉目标目录下的同名目录及试题，并将该目录及该目录的子目录和试题移到目标目录下，用户选择取消，系统不做任何动作。修改目录名称，系统将判断新名称是否与本目录下其他目录同名，如果同名，系统提示名称重复，要求用户重新命名，如果没有同名，系统将保存该目录的新名称；如果用户选择撤消，则系统不做任何动作。
2 试题管理
A 简短描述：系统提供新增，删除，修改的功能，试题有主观题，客观题。主观题有填空题和问答题，填空题有标准答案，问答题有标准答案或无标准答案。客观题有单项选择或多项选择，选项项数不定（两个选项以上，可三、四、五、六……），是非判断题可转为选择题处理。题目中会有图形。
－ 新增：用户选定一个目录，点击新增，系统自动将所在目录的编号值赋给新增试题的所在目录字段，并自动生成试题编号，该编号在整个题库中是唯一值。用户选择题形类别，系统自动将题形类别的编号赋给新增试题的题形类别字段，如果选主观题，系统再提示是否有图形，如果无图形，系统将产生两个文本框，如果有图形，系统将产生两个图形框。一个输入试题题目，一个输入试题答案（如果无标准答案则可不输）；如果选客观题，系统再提示是单项选择或多项选择，如果是单项选择，系统再提示是否有图形，如果无图形，系统将产生一个文本框，用于输入试题题目，同时产生一个列表，用于输入答案选项，选项内容，选项分值，答案选项不可重复。如果有图形，系统将产生一个图形框，用于输入试题题目，同时产生一个列表，用于输入答案选项，选项内容，选项分值，答案选项不可重复；如果是多项选择，系统再提示是否有图形，如果无图形，系统将产生一个文本框，用于输入试题题目，同时产生一个列表，用于输入答案选项，选项内容，选项判断，答案选项不可重复。如果有图形，系统将产生一个图形框，用于输入试题题目，同时产生一个列表，用于输入答案选项，选项内容，选项判断答案选项不可重复。
－ 删除：用户选定一道题目，系统列出题目及题目答案，点击删除，系统提示：将删除题目及该题目答案，如果用户选择确定，系统将删除该题目并自动删除该题目答案，如果用户选择撤消，系统不做任何动作。如果是选择题，用户选中答案选项，点击删除，系统则删除用户选中的答案选项。
－ 修改：用户选定一道题目，点击修改，系统列出该题目内容及答案或答案列表。用户可修改试题内容和试题答案和试题的所在目录编号，如果用户修改试题所在目录编号，系统将判断该目录编号是否存在，如果不存在则发出提示，如果存在，则继续判断该目录下是否还有子目录，如果有子目录则提示不可在该级目录下放置试题。用户不可修改试题的编号。用户也可直接修改主观题的试题答案或客观题的答案选项。
试卷管理
1 简短描述：用户进入试卷管理界面，系统列出已有试卷，并提供新增试卷，删除试卷和修改试卷的功能。如果用户在试卷列表中选中一份试卷，系统列出该份试卷的所有试题，如果用户选定该份试卷的一道试题，系统列出该道试题的答案。
－ 新增：用户点击新增，系统进入新增界面，自动列出企业题库，自动产生试卷编号，用户可修改试卷编号，填入试卷名称，系统判断试卷编号是否重复，如果重复则发出提示。输入完相关信息后，系统提示是否保存，用户保存后，系统提供新增、删除、修改试题的功能，用户选中企业题库中的试题，点击新增，系统将该题增加到试卷中，用户按ctrl或shift可进行多项的选择；如果用户选中企业题库中的目录，点击新增，系统将该目录下所有试题增加到该试卷中。
－ 删除：用户选中试卷列表中的试卷，点击删除，系统判断该试卷是否有用于测试，如果有用于测试，系统提示试卷已经被使用过，删除后无法得知使用该试卷进行测试的测试人员所参加测试的题目，但不会删除该试卷上的企业题库试题；如果没用于测试，系统提示该试卷删除后无法再用于测试，但不会删除该试卷上的企业题库试题。用户按确认，系统将删除该试卷，但不会删除曾使用此试卷进行测试的测评结果。用户按取消，系统不做任何动作。
－ 修改：用户选中试卷列表中的试卷，点击修改，系统进入修改界面，自动列出该试卷的相关信息，及所有试题列表，所提供的功能同新增界面一样，可修改试卷编号、试卷名称等相关信息，也可新增、修改、删除试卷中的试题。
测评管理
1 制定测评计划
A 简短描述：用户进入测评计划界面，系统列出已有测评计划，并提供新增，修改，删除的功能。用户选择一项计划，系统列出该计划的详细信息，包括使用试卷信息，参加测评的人员信息。
－新增：用户点击新增，系统提供已有试卷列表，人员(公司人员或应聘人员)列表，用户输入计划编号、名称等相关信息，系统判断计划计划编号是否重复，如果重复，系统提示重新输入，在列出的试卷中选择一份试卷，从人员列表中选择参加测评的人员。
－删除：用户选择一项计划，点击删除，系统提示将删除该计划及相关信息，包括使用试卷及参加该项测评的人员。
－修改：用户选择一项计划，点击修改，系统判断该计划有没有实施，如果实施，系统提示该计划已经实施，不可修改，如果未实施，系统列出该计划的详细信息，用户可修改计划的所有内容。
2测评实施
A 简短描述：用户以权限登录，系统列出可供选择的试卷，用户选择试卷，按确定，进入答题说明界面，简要说明答题方法、答题时间、题目数量等问题，用户按开始，进入答题界面，系统调出该份试卷，应聘人员开始答题。如有时间限制，系统自动计时，在时间结束前n分钟（可由用户自定义）提醒答题人员，时间到，系统自动退出答题程序，并保存答题结果；如无时间限制，答题人员在答完题后手动保存答题结果并退出答题程序，如未保存，系统也会自动保存每一道答题结果，在有效时间范围内，答题人员可对答题结果进行修改。
3测评结果统计分析
A 简短描述：用户登录测评结果统计分析界面，系统列出所有测评计划，用户选定一测评计划，系统列出该计划的详细信息，用户点击统计，系统根据试题类别，分类统计出各类别的分数，用户选定一测评对象，系统列出该测评对象的测评统计结果。
Top
好帖，这正是我们新手需要的。领教了！另外也提提自己看了之后的一些想法。
o6z提到“根本就不画一个图，只是给出一个名字，联ACTOR都不确定，就把它分配给用例编写人员，让他们去确定到底谁是ACTOR，目的为何”，这与书上说的用例要for each相悖的。但是应该先用例还是先actor，这个问题争论起来就像鸡生蛋，蛋生鸡一样，无休止的。对于业务情况一点也不了解，从for each出发，可以让我们逐步找出用例，但对于一些情况，我们可能是先了解一点业务，可以找到一两个用例，或者这些业务涉及的人员比较多，一下还不能确定，再或者目前该用例的流程不合理，可能需要业务流程再造，那我们可以先提出用例，再考虑其actor和流程。具体情况具体应用，不一定非要按教科书的。
对于用例，我最感困惑的就是粒度问题，例如scentdia(scentdia)提的管理用例与新增、删除、修改等（老觉得scentdia用例描述别扭，但说不上道理来）。虽然粒度问题以各方能理解为度，靠系统分析员的经验去把握，但希望o6z能在这方面说说，或者用个例子来说。
不胜感激！
Top
jonescheng(C#前进无极限)
用例名称需要加入一个主语，一般情况下会是主要角色。
而你没有写究竟什么时候用例结束，也就是后置条件。这个是很重要的。
3、4场景有问题，因为不一定每一次都会发附件，所以我会把4当作一个扩展场景。而且在我看来添加附件也是一种编辑行为。
scentdia(scentdia)
你提供的不是用例。而且请注意，对于目录之类的系统内部的细节最好在初期不要涉及，因为很可能我不采取目录树的方法，也许我会存储的数据库中呢？
而我希望你提供一个类似jonescheng(C#前进无极限)的用例，这样我才好开始分析你的问题。一下给出整个系统场景太乱，不利于说明究竟怎么写用例，当然实际中我们会给出这样一个整体的场景让大家了解系统梗概，可是在学习的时候这样就免了。
Top
libi(风自吟)
看来我要收咨询费了，或者我也干脆办一个用例培训算了：）
我想你应该看到我和阎博士关于面向对象分析的讨论了，我关于不设置ACTOR就交给别人去写用例的动机就在于，我要使用面向对象的分析技术。
在我看来actor最后都会出现在分析模型中，他们都会成为一个分析类。而在编写用例的初期，我们很难确定到底actor是一个什么角色，而这个确认对于我建立面向对象的分析过程又那么重要，所以我才在开始不作决定，而把它留待合适的时间作出。而从这一点你也可以看出，我并不是说用例没有actor，而是说究竟那个actor是什么样子需要逐步的解决。而往往我们面对的商业应用（USECASE的主要分析领域），角色总是很复杂的。比如一个登陆用例，往往是很多人都在使用，而在初期就确定其actor是操作员，这样是不合适的。而不断发现actor的过程中，我们会发现一下actor是另外一下actor的子类，而有的则完全不相关。如果是子类，我就会把这个用例变为一个父类的操作。而不相关则会让我考虑使用操作类，来让大家调用这个公共登陆操作。这一系列的分析是和我后期的实际设计紧密相关的，所以请仔细体会我的做法。
粒度问题是用例的老大难问题，也是最终促使我放弃使用了这么就USECASE的主要原因。而从我的实践中我得到的结论是，主场景是最应该保持简捷的，也就是说主流程不能有太多的场景，我给自己的限度是9个（懒人的最高限度）。而同时对于用例间的粒度问题，比如增加删除之类的东西，如果我发现他们的主要场景基本相似，我就会把他们合并为一个用例。而在最开始的时候，我把一个用例从另外一个用例划分出来的时候，我是很谨慎的，这样作的唯一理由在我这里就是－－可以把过多的场景分开，也就是提高了用例的可理解程度。而这个标准也和具体的情况相联系，不要忘记用例最后是要给客户看的，是要被他们审核通过的。
Top
好贴！mark
Top
xuexi
Top
study
Top
支持一下！
Top
studying......
Top
to: scentdia(scentdia) ，能不能把你的用例图也公布出来看我们后辈学习学习呢？
Top
to:ozzzzzz(希望敏捷)
我刚刚在FAQ增加了几个USECASE的内容，请参照看一下。（在需求里面）
__________________________________________________________________
是在哪一个版块啊！我怎么找不到啊！谢谢！！
Top
软件工程/管理 软件工程
需求管理活动
最后三个就是我新添加的
Top
to :ozzzzzz(希望敏捷)
多谢，我找到了，正在看！！
Top
保留
Top
这么好贴啊！
Top
to :ozzzzzz(希望敏捷)
我怎么没有看见
软件工程/管理 软件工程
需求管理活动
郁闷ing
Top
这么人在讨论，明天在放一些UML图和用例上来
请大家在批评批评
Top
http://expert.csdn.net/Expert/FAQ/List_Room_FAQ_Index.asp?Roomid=401
这个是本版的FAQ地址。
http://expert.csdn.net/Expert/FAQ/FAQ_Index.asp?id=14041
http://expert.csdn.net/Expert/FAQ/FAQ_Index.asp?id=186095
http://expert.csdn.net/Expert/FAQ/FAQ_Index.asp?id=186115
http://expert.csdn.net/Expert/FAQ/FAQ_Index.asp?id=186119
Top
好好看书
Top
up
Top
up
Top
请教（希望敏捷）：
按照这样的说法，用例应该是在设计阶段做还是在分析阶段？
整个的流程又应该怎么走？
Top
yunjian(刀剑如梦)
use case是一种公认的需求分析方法，当然我也见过一些人用它来作设计，只是这样的做法很笨拙。
但是使用USECASE基本还是一个迭代的过程，还是不断修改的过程。基本上不存在一个固定的流程，按照Cockburn的方法基本可以是先找到系统的使用者，然后确定使用者的各个目标，以此目标为用例的动机，然后确定用例的主流程，前置条件，后置条件，例外场景，新参与者，新后置条件。不断的迭代，逐步求得一个合适的描述。
而按照Jacobson的做法，则是先找到一个可观察的流程，并且确认其有显示的意义，这就把那些所谓“在对话框中输入用户名”的无意义的东西过虑了，从而保持了一个粒度的标准。然后是确认其主流程，前置条件，后置条件，等等和Cockburn类似的方法。
基本上对于初学者来说，我建议还是使用Cockburn的方法。初学者最好不要看国内的人写的关于USECASE的文章，最重要的是不要看umlchina的文章。基本上那个地方的人都是以为USECASE就是USECASE DIAGRAM的家伙，根本就不能给你们以什么实质性的帮助。
现在有三本书，我在http://expert.csdn.net/Expert/TopicView1.asp?id=2638058这个帖子中都介绍了一下。
Top
好贴，好贴。
我把我另一个贴的观点挪过来
http://expert.csdn.net/Expert/topic/2761/2761611.xml?temp=1.914614E-02
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
一个系统最低要满足一个Actor的要求。我先解释一下我说的Actor（其实这个概念本来是我想在另一篇帖子UseCase++里去说的）。
在软件世界里，系统会有2种形态的表现，运行状态和维护状态，这两种状态下会对应着n个Actor。
例如，在运行态系统应该满足FirstActor的要求，使FirstActor能从系统的使用中获利，即CanWork。它也需要满足SecondActor的要求，使SecondActor在Context不满足的情况下也能正常使用该系统，即CanWorkCorrectly。它也要满足AntiActor的要求，所谓的AntiActor就是企图非法使用系统破坏FirstActor利益的用户，系统应该满足不能被AntiActor利用的要求，即CanWorkInSecurity，可以增加系统的更多的Actor，比如PerformanceActor等等。这些都是对运行态的系统提出的要求。
在维护状态，系统的表现（Presentation）应该满足对DevelperActor的基本要求，便于维护、调试、进化等等，甚至可以去满足开发者的虚荣心，即LookBeautiful。
一个系统的设计存在于两个状态之中，我决不认为那些所谓的乱七八糟的文档可以谓之为设计。当一个系统可以处在运行态的时候，那一定存在着设计，就像建筑的永恒之道所说的那样，它就在那里存在。而对这个设计的评价，就必须根据是否满足必要的Actor的要求而定。
一个系统的成长必须是根据Actor的各种要求，一级一级来的。我这里说一个系统设计的好与坏，必须根据实际情况去判断。没有该Actor的该要求，就不应该有对应的表现，否则我称之为过分设计。
Top
I 也谈没有银弹
呵呵，题目大了些，其实俺只不过是个程序民工罢了，偶尔跑来灌灌水……
刚才又拜读了一遍人月神话的的没有银弹，大师说世界的主要问题在：
× 复杂度
× 一致性
× 可变性
× 不可见性
大师就是大师，一语破的，当头棒喝，让我明白了这个世界的真相。不过，我的记性一向不大好，记不住这么多条，就斗胆压缩了一下，把问题归结为两条：
× 复杂
× 变化
因为复杂，所以很难一目了然；因为变化，所以不可能千篇一律。
II 分而治之
计算机世界里最常见的手段就是：分而治之，当然，现实中也是一样，毛主席老人家说，吸收进步力量、争取中间力量、孤立顽固力量，也充分体现了这一点。
增量和迭代就是一种分而治之，只不过一个强调了空间一个强调了时间。
分有时候可以象砍瓜切菜，采用暴力手段，有时就必须学庖丁解牛，掌握一些技巧。
对待不变的我们用静态视图去描述理解，对待变化的我们用动态视图去描述理解。
用例分析中，从静态角度去观察，有几个重要的概念：
× Actor
× UseCase
× Context
所以，我不赞同o6z的做法，单纯的谈论用例还是从一个囫囵的角度去看去分析，我们还是应该先识别几个最重要的概念，才能够去做事情。
没有Actor，用例就失去了一个强内聚的结合点，多个用例会一盘散沙，最后的结果就会导致垃圾用例的出现。
没有UseCase，用例就失去了理解系统要求的基础，就没有用例技术本身存在的意义。
没有Context，用例就失去了赖以为生的环境，也会成为无人问津的废弃物。
分是一个问题，合也是一个问题。其实分，本身就破坏了系统，遗憾的是我们却都是盲人，只能通过触摸部分来认识这个混沌的世界。老子说：
“
道可道，非常道；名可名，非常名。
無名，天地之始；有名，万物之母。
故常無欲，以觀其妙；常有欲，以觀其徼。
此兩者，同出而异名，同謂之玄。
玄之又玄，眾妙之門。"
Top
up!
Top
to twinsant124(蚂蚁的天空)
你觉得把精力花在这种纯理论的东西有用吗？ 我们只是工人，要靠解决实际问题吃饭的，这儿应该没有搞哲学的吧？弄一堆“玄之又玄”的东西唬唬人还能有什么用呢？ 就像以前在C++板块，一个关于OO和泛型的帖子回复到几百，最后都讨论到什么世界的本质上去了，最后解决什么问题了吗？ 个人观点，没有任何恶意的。
Top
楼上的兄弟，怎么能这么说呢？
多好的东西啊！
学习！
Top
twinsant124(蚂蚁的天空)
写了不错。抽象层次越高，容易看到人们思考得方式，可谓殊途同归，正如你写：毛主席老人家说，吸收进步力量、争取中间力量、孤立顽固力量，也充分体现了这一点。写软件和政治也有可比之处，还有拿软件工程和建筑相比得...一切一切，体现人思维方式。
我们头脑中应该建立一个抽象层次硬件底层（汇编指令）－>高级语言->uml类图->实际问题域。各个层次有许多复杂和变化得东东。还可以继续分层次和模块。
用例主要是捕获用户需求，主要是了解到底用户要这个系统为他做什么？所涉及有系统－人（actor）－及系统边界，用例可分为功能性用例和非功能用例（如界面颜色等）功能用例可分为主要功能，次要功能用例(次要场景)这是从全局来分析和规类用户得需求。具体细化可根据实际情况。 每个用例可以写用户场景。这是个问题域得问题。不要涉及类等下一层问题。所以用例分析只是一种工具，他能量化问题域模型。
uml类图是问题域的下一层，当然要和问题域要有衔接。这里就要说oo分析，他模糊了问题域和解域的距离。从问题域空间获取关键字来做类（生命模板）,这里就要把我们的实现放到类中，成为类的功能。可以理解为，我们把这个系统分配给许多的类（对象）来管理。如果类多（复杂），那么我们可以把类分为好几个“部门”层次（总部－分部a－分部b....）,小了好管理。其实mvc也是可以看做这个概念把（瞎想）。
。。。。。。。
写累了，请高手指点
Top
一个一般的、实用的mis系统往往有近百个业务类型，几百个活动。初学者往往一上来就拿几个活动当作用例，急于让人知道自己“会写用例”了。其实，对于项目经理（或者助理）这一级别的人，更注重去区分这些所谓用例的“重要性”——直接去表达最重要、影响最广、用户最关心的用例，而不是纠缠在细枝末节上裹足不前。有人说“从细节中进行有效的管理”，这个说法不错！但是，这恰恰是在抓住了重点之后，仅仅对重点问题利用这种方法进行清楚地表达。盲目地将普通的“活动”提升为“用例”的水平，软件分析的价值大大降低了！
因此，虽然实际需求是异常复杂的，但是用例未必复杂。“治乱”是行家的看家本事。
软件工程，最重要的并不是“分而治之”。分而治之是入门的知识，是关于结构的、静态的知识。一个软件，运行时随时可能响应不同的事件，这些事件发生次序没有规律，只有内在的关联条件（所谓数据驱动），分而治之只能很清楚地了解数据的结构，却不能方便地表达运动的规律。一个“夹子”它夹住了文件，从而使我能够顺利地将一个文档归档，这并不是因为我将夹子从物理方面分而治之；鲁迅述说的“第一个吃螃蟹的人”也不是因为对螃蟹作了分而治之。将一组活动“分而治之”是马后炮的做法，对于关联知识太庞杂、需要主动去寻找较好的解决问题的方法的领域无益。大部分生活中的“自然人”是根据框架、而不是结构去思考的，因此虽然它并不是钱币方面的专家，仍然比钱币专家更喜欢将钱币的功能发挥到极致。
Top
//分而治之是入门的知识，是关于结构的、静态的知识。一个软件，运行时随时可能响应不同的事件，这些事件发生次序没有规律，只有内在的关联条件（所谓数据驱动），分而治之只能很清楚地了解数据的结构，却不能方便地表达运动的规律//
用uml来建模，uml包括静态，动态概念。uml也有用来表示流程的活动图（但是不推荐）。不否认软件是对不同事件的响应，但是是杂乱的，理解困难的，所以把他们归类为静态的类以及动态的交互。这样概念不是清晰了？静态的模型可以使用分而治之策略，动态的模型体现对象的交流，完成软件的功能，可以用用例来指导，体现了一种思想，对象如人，如要建立一个服务器和客户端的网络连接，所涉及的问题很多，负责协议的解释，准确性校验，加密等，那么可以把这些任务分给不同的对象来完成。如给人分配任务一般，你去完成正确性校验，你去完成加密...分析软件就如同管理，只是管理这些对象，而具体的加工这些对象，那就要到对象工厂去加工，我们可以自给自足，也可叫别人去加工。但是分而治之很重要，所谓抓住框架，不要太零散。
个人理解，理解不当处望指正。
Top
gz ing
Top
学习啊
Top
usecase是一种动态模型，而不是静态模型，它比和静态的模型相配合才可以比较完整的反映一个系统的整体。那么什么是动态模型呢？在面向对象这个方法体系中那就是系统的概念模型－－系统的概念类图，也可以叫业务类图。这个类图所反映的就是系统所涉及的问题域中的概念，它们有的就是你的usecase中的actor。而这个类图往往是在最早就出现了，usecase多数情况下是在它开始建造后并行的和它共同建立的。这样的做法是标准的OO的做法，不管你是RUP也好，FDD也好,XP也好，大多如此。这个概念模型和USECASE模型会互相影响，互相说明，但是他们并不是由这个可以推导出那个的一种关系，也就是他们都有各自的特有部分，是不能相互替代的。这一点和UML没有任何的关系，你完全可以使用你的一种表示法去表达你的类。
分析的目标在于使我们更加清楚的理解问题的背景和内核，分析模型也只是为此而存在，分析模型和设计模型是有所不同的。我们可以看看分析模式，在第一章就讲到他们的不同。它举的一个例子是说台球我们可以很容易的建立其这个问题的分析模型，也就是会很容易捕捉到用例和类，但是这并不是说我们就会很简单的建议一个软件虚拟台球系统，我们还要去遵守多种多样的物理规则。而在商业环境中这样的物理规则是缺乏的，比如我们设计一个生产管理系统，我们可以很简单的知道一个环节的生产参数，并且对整个流程也可以很简单的俩机清楚，但是我们并不能因此就得到如何规划投料和制定各个生产环节的生产策略。如此我们必须清楚我们得到一个分析模型并不能代表我们就距离成功不远了，还有很多的事情我们要做。
而所谓的分的策略主要还是在于可以把系统进行迭代和增量的开发，只是可以顺便提高可理解性。
Top
最近心情好了，不想说话了，我决定继续潜水+_+
Top
受教了！谢谢！
Top
good. up.
Top
学习中……
up！
Top
up
Top
up
Top
up
Top
打字错误类图是静态模型 USECASE是动态模型
过于匆忙了 抱歉
Top
ozzzzzz,你继续啊！
期待你的精彩发言！
Top
usecase怎么和类图绞到一块去了，类图和状态图放一起说说还行，怎么和usecase比较去了，就这样还说什么这里是学术讨论区之类的话，真是侮辱学术这两个字。
这群人自管吵得热闹，见周伯通、郭靖等人到来，只道是华山的客人，也不理会。一名
铁塔般的大汉朗声说道：“大家且莫吵闹，乱打一气也非了局，这‘武功天下第一’的称
号，决不是叫叫嚷嚷便能得手的。今日各路好汉都已相聚于此，大伙儿何不便凭兵刃拳脚上
见个雌雄？只要谁能长胜不败，大家便心悦诚服，公推他为‘武功天下第一’”。一个长须
道人挥剑说道：“不错。武林中相传有‘华山论剑’的韵事，咱们今日便来论他一论，且看
当世英雄，到底是谁居首？”余人轰然叫好，便有数人抢先站出，大叫：“谁敢上来？”
周伯通、黄药师、一灯等人面面相觑，看这群人时，竟无一个识得。
Top
楼上看不过大可不必在此浪费时间笔墨。
Top
我时间很多，不怕浪费，我最喜欢做的事就是瞧热闹，看戏。
Top
我是刚刚接触软件工程，看了这么多帖子，觉得学习了很多的东西，高手就是高手呀。
Top
to moonsilver:
有点素养,不要诬蔑别人的劳动和智慧!
期待 精彩贴 和 o6z!!!!!
Top
仁者见仁，智者见智，如果你觉得讨论的是你不喜欢的。
你大可以不来看此贴，何必你认为不对的，就一定要别人
来认同你了呢？
我们期待ozzzz(希望敏捷）更精彩的发言。。
有时间就可以好好学习。。。不用去看热闹了。。
Top
学习 中
Top
freecs(北狼):
嘿嘿，我怎么“诬蔑别人的智慧了”？
Top
mark
Top
恩
应该好好看看拉
Top
根据《有效用例模式》，如果use case图中有add XXX, del XXX, edit XXX等，这个use case就不是好的use case.
Top
<script type="text/javascript"><!--google_ad_client = "pub-5088988998974111";google_alternate_ad_url = "http://topic.csdn.net/include/google_default_160_600.htm";google_ad_width = 160;google_ad_height = 600;google_ad_format = "160x600_as";google_ad_type = "text_image";google_ad_channel ="";google_color_border = "FFFFFF";google_color_bg = "FFFFFF";google_color_link = "0000CC";google_color_url = "008000";google_color_text = "6F6F6F";//--></script><script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript"></script>
问题点数：0、回复次数：66
一个消息管理系统。
http://www.hatfamily.com/a.jpg
请大家批评阿
1楼 ozzzzzz (希望敏捷) 
回复于 2003-12-17 11:20:48 得分 0
回复于 2003-12-17 11:20:48 得分 0 我刚刚在FAQ增加了几个USECASE的内容，请参照看一下。（在需求里面）
可以你现在还不真的知道什么是USECASE。
2楼 samllbig (沉默是金) 
回复于 2003-12-17 11:48:10 得分 0
回复于 2003-12-17 11:48:10 得分 0 谢谢你的批评，
好的，我去看看，能否指点一下我的认识
错误在那里呢？我希望提高
3楼 ozzzzzz (希望敏捷) 回复于 2003-12-17 15:43:55 得分 0
回复于 2003-12-17 15:43:55 得分 0 首先你要明白USECASE不是一种UML图，而是一种格式化文档。
如果你不把流程用文字或者图示的方法表示出来，就无法理解其所反映的流程到底要作什么以及怎么满足涉众的利益。光光那么一个USECASE DIAGRAM是不能说明什么问题的。
4楼 samllbig (沉默是金) 回复于 2003-12-17 17:30:47 得分 0
回复于 2003-12-17 17:30:47 得分 0 我明白了，其时我只是画一个用例图出来了，
至于用例主执行过程，我没有进行描述
5楼 ozzzzzz (希望敏捷) 回复于 2003-12-17 21:04:44 得分 0
回复于 2003-12-17 21:04:44 得分 0 你画一个用例图有什么用呢？除了说明有那么一些用例还能有什么作用吗？
6楼 zhuma (竹马) 回复于 2003-12-17 22:13:06 得分 0
回复于 2003-12-17 22:13:06 得分 0 我以前学写用例时写的使用叙述，是作为场景描述给下一步的用例书写做准备的。一时找不到用例描述了，下次找到了在另发。给你看看，也希望oz6指正一下。
J2PM使用叙述
新一年的江西省自然基金课题申请开始了。
又是一个晴朗的早晨，江西省自然基金委员会的沈主任走进办公室，打开电脑，准备整理一下往日的自然基金申报项目。沈主任启动了数据管理工具J2DM，先将整个数据库进行了备份，然后删除了两年以前的数据。
这时，江西自然研究所的石研究员走了进来，他是来上交自己今年的自然基金课题的申报书的。沈主任把石研究员带来的申请书的MS Word电子文档拷贝进了电脑。然后，沈主任一边打开自然基金项目管理系统J2PM，选择将申报书的内容导入到数据库中。一边告诉石研究员，江西金融研究所的施办事员申报的课题由于不符合申请规定，被系统自动淘汰了。这时系统自动查询了与石研究员的申请课题相关的历史数据，确认该课题符合申请规定，提示通过。石研究员很高兴，在表示感谢后离开了。接着，沈主任又把昨天Email收到的南昌基金学院的一批申请书一次性导入了数据库。
提高办事效率是南昌市政府职能部门当前的重要目标。石研究员一离开，沈主任就开始为刚导入的申报课题选择审查专家了。沈主任在J2PM中定位到石研究员的申报课题，又启动了专家管理系统J2EM。专家管理系统自动定位到了和申报课题相关的专家类上。沈主任根据J2EM中的专家信息为申报课题选择了五位专家。同样，沈主任为J2PM中的其它课题选择了审查专家。
下午，沈主任把打印好的各个申报课题的审查函寄发给了相应的专家。
两个月后的一天，沈主任的桌头放上了关于石研究员的申请课题的审查专家的第一份回函。沈主任启动J2PM，定位到石研究员的申请课题，输入了专家的意见和评分。这时，电话铃响了，沈主任拿起电话，原来是南昌基金学院的肖院长打来的电话，肖院长想了解一下本单位今年已经申报了多少课题。沈主任打开J2PM，对南昌基金学院进行查询。系统返回了南昌基金学院的课题申报信息。沈主任根据结果向肖院长作了答复。肖院长表示感谢后邀请沈主任有空时到南昌基金学院参观。沈主任愉快地接收了邀请。
又过了四个月，石研究员的申请课题的所有审查专家的回函期限到了，但只有三位专家发回了意见。于是，沈主任在J2PM中根据三位专家的意见和评分为石研究员的申请课题生成了最终评分。
十月是收获的季节，也是自然基金终审的日子。沈主任根据各个申请课题的总评分进行了最后的排名。最终，各学科组分类的排名前十位的课题得到了立项，其余课题被淘汰。
经过基金委的讨论，沈主任为立项的课题分配了经费，并在J2PM中记录了该信息。
石研究员的课题也得到了立项，但她感到分配的经费不足。于是，石研究员向基金委提出了增加经费的申请。基金委经过讨论，同意了石研究员的申请。沈主任根据新的决定更新了石研究员的项目信息。
一年后，沈主任收到了石研究员中止课题的申请。原来石研究员收到了毛里求斯大学的担任客座教授的邀请，为援助非洲兄弟的伟大使命而申请中止课题。基金委基金委经过讨论，同意了石研究员的申请。沈主任根据新的决定更新了石研究员的项目信息。
撰写《使用叙述》的问题：
1． 难以把握描述的精确度。
2． 开发组对虚拟环境的交互。
7楼 ozzzzzz (希望敏捷) 回复于 2003-12-18 00:38:16 得分 0
回复于 2003-12-18 00:38:16 得分 0 这不是一个场景，它包括了太多的元素。在你的阐述中包括了很多的用例，我先以一个来作例子讲一下到底怎么写用例。
比如我们先看第一个用例，叫－－备份数据。实际上这个名字也不是这个用例的最后名称，有多种不同的命名策略，但是“备份数据”这几个字是大家都会用到的。按照我的名字原则这个用例大概最后会叫－－用户备份数据，而用户这词我现在还没有把握，可能最后会有更加有针对的词，比如考虑到权限之类的因素的词。
然后我会看什么时候可以启动这个用例，当然是合法用户才可以使用这个功能，所以前置条件应该是已经完成登陆用例。大家注意这个时候很多人会考虑是不是有包含关系，我的看法是把它当作其前置条件更加符合实际情况。因为你不是每使用备份前都会使用登陆这个用例的，也许你早就登陆过了，完成了很多工作后才来备份的。而要是你使用包含关系的登陆往往就意味着，你在使用这个用例前必须先使用登陆用例，然后跟着开始备份。
确定前置条件后，马上就要确定启动场景，也就是什么时候这个用例开始启动。这个场景我描述为－－用户选择备份数据功能。大家注意，我没有使用用户点按钮或者菜单启动备份功能，这是因为用例是一种高层功能描述，不要和具体的实现绑定在一起。比如如果我用了绑定的办法，后来发现还可以通过使用快捷键方式启动这个用例，客户自定义在某个时刻启动这个用例，这个时候你就必须修改这个用例的写法，显然这是现在不必要的工作，我们会在具体如何实现这个用例的业务设计阶段去考虑这样的细节问题，现在还不是时候。
场景2－－用户选择要备份的数据。
场景3－－用户确认开始备份
场景4－－数据成功备份，显示备份成功。
场景4可以看作后置条件，它用来说明用例成功后的效果。
而上面我阐述的是用例的主流程，这是一个一切顺利的成功的流程。我们可以对其每一个场景最细化工作，比如场景3的确认可以细化为确认备份到数据库，备份到软驱，备份到磁带等，这些我们可以认为是场景3a、3b、3c等。
而同时我们还要考虑到一些意外的或者错误的情况。比如选择要备份的数据后，客户却觉得没有必要备份了。这个就是一个意外场景，我会命名它为－－！3。也可能是你选择备份到软盘，但是软驱中没有盘，这我可以认为它是一个意外，当然也可以认为它是一个错误，这不是太大的问题。而如果你选择的数据已经损坏，这显然就是一个错误，这就是一个错误场景，我会命名它为－－◎4。
上面这个例子只是为了说明怎么写用例，我要是真的去写则可能会把备份、删除、添加、拷贝等几个功能用一个用例－－客户维护数据。而同时大家也注意到，我们没有把主场景划分的过于细节，比如划分为15个场景。这样你会画太多的资源，因为每一个主场景都会涉及意外和错误场景，过多的主场景，会让你的用例描述过大，过于细节化，不利于理解用例的核心思想。
实际上写用例的过程，就是一个先明白大概要作什么，然后确定主场景，再以后你就可以去选择确定前置条件、后置条件、意外、错误，或者干脆就先细化一个场景，这个没有先后之分，只要你都作了就可以，什么先容易确定就先确定什么，只要你按照主流程场景为线索，把这些东西串起来就可以了。
8楼 samllbig (沉默是金) 回复于 2003-12-18 12:26:57 得分 0
回复于 2003-12-18 12:26:57 得分 0 ozzzzzz(希望敏捷) :
你的讲解非常精彩。把我看编写有效用例的东西都进行了一个
串联。真诚的感谢你！
9楼 samllbig (沉默是金) 回复于 2003-12-18 13:05:54 得分 0
回复于 2003-12-18 13:05:54 得分 0 看到你的讲解，我也想我的用例叙述贴上来，请ozzzzzz(希望敏捷) 指导，谢谢！
清晨，新贸公司的业务员小刘走进办公室，打开电脑，启动讯息通讯系统，
准备查阅公司的客户发来的消息。进入系统后。系统已经把发送给它的
新消息显示出来。他依次查看了这些消息。其中有一条是客户要求去市场上去
寻找“洗澡用的沐浴球的。他关掉讯息通讯系统。然后离开公司去了市场上去
找这种产品。他找到产品后。对产品进行拍照，询问了价格。然后回到公司。
将这个产品的资料和报价都整理成一份WORD文档。然后再次打开讯息通讯系统
搜索这条“洗澡用的沐浴球的”的消息。然后回复这条消息。将自己的在市场上
的情况写在消息中。在将其中的WORD文档附加在消息中。然后发消消息。中午。
当他再次进入讯息通讯系统时。客户的回复消息已经列在新消息中了。他查看了
消息。客户已经确认让他到市场上去采购。这时他要发送一条新消息给主管来
确认。于是他新建了一条消息。将情况都写在消息中。从部门列表中选择管理部
然后从管理部的人员列表中选择了BOSS。然后发送消息。中午他得到了主管的确认
他于是立即去市场上定货。
希望ozzzzzz(希望敏捷) 提出宝贵的意见。我对用例才入门，请你指点一下。
我的用例图分出来的用例是否正确。谢谢！！
10楼 ozzzzzz (希望敏捷) 回复于 2003-12-18 16:47:31 得分 0
回复于 2003-12-18 16:47:31 得分 0 用例图的作用在我看来就是初期标示出有那些用例，这个是最重要的功能，所以这个时候的用例是一个一个排列，不相联系的。我这么作是为具体表现用例作分配工作的准备，因为一个系统不会让一个人去写所有的用例，那么先划分到底有多少用例就很有必要。而下一步我可能会生成一个和你给我的用例类似的整体用例图，用来给大家说明用例间的联系，从而人大家从整体掌握系统的功能要求。但是往往项目成员在看了前面的各个用例以后就已经理解了系统的梗概，所以这个整体用例图就显得没有必要了。而其实我还可能根本就不画一个图，只是给出一个名字，联ACTOR都不确定，就把它分配给用例编写人员，让他们去确定到底谁是ACTOR，目的为何。
你上面的阐述只是列举了多个场景，那些都不是用例，我们还要作提纯工作。所以你应该按照我上面的方法在这个阐述中提纯出用例。
而在上面我的例子中，你会看到我没有提出写用例目标。并不是我忘记写这个重要的部分了，而是那个例子实在不能很好的说明用例目标的作用。用例目标其实就是参与者，通过这个用例所要达到的目标，从这个意义上说所有的用例都有一个目标－－更好的完成工作。当然这样的目标没有说明具体的问题，而“完成数据备份，以保存数据到一个客户希望的介质”，这样的阐述用来作用例目标是合适的。但是其实这个阐述在我看来，还是可有可无的，因为这个例子都是在体现这个目标。而实际上，有的用例所体系的目标绝对不是一个，也不是一个角色的目标。这个时候是最需要明确用例目标的，不然那里流程就会显得不合逻辑。比如一个用例是－－用户登陆。
主要场景是
1，用户启动系统，系统提示登陆，
2，用户输入用户名、密码，并确认
3，系统显示登陆成功 进入操作
然而这往往不是真正我们在最后写的用例，最后的用例大概会是这样
1，用户启动系统，系统提示登陆
2，用户输入用户名、密码，并确认
3，系统提示上一次用户登陆时间，并自动记录此次登陆时间
4，系统显示登陆成功，并自动进入操作界面
我们看到这2个用例书写方式中最大的不同，在于后面的第三场景，这个场景中的自动记录数据和显示上次登陆时间，显然不是满足用户使用系统这个目的的，而它们又是那么必要。所以这个用例其实所要完成的目标就还需要包括－－帮助用户检查有没有非法使用系统情况。而同时记录用户登陆时间的目标还要更加多，它还满足了使用系统的另外一些人的目标，比如管理员可以使用这个数据，监督系统的使用情况。而如此说来，用例目标就不能只是考虑到ACTOR的目标，而应该考虑所有会和这个用例产生关系的人的不同目标。如果有些人的目标没有被考虑到，你就用可能遗漏很重要的东西。
你还是去写一个用例来给我看看吧。你上面那个不是用例。
11楼 jonescheng (小块头无大智慧) 回复于 2003-12-19 10:48:54 得分 0
回复于 2003-12-19 10:48:54 得分 0 谢谢你希望敏捷。那我就把其中的一个用例贴在下面，请你多指点
用例： 发送消息
参与者: 公司职员
前置条件：用户已登陆
触发条件：用户选择消息发送功能
目的：将一条消息发送给指定的接收者
主执行场景：
1.用户选择系统中的消息发送功能
2.用户在用户列表中选择消息接收者
3.用户编辑消息
4.用户添加附件
5.用户确认发送消息
扩展场景没有填写，请希望敏捷批评
12楼 Jim3 (Jim) 回复于 2003-12-19 11:06:08 得分 0
回复于 2003-12-19 11:06:08 得分 0 好贴，顶＋收藏
13楼 scentdia (scentdia) 回复于 2003-12-19 12:03:29 得分 0
回复于 2003-12-19 12:03:29 得分 0 我这也有一个人力测评管理系统的用例描述，用例图就省了，大家看了下面的描述应该知道有些什么角色和用例，希望大家指正：
题库管理
1 题库类别管理
A 简短描述：根目录为：企业题库，根目录只有一个，不可新增，也不可删除，但可修改根目录名称；在根目录下，可新增、删除、修改子目录，子目录的层数至少能增加到三层，最好层数不限。
B 事件流程：系统提供新增，删除，修改目录的功能。选择根目录时，只提供修改和新增的功能；在选择其它目录情况下，可新增，删除，修改。
－ 新增：用户选定一个目录，系统默认这个选定目录为父目录，用户点击新增，系统自动新增一个子目录，并预设此目录名称为‘新目录’；系统提示用户为这个新目录命名，用户可命名或撤消操作，选择撤消，则系统自动删除这个‘新目录’；用户重新命名后，系统提示保存或撤消，选择保存则系统将判断这个新增目录是否与本目录下其他目录同名，如果同名，系统提示名称重复，要求用户重新命名，如果没有同名，系统将保存该新增目录；如果用户选择撤消，则系统自动删除该新增目录。
－ 删除：用户选定一个目录，点击删除，系统提示用户：将删除该目录下的所有子目录及该目录下的所有试题，删除后将不能恢复，请用户慎重考虑。如果用户选择确定要删除，系统将自动删除该目录及该目录下所有子目录及该目录下所有试题。如果用户选择取消，系统不做任何动作。
－ 修改：用户选定一个目录，点击修改，用户将可修改该目录的路径或名称。修改路径通过修改该目录的父目录编号来实现，如果用户填入的父目录编号不存在，系统提示：不存在该目录，撤消用户操作；如果用户填入的为该目录的子目录编号，系统提示：不可将该目录放在自己的子目录下，撤消用户操作；如果目标目录下有与该目录同名的目录，系统提示：目标目录下存在与该目录同名目录，系统将覆盖掉目标目录下同名目录及试题，用户选择确定，系统自动删除掉目标目录下的同名目录及试题，并将该目录及该目录的子目录和试题移到目标目录下，用户选择取消，系统不做任何动作。修改目录名称，系统将判断新名称是否与本目录下其他目录同名，如果同名，系统提示名称重复，要求用户重新命名，如果没有同名，系统将保存该目录的新名称；如果用户选择撤消，则系统不做任何动作。
2 试题管理
A 简短描述：系统提供新增，删除，修改的功能，试题有主观题，客观题。主观题有填空题和问答题，填空题有标准答案，问答题有标准答案或无标准答案。客观题有单项选择或多项选择，选项项数不定（两个选项以上，可三、四、五、六……），是非判断题可转为选择题处理。题目中会有图形。
－ 新增：用户选定一个目录，点击新增，系统自动将所在目录的编号值赋给新增试题的所在目录字段，并自动生成试题编号，该编号在整个题库中是唯一值。用户选择题形类别，系统自动将题形类别的编号赋给新增试题的题形类别字段，如果选主观题，系统再提示是否有图形，如果无图形，系统将产生两个文本框，如果有图形，系统将产生两个图形框。一个输入试题题目，一个输入试题答案（如果无标准答案则可不输）；如果选客观题，系统再提示是单项选择或多项选择，如果是单项选择，系统再提示是否有图形，如果无图形，系统将产生一个文本框，用于输入试题题目，同时产生一个列表，用于输入答案选项，选项内容，选项分值，答案选项不可重复。如果有图形，系统将产生一个图形框，用于输入试题题目，同时产生一个列表，用于输入答案选项，选项内容，选项分值，答案选项不可重复；如果是多项选择，系统再提示是否有图形，如果无图形，系统将产生一个文本框，用于输入试题题目，同时产生一个列表，用于输入答案选项，选项内容，选项判断，答案选项不可重复。如果有图形，系统将产生一个图形框，用于输入试题题目，同时产生一个列表，用于输入答案选项，选项内容，选项判断答案选项不可重复。
－ 删除：用户选定一道题目，系统列出题目及题目答案，点击删除，系统提示：将删除题目及该题目答案，如果用户选择确定，系统将删除该题目并自动删除该题目答案，如果用户选择撤消，系统不做任何动作。如果是选择题，用户选中答案选项，点击删除，系统则删除用户选中的答案选项。
－ 修改：用户选定一道题目，点击修改，系统列出该题目内容及答案或答案列表。用户可修改试题内容和试题答案和试题的所在目录编号，如果用户修改试题所在目录编号，系统将判断该目录编号是否存在，如果不存在则发出提示，如果存在，则继续判断该目录下是否还有子目录，如果有子目录则提示不可在该级目录下放置试题。用户不可修改试题的编号。用户也可直接修改主观题的试题答案或客观题的答案选项。
试卷管理
1 简短描述：用户进入试卷管理界面，系统列出已有试卷，并提供新增试卷，删除试卷和修改试卷的功能。如果用户在试卷列表中选中一份试卷，系统列出该份试卷的所有试题，如果用户选定该份试卷的一道试题，系统列出该道试题的答案。
－ 新增：用户点击新增，系统进入新增界面，自动列出企业题库，自动产生试卷编号，用户可修改试卷编号，填入试卷名称，系统判断试卷编号是否重复，如果重复则发出提示。输入完相关信息后，系统提示是否保存，用户保存后，系统提供新增、删除、修改试题的功能，用户选中企业题库中的试题，点击新增，系统将该题增加到试卷中，用户按ctrl或shift可进行多项的选择；如果用户选中企业题库中的目录，点击新增，系统将该目录下所有试题增加到该试卷中。
－ 删除：用户选中试卷列表中的试卷，点击删除，系统判断该试卷是否有用于测试，如果有用于测试，系统提示试卷已经被使用过，删除后无法得知使用该试卷进行测试的测试人员所参加测试的题目，但不会删除该试卷上的企业题库试题；如果没用于测试，系统提示该试卷删除后无法再用于测试，但不会删除该试卷上的企业题库试题。用户按确认，系统将删除该试卷，但不会删除曾使用此试卷进行测试的测评结果。用户按取消，系统不做任何动作。
－ 修改：用户选中试卷列表中的试卷，点击修改，系统进入修改界面，自动列出该试卷的相关信息，及所有试题列表，所提供的功能同新增界面一样，可修改试卷编号、试卷名称等相关信息，也可新增、修改、删除试卷中的试题。
测评管理
1 制定测评计划
A 简短描述：用户进入测评计划界面，系统列出已有测评计划，并提供新增，修改，删除的功能。用户选择一项计划，系统列出该计划的详细信息，包括使用试卷信息，参加测评的人员信息。
－新增：用户点击新增，系统提供已有试卷列表，人员(公司人员或应聘人员)列表，用户输入计划编号、名称等相关信息，系统判断计划计划编号是否重复，如果重复，系统提示重新输入，在列出的试卷中选择一份试卷，从人员列表中选择参加测评的人员。
－删除：用户选择一项计划，点击删除，系统提示将删除该计划及相关信息，包括使用试卷及参加该项测评的人员。
－修改：用户选择一项计划，点击修改，系统判断该计划有没有实施，如果实施，系统提示该计划已经实施，不可修改，如果未实施，系统列出该计划的详细信息，用户可修改计划的所有内容。
2测评实施
A 简短描述：用户以权限登录，系统列出可供选择的试卷，用户选择试卷，按确定，进入答题说明界面，简要说明答题方法、答题时间、题目数量等问题，用户按开始，进入答题界面，系统调出该份试卷，应聘人员开始答题。如有时间限制，系统自动计时，在时间结束前n分钟（可由用户自定义）提醒答题人员，时间到，系统自动退出答题程序，并保存答题结果；如无时间限制，答题人员在答完题后手动保存答题结果并退出答题程序，如未保存，系统也会自动保存每一道答题结果，在有效时间范围内，答题人员可对答题结果进行修改。
3测评结果统计分析
A 简短描述：用户登录测评结果统计分析界面，系统列出所有测评计划，用户选定一测评计划，系统列出该计划的详细信息，用户点击统计，系统根据试题类别，分类统计出各类别的分数，用户选定一测评对象，系统列出该测评对象的测评统计结果。
14楼 libi (风自吟) 
回复于 2003-12-19 13:01:12 得分 0
回复于 2003-12-19 13:01:12 得分 0 好帖，这正是我们新手需要的。领教了！另外也提提自己看了之后的一些想法。
o6z提到“根本就不画一个图，只是给出一个名字，联ACTOR都不确定，就把它分配给用例编写人员，让他们去确定到底谁是ACTOR，目的为何”，这与书上说的用例要for each相悖的。但是应该先用例还是先actor，这个问题争论起来就像鸡生蛋，蛋生鸡一样，无休止的。对于业务情况一点也不了解，从for each出发，可以让我们逐步找出用例，但对于一些情况，我们可能是先了解一点业务，可以找到一两个用例，或者这些业务涉及的人员比较多，一下还不能确定，再或者目前该用例的流程不合理，可能需要业务流程再造，那我们可以先提出用例，再考虑其actor和流程。具体情况具体应用，不一定非要按教科书的。
对于用例，我最感困惑的就是粒度问题，例如scentdia(scentdia)提的管理用例与新增、删除、修改等（老觉得scentdia用例描述别扭，但说不上道理来）。虽然粒度问题以各方能理解为度，靠系统分析员的经验去把握，但希望o6z能在这方面说说，或者用个例子来说。
不胜感激！
15楼 ozzzzzz (希望敏捷) 回复于 2003-12-19 13:09:45 得分 0
回复于 2003-12-19 13:09:45 得分 0 jonescheng(C#前进无极限)
用例名称需要加入一个主语，一般情况下会是主要角色。
而你没有写究竟什么时候用例结束，也就是后置条件。这个是很重要的。
3、4场景有问题，因为不一定每一次都会发附件，所以我会把4当作一个扩展场景。而且在我看来添加附件也是一种编辑行为。
scentdia(scentdia)
你提供的不是用例。而且请注意，对于目录之类的系统内部的细节最好在初期不要涉及，因为很可能我不采取目录树的方法，也许我会存储的数据库中呢？
而我希望你提供一个类似jonescheng(C#前进无极限)的用例，这样我才好开始分析你的问题。一下给出整个系统场景太乱，不利于说明究竟怎么写用例，当然实际中我们会给出这样一个整体的场景让大家了解系统梗概，可是在学习的时候这样就免了。
16楼 ozzzzzz (希望敏捷) 回复于 2003-12-19 13:32:57 得分 0
回复于 2003-12-19 13:32:57 得分 0 libi(风自吟)
看来我要收咨询费了，或者我也干脆办一个用例培训算了：）
我想你应该看到我和阎博士关于面向对象分析的讨论了，我关于不设置ACTOR就交给别人去写用例的动机就在于，我要使用面向对象的分析技术。
在我看来actor最后都会出现在分析模型中，他们都会成为一个分析类。而在编写用例的初期，我们很难确定到底actor是一个什么角色，而这个确认对于我建立面向对象的分析过程又那么重要，所以我才在开始不作决定，而把它留待合适的时间作出。而从这一点你也可以看出，我并不是说用例没有actor，而是说究竟那个actor是什么样子需要逐步的解决。而往往我们面对的商业应用（USECASE的主要分析领域），角色总是很复杂的。比如一个登陆用例，往往是很多人都在使用，而在初期就确定其actor是操作员，这样是不合适的。而不断发现actor的过程中，我们会发现一下actor是另外一下actor的子类，而有的则完全不相关。如果是子类，我就会把这个用例变为一个父类的操作。而不相关则会让我考虑使用操作类，来让大家调用这个公共登陆操作。这一系列的分析是和我后期的实际设计紧密相关的，所以请仔细体会我的做法。
粒度问题是用例的老大难问题，也是最终促使我放弃使用了这么就USECASE的主要原因。而从我的实践中我得到的结论是，主场景是最应该保持简捷的，也就是说主流程不能有太多的场景，我给自己的限度是9个（懒人的最高限度）。而同时对于用例间的粒度问题，比如增加删除之类的东西，如果我发现他们的主要场景基本相似，我就会把他们合并为一个用例。而在最开始的时候，我把一个用例从另外一个用例划分出来的时候，我是很谨慎的，这样作的唯一理由在我这里就是－－可以把过多的场景分开，也就是提高了用例的可理解程度。而这个标准也和具体的情况相联系，不要忘记用例最后是要给客户看的，是要被他们审核通过的。
17楼 yunhi () 回复于 2003-12-20 03:13:48 得分 0
回复于 2003-12-20 03:13:48 得分 0 好贴！mark
18楼 showerXP (小阿！) 
回复于 2003-12-20 14:24:52 得分 0
回复于 2003-12-20 14:24:52 得分 0 xuexi
19楼 GreenSpring (清青泉(www.iblogs.cn)) 回复于 2003-12-21 13:11:09 得分 0
回复于 2003-12-21 13:11:09 得分 0 study
20楼 csdnshao (如水人生) 回复于 2003-12-22 09:55:48 得分 0
回复于 2003-12-22 09:55:48 得分 0 支持一下！
21楼 mayuming513 (小马哥) 回复于 2003-12-22 11:07:40 得分 0
回复于 2003-12-22 11:07:40 得分 0 studying......
22楼 hbug () 回复于 2003-12-22 14:49:25 得分 0
回复于 2003-12-22 14:49:25 得分 0 to: scentdia(scentdia) ，能不能把你的用例图也公布出来看我们后辈学习学习呢？
23楼 hbug () 回复于 2003-12-22 14:51:17 得分 0
回复于 2003-12-22 14:51:17 得分 0 to:ozzzzzz(希望敏捷)
我刚刚在FAQ增加了几个USECASE的内容，请参照看一下。（在需求里面）
__________________________________________________________________
是在哪一个版块啊！我怎么找不到啊！谢谢！！
24楼 ozzzzzz (希望敏捷) 回复于 2003-12-22 15:10:55 得分 0
回复于 2003-12-22 15:10:55 得分 0 软件工程/管理 软件工程
需求管理活动
最后三个就是我新添加的
25楼 hbug () 回复于 2003-12-22 15:38:56 得分 0
回复于 2003-12-22 15:38:56 得分 0 to :ozzzzzz(希望敏捷)
多谢，我找到了，正在看！！
26楼 zgpp (要把专家分提上去) 回复于 2003-12-23 13:49:44 得分 0
回复于 2003-12-23 13:49:44 得分 0 保留
27楼 () 
回复于 2003-12-25 11:25:18 得分 0
回复于 2003-12-25 11:25:18 得分 0 这么好贴啊！
28楼 marvellin (我) 回复于 2003-12-25 16:41:13 得分 0
回复于 2003-12-25 16:41:13 得分 0 to :ozzzzzz(希望敏捷)
我怎么没有看见
软件工程/管理 软件工程
需求管理活动
郁闷ing
29楼 samllbig (沉默是金) 回复于 2003-12-25 18:16:40 得分 0
回复于 2003-12-25 18:16:40 得分 0 这么人在讨论，明天在放一些UML图和用例上来
请大家在批评批评
30楼 ozzzzzz (希望敏捷) 回复于 2003-12-25 18:23:03 得分 0
回复于 2003-12-25 18:23:03 得分 0 http://expert.csdn.net/Expert/FAQ/List_Room_FAQ_Index.asp?Roomid=401
这个是本版的FAQ地址。
http://expert.csdn.net/Expert/FAQ/FAQ_Index.asp?id=14041
http://expert.csdn.net/Expert/FAQ/FAQ_Index.asp?id=186095
http://expert.csdn.net/Expert/FAQ/FAQ_Index.asp?id=186115
http://expert.csdn.net/Expert/FAQ/FAQ_Index.asp?id=186119
31楼 xiaodaoren (*) 回复于 2003-12-27 00:13:59 得分 0
回复于 2003-12-27 00:13:59 得分 0 好好看书
32楼 wltsui (-无招胜有招-) 
回复于 2004-01-05 12:57:28 得分 0
回复于 2004-01-05 12:57:28 得分 0 up
33楼 raymond323 (raymond) 回复于 2004-01-05 20:31:59 得分 0
回复于 2004-01-05 20:31:59 得分 0 up
34楼 yunjian (刀剑如梦) 回复于 2004-01-07 13:54:19 得分 0
回复于 2004-01-07 13:54:19 得分 0 请教（希望敏捷）：
按照这样的说法，用例应该是在设计阶段做还是在分析阶段？
整个的流程又应该怎么走？
35楼 ozzzzzz (希望敏捷) 回复于 2004-01-07 14:22:11 得分 0
回复于 2004-01-07 14:22:11 得分 0 yunjian(刀剑如梦)
use case是一种公认的需求分析方法，当然我也见过一些人用它来作设计，只是这样的做法很笨拙。
但是使用USECASE基本还是一个迭代的过程，还是不断修改的过程。基本上不存在一个固定的流程，按照Cockburn的方法基本可以是先找到系统的使用者，然后确定使用者的各个目标，以此目标为用例的动机，然后确定用例的主流程，前置条件，后置条件，例外场景，新参与者，新后置条件。不断的迭代，逐步求得一个合适的描述。
而按照Jacobson的做法，则是先找到一个可观察的流程，并且确认其有显示的意义，这就把那些所谓“在对话框中输入用户名”的无意义的东西过虑了，从而保持了一个粒度的标准。然后是确认其主流程，前置条件，后置条件，等等和Cockburn类似的方法。
基本上对于初学者来说，我建议还是使用Cockburn的方法。初学者最好不要看国内的人写的关于USECASE的文章，最重要的是不要看umlchina的文章。基本上那个地方的人都是以为USECASE就是USECASE DIAGRAM的家伙，根本就不能给你们以什么实质性的帮助。
现在有三本书，我在http://expert.csdn.net/Expert/TopicView1.asp?id=2638058这个帖子中都介绍了一下。
36楼 twinsant124 (蚂蚁的天空) 回复于 2004-02-25 09:53:24 得分 0
回复于 2004-02-25 09:53:24 得分 0 好贴，好贴。
我把我另一个贴的观点挪过来
http://expert.csdn.net/Expert/topic/2761/2761611.xml?temp=1.914614E-02
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
一个系统最低要满足一个Actor的要求。我先解释一下我说的Actor（其实这个概念本来是我想在另一篇帖子UseCase++里去说的）。
在软件世界里，系统会有2种形态的表现，运行状态和维护状态，这两种状态下会对应着n个Actor。
例如，在运行态系统应该满足FirstActor的要求，使FirstActor能从系统的使用中获利，即CanWork。它也需要满足SecondActor的要求，使SecondActor在Context不满足的情况下也能正常使用该系统，即CanWorkCorrectly。它也要满足AntiActor的要求，所谓的AntiActor就是企图非法使用系统破坏FirstActor利益的用户，系统应该满足不能被AntiActor利用的要求，即CanWorkInSecurity，可以增加系统的更多的Actor，比如PerformanceActor等等。这些都是对运行态的系统提出的要求。
在维护状态，系统的表现（Presentation）应该满足对DevelperActor的基本要求，便于维护、调试、进化等等，甚至可以去满足开发者的虚荣心，即LookBeautiful。
一个系统的设计存在于两个状态之中，我决不认为那些所谓的乱七八糟的文档可以谓之为设计。当一个系统可以处在运行态的时候，那一定存在着设计，就像建筑的永恒之道所说的那样，它就在那里存在。而对这个设计的评价，就必须根据是否满足必要的Actor的要求而定。
一个系统的成长必须是根据Actor的各种要求，一级一级来的。我这里说一个系统设计的好与坏，必须根据实际情况去判断。没有该Actor的该要求，就不应该有对应的表现，否则我称之为过分设计。
37楼 twinsant124 (蚂蚁的天空) 回复于 2004-02-25 11:48:42 得分 0
回复于 2004-02-25 11:48:42 得分 0 I 也谈没有银弹
呵呵，题目大了些，其实俺只不过是个程序民工罢了，偶尔跑来灌灌水……
刚才又拜读了一遍人月神话的的没有银弹，大师说世界的主要问题在：
× 复杂度
× 一致性
× 可变性
× 不可见性
大师就是大师，一语破的，当头棒喝，让我明白了这个世界的真相。不过，我的记性一向不大好，记不住这么多条，就斗胆压缩了一下，把问题归结为两条：
× 复杂
× 变化
因为复杂，所以很难一目了然；因为变化，所以不可能千篇一律。
II 分而治之
计算机世界里最常见的手段就是：分而治之，当然，现实中也是一样，毛主席老人家说，吸收进步力量、争取中间力量、孤立顽固力量，也充分体现了这一点。
增量和迭代就是一种分而治之，只不过一个强调了空间一个强调了时间。
分有时候可以象砍瓜切菜，采用暴力手段，有时就必须学庖丁解牛，掌握一些技巧。
对待不变的我们用静态视图去描述理解，对待变化的我们用动态视图去描述理解。
用例分析中，从静态角度去观察，有几个重要的概念：
× Actor
× UseCase
× Context
所以，我不赞同o6z的做法，单纯的谈论用例还是从一个囫囵的角度去看去分析，我们还是应该先识别几个最重要的概念，才能够去做事情。
没有Actor，用例就失去了一个强内聚的结合点，多个用例会一盘散沙，最后的结果就会导致垃圾用例的出现。
没有UseCase，用例就失去了理解系统要求的基础，就没有用例技术本身存在的意义。
没有Context，用例就失去了赖以为生的环境，也会成为无人问津的废弃物。
分是一个问题，合也是一个问题。其实分，本身就破坏了系统，遗憾的是我们却都是盲人，只能通过触摸部分来认识这个混沌的世界。老子说：
“
道可道，非常道；名可名，非常名。
無名，天地之始；有名，万物之母。
故常無欲，以觀其妙；常有欲，以觀其徼。
此兩者，同出而异名，同謂之玄。
玄之又玄，眾妙之門。"
38楼 freecs (北狼) 回复于 2004-02-26 11:30:57 得分 0
回复于 2004-02-26 11:30:57 得分 0 up!
39楼 () 回复于 2004-02-26 16:49:17 得分 0
回复于 2004-02-26 16:49:17 得分 0 to twinsant124(蚂蚁的天空)
你觉得把精力花在这种纯理论的东西有用吗？ 我们只是工人，要靠解决实际问题吃饭的，这儿应该没有搞哲学的吧？弄一堆“玄之又玄”的东西唬唬人还能有什么用呢？ 就像以前在C++板块，一个关于OO和泛型的帖子回复到几百，最后都讨论到什么世界的本质上去了，最后解决什么问题了吗？ 个人观点，没有任何恶意的。
40楼 freecs (北狼) 回复于 2004-02-26 17:35:48 得分 0
回复于 2004-02-26 17:35:48 得分 0 楼上的兄弟，怎么能这么说呢？
多好的东西啊！
学习！
41楼 nblueguy (learner) 回复于 2004-02-26 23:33:36 得分 0
回复于 2004-02-26 23:33:36 得分 0 twinsant124(蚂蚁的天空)
写了不错。抽象层次越高，容易看到人们思考得方式，可谓殊途同归，正如你写：毛主席老人家说，吸收进步力量、争取中间力量、孤立顽固力量，也充分体现了这一点。写软件和政治也有可比之处，还有拿软件工程和建筑相比得...一切一切，体现人思维方式。
我们头脑中应该建立一个抽象层次硬件底层（汇编指令）－>高级语言->uml类图->实际问题域。各个层次有许多复杂和变化得东东。还可以继续分层次和模块。
用例主要是捕获用户需求，主要是了解到底用户要这个系统为他做什么？所涉及有系统－人（actor）－及系统边界，用例可分为功能性用例和非功能用例（如界面颜色等）功能用例可分为主要功能，次要功能用例(次要场景)这是从全局来分析和规类用户得需求。具体细化可根据实际情况。 每个用例可以写用户场景。这是个问题域得问题。不要涉及类等下一层问题。所以用例分析只是一种工具，他能量化问题域模型。
uml类图是问题域的下一层，当然要和问题域要有衔接。这里就要说oo分析，他模糊了问题域和解域的距离。从问题域空间获取关键字来做类（生命模板）,这里就要把我们的实现放到类中，成为类的功能。可以理解为，我们把这个系统分配给许多的类（对象）来管理。如果类多（复杂），那么我们可以把类分为好几个“部门”层次（总部－分部a－分部b....）,小了好管理。其实mvc也是可以看做这个概念把（瞎想）。
。。。。。。。
写累了，请高手指点
42楼 w_rose (w_rose) 回复于 2004-02-27 02:01:19 得分 0
回复于 2004-02-27 02:01:19 得分 0 一个一般的、实用的mis系统往往有近百个业务类型，几百个活动。初学者往往一上来就拿几个活动当作用例，急于让人知道自己“会写用例”了。其实，对于项目经理（或者助理）这一级别的人，更注重去区分这些所谓用例的“重要性”——直接去表达最重要、影响最广、用户最关心的用例，而不是纠缠在细枝末节上裹足不前。有人说“从细节中进行有效的管理”，这个说法不错！但是，这恰恰是在抓住了重点之后，仅仅对重点问题利用这种方法进行清楚地表达。盲目地将普通的“活动”提升为“用例”的水平，软件分析的价值大大降低了！
因此，虽然实际需求是异常复杂的，但是用例未必复杂。“治乱”是行家的看家本事。
软件工程，最重要的并不是“分而治之”。分而治之是入门的知识，是关于结构的、静态的知识。一个软件，运行时随时可能响应不同的事件，这些事件发生次序没有规律，只有内在的关联条件（所谓数据驱动），分而治之只能很清楚地了解数据的结构，却不能方便地表达运动的规律。一个“夹子”它夹住了文件，从而使我能够顺利地将一个文档归档，这并不是因为我将夹子从物理方面分而治之；鲁迅述说的“第一个吃螃蟹的人”也不是因为对螃蟹作了分而治之。将一组活动“分而治之”是马后炮的做法，对于关联知识太庞杂、需要主动去寻找较好的解决问题的方法的领域无益。大部分生活中的“自然人”是根据框架、而不是结构去思考的，因此虽然它并不是钱币方面的专家，仍然比钱币专家更喜欢将钱币的功能发挥到极致。
43楼 nblueguy (learner) 回复于 2004-02-27 10:33:51 得分 0
回复于 2004-02-27 10:33:51 得分 0 //分而治之是入门的知识，是关于结构的、静态的知识。一个软件，运行时随时可能响应不同的事件，这些事件发生次序没有规律，只有内在的关联条件（所谓数据驱动），分而治之只能很清楚地了解数据的结构，却不能方便地表达运动的规律//
用uml来建模，uml包括静态，动态概念。uml也有用来表示流程的活动图（但是不推荐）。不否认软件是对不同事件的响应，但是是杂乱的，理解困难的，所以把他们归类为静态的类以及动态的交互。这样概念不是清晰了？静态的模型可以使用分而治之策略，动态的模型体现对象的交流，完成软件的功能，可以用用例来指导，体现了一种思想，对象如人，如要建立一个服务器和客户端的网络连接，所涉及的问题很多，负责协议的解释，准确性校验，加密等，那么可以把这些任务分给不同的对象来完成。如给人分配任务一般，你去完成正确性校验，你去完成加密...分析软件就如同管理，只是管理这些对象，而具体的加工这些对象，那就要到对象工厂去加工，我们可以自给自足，也可叫别人去加工。但是分而治之很重要，所谓抓住框架，不要太零散。
个人理解，理解不当处望指正。
44楼 joachern (程序人生) 回复于 2004-02-27 11:26:28 得分 0
回复于 2004-02-27 11:26:28 得分 0 gz ing
45楼 matrixleon (仗剑江湖载酒行，楚腰纤细掌中轻) 回复于 2004-02-29 15:54:33 得分 0
回复于 2004-02-29 15:54:33 得分 0 学习啊
46楼 ozzzzzz (希望敏捷) 回复于 2004-02-29 16:45:37 得分 0
回复于 2004-02-29 16:45:37 得分 0 usecase是一种动态模型，而不是静态模型，它比和静态的模型相配合才可以比较完整的反映一个系统的整体。那么什么是动态模型呢？在面向对象这个方法体系中那就是系统的概念模型－－系统的概念类图，也可以叫业务类图。这个类图所反映的就是系统所涉及的问题域中的概念，它们有的就是你的usecase中的actor。而这个类图往往是在最早就出现了，usecase多数情况下是在它开始建造后并行的和它共同建立的。这样的做法是标准的OO的做法，不管你是RUP也好，FDD也好,XP也好，大多如此。这个概念模型和USECASE模型会互相影响，互相说明，但是他们并不是由这个可以推导出那个的一种关系，也就是他们都有各自的特有部分，是不能相互替代的。这一点和UML没有任何的关系，你完全可以使用你的一种表示法去表达你的类。
分析的目标在于使我们更加清楚的理解问题的背景和内核，分析模型也只是为此而存在，分析模型和设计模型是有所不同的。我们可以看看分析模式，在第一章就讲到他们的不同。它举的一个例子是说台球我们可以很容易的建立其这个问题的分析模型，也就是会很容易捕捉到用例和类，但是这并不是说我们就会很简单的建议一个软件虚拟台球系统，我们还要去遵守多种多样的物理规则。而在商业环境中这样的物理规则是缺乏的，比如我们设计一个生产管理系统，我们可以很简单的知道一个环节的生产参数，并且对整个流程也可以很简单的俩机清楚，但是我们并不能因此就得到如何规划投料和制定各个生产环节的生产策略。如此我们必须清楚我们得到一个分析模型并不能代表我们就距离成功不远了，还有很多的事情我们要做。
而所谓的分的策略主要还是在于可以把系统进行迭代和增量的开发，只是可以顺便提高可理解性。
47楼 twinsant124 (蚂蚁的天空) 回复于 2004-03-01 15:19:19 得分 0
回复于 2004-03-01 15:19:19 得分 0 最近心情好了，不想说话了，我决定继续潜水+_+
48楼 () 回复于 2004-03-03 16:28:36 得分 0
回复于 2004-03-03 16:28:36 得分 0 受教了！谢谢！
49楼 () 回复于 2004-03-03 18:31:13 得分 0
回复于 2004-03-03 18:31:13 得分 0 good. up.
50楼 CoLinM (林) 回复于 2004-03-06 15:47:21 得分 0
回复于 2004-03-06 15:47:21 得分 0 学习中……
up！
51楼 Ranma_True (乱马1/2(真)) 回复于 2004-03-06 20:35:40 得分 0
回复于 2004-03-06 20:35:40 得分 0 up
52楼 lr2000 () 回复于 2004-03-07 09:40:36 得分 0
回复于 2004-03-07 09:40:36 得分 0 up
53楼 windyezcross (windyezcross) 回复于 2004-03-10 15:08:19 得分 0
回复于 2004-03-10 15:08:19 得分 0 up
54楼 ozzzzzz (希望敏捷) 回复于 2004-03-10 15:18:26 得分 0
回复于 2004-03-10 15:18:26 得分 0 打字错误类图是静态模型 USECASE是动态模型
过于匆忙了 抱歉
55楼 freecs (北狼) 回复于 2004-03-12 20:18:39 得分 0
回复于 2004-03-12 20:18:39 得分 0 ozzzzzz,你继续啊！
期待你的精彩发言！
56楼 moonsilver (银月杀手) 回复于 2004-03-12 20:35:40 得分 0
回复于 2004-03-12 20:35:40 得分 0 usecase怎么和类图绞到一块去了，类图和状态图放一起说说还行，怎么和usecase比较去了，就这样还说什么这里是学术讨论区之类的话，真是侮辱学术这两个字。
这群人自管吵得热闹，见周伯通、郭靖等人到来，只道是华山的客人，也不理会。一名
铁塔般的大汉朗声说道：“大家且莫吵闹，乱打一气也非了局，这‘武功天下第一’的称
号，决不是叫叫嚷嚷便能得手的。今日各路好汉都已相聚于此，大伙儿何不便凭兵刃拳脚上
见个雌雄？只要谁能长胜不败，大家便心悦诚服，公推他为‘武功天下第一’”。一个长须
道人挥剑说道：“不错。武林中相传有‘华山论剑’的韵事，咱们今日便来论他一论，且看
当世英雄，到底是谁居首？”余人轰然叫好，便有数人抢先站出，大叫：“谁敢上来？”
周伯通、黄药师、一灯等人面面相觑，看这群人时，竟无一个识得。
57楼 swinging (山不在高) 回复于 2004-03-13 19:44:43 得分 0
回复于 2004-03-13 19:44:43 得分 0 楼上看不过大可不必在此浪费时间笔墨。
58楼 moonsilver (银月杀手) 回复于 2004-03-14 12:46:03 得分 0
回复于 2004-03-14 12:46:03 得分 0 我时间很多，不怕浪费，我最喜欢做的事就是瞧热闹，看戏。
59楼 () 回复于 2004-03-14 13:52:08 得分 0
回复于 2004-03-14 13:52:08 得分 0 我是刚刚接触软件工程，看了这么多帖子，觉得学习了很多的东西，高手就是高手呀。
60楼 freecs (北狼) 回复于 2004-03-20 09:18:04 得分 0
回复于 2004-03-20 09:18:04 得分 0 to moonsilver:
有点素养,不要诬蔑别人的劳动和智慧!
期待 精彩贴 和 o6z!!!!!
61楼 jonescheng (小块头无大智慧) 回复于 2004-03-20 11:06:56 得分 0
回复于 2004-03-20 11:06:56 得分 0 仁者见仁，智者见智，如果你觉得讨论的是你不喜欢的。
你大可以不来看此贴，何必你认为不对的，就一定要别人
来认同你了呢？
我们期待ozzzz(希望敏捷）更精彩的发言。。
有时间就可以好好学习。。。不用去看热闹了。。
62楼 flyingxfxf (偶尔堕落) 回复于 2004-03-20 17:32:08 得分 0
回复于 2004-03-20 17:32:08 得分 0 学习 中
63楼 moonsilver (银月杀手) 回复于 2004-03-21 03:05:28 得分 0
回复于 2004-03-21 03:05:28 得分 0 freecs(北狼):
嘿嘿，我怎么“诬蔑别人的智慧了”？
64楼 water2ice (没有影子) 回复于 2004-03-21 19:46:25 得分 0
回复于 2004-03-21 19:46:25 得分 0 mark
65楼 () 回复于 2004-03-21 22:46:32 得分 0
回复于 2004-03-21 22:46:32 得分 0 恩
应该好好看看拉
66楼 AutoAsm (风流总被雨打风吹去) 
回复于 2004-03-25 15:59:03 得分 0
回复于 2004-03-25 15:59:03 得分 0 根据《有效用例模式》，如果use case图中有add XXX, del XXX, edit XXX等，这个use case就不是好的use case.
网站简介－广告服务－网站地图－帮助信息－联系方式－English－问题报告
CSDN北京百联美达美数码科技有限公司 版权所有 京 ICP 证 020026 号 CSDN
© 2000-04, CSDN.NET, All Rights Reserved
- 用例设计
- 测试用例设计
- 设计用例
- 测试用例设计
- 用例设计
- 用例设计心得
- 用例设计
- 测试用例设计
- 测试用例设计
- 测试用例设计
- 测试用例设计
- 测试用例设计
- 用例设计大全
- 测试用例设计
- 测试用例设计
- 测试用例设计
- 用例设计
- 设计模式用例
- 常用Javascript代码
- Eclipse3.01 + MinGW3.1配置标准C/C++开发环境
- .Net基本概念
- 给网友良少的一封回信，希望能结识更多的志同道合者！
- 正则表达式30分钟入门教程
- 设计用例
- 复杂性话题之总结
- windows下使用makefile编译C语言.doc
- 收集的CSS仿经典下拉菜单
- SQL server2000 安装文件挂起错误的解决办法
- 如何高亮显示关键字
- XML基础
- sql中压缩日志文件和ntextl转化为varchar的处理(downmoon)
- 163改版了~~
