📄 请问use case图和class图有什么关系.txt
字号:
作者 内容
qsqwmy 请问Use Case图和Class图有什么关系?
http://www.shecn.com/best/g32/u1147405.htm
--------------------------------------------------------------------------------
是不是Class图的设计由Use Case图而来呢?
03/05/12 08:34 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
gene_cn 基本上是先捕捉用例,也就是需求,然后才有CLASS,但也可以直接画CLASS框图,这要看你对系统的熟悉程度。
--------------------------------------------------------------------------------
03/05/12 08:50 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
qsqwmy 回复: 基本上是先捕捉用例,也就是需求,然后才有CLASS,但也可以直接画CLASS框图,这要看你对系统的熟悉程度。
--------------------------------------------------------------------------------
那么用例决定类吗?比如说由这个用例,我们可以得出我们需要某几个类,由另外一个用例我们又得出另外需要几个类。有这种层次的关系吗?
03/05/12 08:57 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
gene_cn 也可以这样说,任何开发出来的软件都必须满足需求,CLASS是实现需求的一种元素。
--------------------------------------------------------------------------------
03/05/12 09:00 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
qsqwmy 回复: 也可以这样说,任何开发出来的软件都必须满足需求,CLASS是实现需求的一种元素。
--------------------------------------------------------------------------------
我就是在根据Use Cases图设计Class这一方面找不到感觉,我感觉自己设计Class的时候好像是脱离了Use Case的。
03/05/12 09:09 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
gene_cn 那你要一步一步来,先从业务用例图和它的活动图,然后系统用例和它的时序图,协作图,最后是类图,数据库结构图,这样认真做下去,你的感觉就会很好。
--------------------------------------------------------------------------------
03/05/12 09:14 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
qsqwmy 回复: 那你要一步一步来,先从业务用例图和它的活动图,然后系统用例和它的时序图,协作图,最后是类图,数据库结构图,这样认真做下去,你的感觉就会很好。
--------------------------------------------------------------------------------
好的,继续努力………………
多谢了!!
03/05/12 09:21 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
xuf0000 回复: 请问Use Case图和Class图有什么关系?
--------------------------------------------------------------------------------
本质上其实Use Case只是帮助你搞清楚客户究竟要做什么这个问题,以前我们主要是用文字来描述,如SRS,但辅以用例图的话可能更清晰直观,所以在做用例的时候(也就是在了解做什么)最好不要想到其它详细的东西,至多考虑一下架构。类图只是在对需求(用例)做分析时才使用的,如根据客户的业务情况抽象出不同的类如实体,边界,控制等。所以说Use Case diagram和Class diagram并不是非要有什么对应的关系,Use Case只是使用者的视图,Class 则是实施者的视图,唉,这其间的东西很难要语言来表达...多做几年就理解了。
03/05/13 12:56 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
qsqwmy 回复: 请问Use Case图和Class图有什么关系?
--------------------------------------------------------------------------------
终于明白了,多谢!!
03/05/13 13:07 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
babituo Use Case从外部描述有哪些主角(Actor)提出哪些过程需求,Class从内部表达主角的所有过程请求靠怎样设计的角色(Work)来协作完成。
--------------------------------------------------------------------------------
一个主外,一个主内;
从外到内,里应外合,完成需求到设计的过渡和保证一致性。
03/05/13 14:09 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
qsqwmy 回复: Use Case从外部描述有哪些主角(Actor)提出哪些过程需求,Class从内部表达主角的所有过程请求靠怎样设计的角色(Work)来协作完成。
--------------------------------------------------------------------------------
好理论的东西呀,这可比写一个函数难多了,呵呵……
03/05/15 08:11 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
babituo 为什么分析设计会难过编程?(跑点题)
--------------------------------------------------------------------------------
在某种意义上讲,分析设计和编程完全是一回事:就是讲清楚同一件可重复发生的事情的原尾。只不过用的语言符号不一样而已。
我发现有些程序员往往使用编程语言来表达一个需求比用自然语言还来得快和准。就是与客户交流起来困难。
编程语言是程序员惯用的思考语言,分析设计语言比编程语言更接近自然语言,也就是普通人的思考语言,应该比编程语言更容易学习和掌握。为什么在程序员看来用分析设计语言表达用户的需求反而难过用编程语言呢?
有没有大家是先学习编程语言,再学分析设计语言方面的原因?
可不可以适当地反过来?
计算机软件的教育也许有入口错误。急于求成,急于让学生尽快了解计算机的资源,而忘了从普通人的资源逐渐演变过去。
03/05/15 11:41 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
qsqwmy 回复: 为什么分析设计会难过编程?(跑点题)
--------------------------------------------------------------------------------
说的有道理,可能是因为先学编程,再学分析的缘故,可是我觉得要是分析的话,有一定的编程经验会更加有帮助才是。
03/05/15 12:03 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
babituo 大家都这么说,我也不反对这种说法,可你知道这是为什么吗?
--------------------------------------------------------------------------------
03/05/15 14:32 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
qsqwmy 回复: 大家都这么说,我也不反对这种说法,可你知道这是为什么吗?
--------------------------------------------------------------------------------
老实说,我也不知道为什么,愿闻其详。
03/05/15 14:55 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
snakerlee 你为什么要做软件呢?因为要编出一堆代码?
--------------------------------------------------------------------------------
03/05/15 16:44 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
snakerlee 我倒是觉得应该有对应关系,但不是一一对应关系
--------------------------------------------------------------------------------
因为要修改、提炼、升华嘛
03/05/15 16:46 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
gaojuntao 回复: 为什么分析设计会难过编程?(跑点题)
--------------------------------------------------------------------------------
分析设计的重点是从总体上把握系统,他们的职责在保障软件各种质量属性:
如,可扩展性、易维护性等。
程序员的重点是保障整个系统在局部上的质量。
一句话,一个把握宏观,而另一个的工作焦点在局部。
03/05/15 17:03 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
heyongbin 回复: 大家都这么说,我也不反对这种说法,可你知道这是为什么吗?
--------------------------------------------------------------------------------
个人特质第一,后天学习第二,编码与分析设计的差异还是挺大的。有些人是很难去做分析设计的,但也有计算机基础差,却很适合做分析设计。有一次我见到一个863专家,他的课题是数字(某省),他可能从来没有写过程序,但思路特好,可能与他长期做课题Leader 有关把。
03/05/15 18:14 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
zhxb 回复: 请问Use Case图和Class图有什么关系?
--------------------------------------------------------------------------------
我认为:1、如果已经存在领域模型,则就可以产生Class图;2、对于业务对象,并一定是从用例图产生出来,可以通过其它方式来产生,这些业务对象可以直接产生的类图。
其实,对于OMT来说,不一定需要用例来进行分析设计,通过短语分析从问题描述中取得类的信息(名称、属性、操作)。
03/05/15 19:51 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
babituo 我也只是有自己的感觉.
--------------------------------------------------------------------------------
为什么做分析设计的人有编程经验会更好,就好比搞建筑和结构设计的工程师有施工经验会更好一样。主要解决的是一个“实现”问题。即你发现的问题是否有可行的解决办法,你设计的解决方案是否存在在经济,技术,工艺上的实现手段。
这个问题很重要吗?是很重要,如果发现的问题不可解决,设计的方案不可实现,那么项目必然失败。
这个问题一定会出现吗?也就是说,如果分析设计师没有编程经验,就一定会导致他的分析设计方案不可实现吗?不见得。分析设计师其他方面的阅历是可以降低这个风险的。比如他见过的失败的方案足够多,他有丰富的软件使用经验等等。
闻道有先后,术业有专攻,隔行如隔山。也许这才是分析设计难于编程的根本原因吧。
03/05/16 09:21 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首
qsqwmy 回复: 我也只是有自己的感觉.
--------------------------------------------------------------------------------
很有道理,赞同赞同………………
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -