!用例与gui设计的关系 .txt

一些关于UML的经典讨论

god2000   用例就是菜单项
　
http://www.umlchina.com/best/g34/u1152270.htm

--------------------------------------------------------------------------------
 
用例既然为用户与系统的功能接口，在gui程序中好像就是菜单项，不只这里面有没有一定的对应关系。当然每个菜单项与按钮肯定联系者一些操作
 
 03/10/30 08:54 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  “就是”一词打上引号，表达也许准确一些
　
--------------------------------------------------------------------------------
 
这里谈到用例与GUI设计的关系 

用例是从用户和系统之间进行交互的接口的角度，来观察系统外部应该具备的表现。“应该”的意思是，系统的表现必须符合用户的某种目的。所以，与其说用例是用来描述系统的，还不如说用例是用来描述用户的目的的。 

这个接口，当然是指逻辑意义上的数据和行为的交互，最终主要是表现在软件的GUI界面的实现上。当然，“用户”也可能是目标系统以外的其他系统，不一定是人，这时，也许需要其他比如通讯接口，协议之类的实现。 

“是”这个词在自然语言中有好些含义,如：1.等同于同一事物，2.类似于另一事物，3.对应于另一事物。楼主的含义应该是取第三个的一部分。 
 
 03/10/30 09:09 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 sealw  那对于没有菜单的应用（系统）呢？
　
--------------------------------------------------------------------------------
 
 03/10/30 09:29 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 qingrun   还有一些系统自动处理完成的业务，也不会展现在菜单中呀。这又如何解释呢？
　
--------------------------------------------------------------------------------
 
 03/10/30 10:24 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 god2000   回复: 谢谢各位高人，继续深入如下
　
--------------------------------------------------------------------------------
 
1、回qingrun 
其它系统作为外部角色确实无法表达。我这个说法一个目的想破除对用例的神秘感，很多程序员可以很快的做一个完整的菜单出来，却陷在用例糊涂了，我就是其中之一。菜单项做为用例的一部分，甚至有些菜单也不是用例，但其间确有一定的对应关系，这种认识的价值下文论述。 
2、回sealw 
程序总有操作接口，可能表述为操作接口更合适，但不易理解了 
3、回babituo 
若这种认识有一定道理，那么用例对GUI设计就有很强的指导作用，我以前做项目用户老要DEMO,拿用例给他们解释恐怕很难。用例中对用户操作的相关性表达的很精确，根据这种相关性在GUI中安排操作点应该能让用户舒服些。在用例定义完成后就可以做DEMO或界面设计了 
　
 
 03/10/30 10:51 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  用例与GUI设计是大有关系
　
--------------------------------------------------------------------------------
 
开发用例模型首先是发现用例，发现用例之前可以是发现主角，如果是开发系统用例，这些工作以业务模型为基础。 

我们讨论的是发现用例之后的情况，GUI设计的位置， 
发现用例之后，我们要设计用例的事件流。 
事件流就是主角（用户）和系统之间的交互过程，这各过程从系统外部描述主角为了实现自己的某个目的而需要向系统发出的一系列的数据信息和行动指令，系统作出什么反应来引导主角最终期望得到的结果。 
我们要注意的是，用例的开发自始至终都要围绕主角的某个目的。这个目的可以是得到一个结果，要保证目的被表达得清晰和相对完整。 

由于用户的目的往往不是走一条直线过程就完成了的，即用户的目的是有结构的。一个目的的达成需要依赖另外一些目的的达成，所以，就会出现一个达到目的的一个路网，这个路网就是一个有向图，有向图有端口的结点和中间的结点。 
不要以为中间的结点只是描述系统的行为，同样也是描述主角和系统的交互行为，只是中间结点也许是到达多个出口结点（用户最终目标）的枢纽。 

有了这张“有向图”，就可以开始设计GUI了。设计GUI不仅仅是设计操作点的元件，更重要的是设计用户操作的导航路径，设计这些导航路径的原始信息，就是这张有向图：清楚地表达了用户每个目标实现过程中的每一站和这些站之间的关系。 

至于界面元件的应用，完全根据用户在该“站”上与系统要交户的内容特点来确定。 

这里有必要谈到界面原型的设计，在没有使用用例模型之前，界面原型是启发用户需求的很好的办法。但也会带来一些负面的作用，如：容易对界面设计带来限制，容易把注意力引到系统外观设计，而不是用户内在需求上。 
在使用用例模型方法之后，界面原型成为研讨用例的主要手段之一。基于一个可视的交互界面原型，开发用例事件流变得更好操作。也不会对界面设计带来限制。 
 
 03/10/30 11:45 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 god2000   回复: 用例定义、用例分析、用例实现的界限
　
--------------------------------------------------------------------------------
 
以系统为例 
用例定义描述了用户要做什么，他在完成这个用例时的动作序列可分为（点击按钮、输入数据两类吧）这时是否定义清楚要输入的数据呢 
系统用例分析用活动图，好像是在定义的基础上将内部的活动补上。对于较小的用例是否可以直接用交互图实现 
分析和实现的界限和相关技术该怎样说 
 
 03/10/30 12:35 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  从用例模型到对象模型的过程
　
--------------------------------------------------------------------------------
 
用例研讨（需求获取） 
——发现主角和用例 
——开发界面原型（得到边界类） 
——详细说明用例（文字事件流，活动图） 
用例分析（分析设计） 
——查找分析类 
——建立分析设计模型（类-关联图） 
——实现用例(顺序图，协作图) 
 
 03/10/30 13:51 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 decapli   回复: 用例就是菜单项
　
--------------------------------------------------------------------------------
 
菜单项是各种功能，很琐碎。 
用例的粒度到不了那么细吧？ 

等号肯定是划不上的。 

而且，用户界面只能涵盖系统功能的一部分，所以也只是反映了一部分用例。
 
 03/10/30 13:55 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  已更新回复
　
--------------------------------------------------------------------------------
 
 03/10/30 14:54 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 god2000   回复:其余部分可以理解，实现用例到什么程度呢，其对编程的指导价值
　
--------------------------------------------------------------------------------
 
我感到用例有两种功能：为系统分析的起点和对系统的验证 
用例实现很大程度上为脚本推演:一组对象形成的语境，然后由一个对象发起，引起一系列动作。从中可以将分析类逐步充实为设计类。跨越分析与设计两个阶段，问题在于系统平台相关部分这时需要考虑吗，有一些通用的协作机制（设计模式）这时引入吗。用例实现有可能会引入大量的交互图，甚至一个用例要用多副图来表达，怎样避免设计过度呢。 

　
 
 03/10/30 18:46 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 j2ee  why?
　
--------------------------------------------------------------------------------
 
 03/10/30 23:52 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 j2ee  糊涂
　
--------------------------------------------------------------------------------
 
 03/10/31 00:01 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 god2000   回复: 愿听高见，摆出来就是接受批评的
　
--------------------------------------------------------------------------------
 
 03/10/31 08:49 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 sealw  如果站在须弥芥子，乾坤马一毛的高度来看，这是有道理的
　
--------------------------------------------------------------------------------
 
空中无色，无受想行识。 

所谓用例，即非用例，是名用例。
 
 03/10/31 09:19 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 savagearts  回复: 愿听高见，摆出来就是接受批评的
　
--------------------------------------------------------------------------------
 
在某种程度上说，用例就是菜单项有一定的正确性。 
用例就是的本质就是需求。菜单项是用户的需求么？不是，它只是一种表现系统行为的表现形式而已。所以他不是用例。但是菜单项同时也代表了用户想要得到具有价值的东西，所以可以说是用例。就好像前面一些哥们提到的“还有一些不易被观测的用例“就不能简单地说是菜单项。
 
 03/10/31 13:52 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  关于用例实现的目的理解可能有偏差。
　
--------------------------------------------------------------------------------
 
我感到用例有两种功能：为系统分析的起点和对系统的验证 
[同意]。 
用例实现很大程度上为脚本推演:一组对象形成的语境，然后由一个对象发起，引起一系列动作。从中可以将分析类逐步充实为设计类。跨越分析与设计两个阶段， 
[同意] 
问题在于系统平台相关部分这时需要考虑吗 
[在设计模型中应开始考虑，主要在部署模型中（物理设计）考虑]， 
有一些通用的协作机制（设计模式）这时引入吗 
[适合问题的模式应该引入]。 
用例实现有可能会引入大量的交互图，甚至一个用例要用多副图来表达，怎样避免设计过度呢。 
[用例实现的主要目的不是为指导编码，而是用来跟踪需求，验证分析设计模型和用例模型的一致性，指导编码的应该是构件模型。] 

关于设计过度，我从来就没有过这种经历，不知道谁有？ 
我理解有一种担心：分析设计（逻辑设计）太详细了，以至于详细到重新设计一些已有的构件的内部逻辑了。这样会导致对物理设计和编码的误导。 
我相信大家在开发中很少经历逻辑设计阶段，多数是直接进行物理设计，我认为：这种担心出现在物理设计阶段是合理的，但在逻辑设计阶段是多余的，关键是大家很少做真正的逻辑设计。 
即使是我个人的经历，往往也不能从头到走遍分析模型，设计模型，构件模型和部署（物理）模型。曾经有人拿我的逻辑设计就去编程，结果不是说设计过度，就是说设计不清晰。当然，大多数老到一点的程序员都很聪明，他们能在头脑中完成物理设计，他们更欢迎清晰的逻辑设计，巴不得你的逻辑设计“过度”一些。
 
 03/10/31 17:12 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 j2ee  用例是用户和系统打交道的一个场景，反映了用户/外部系统如何使用系统
　
--------------------------------------------------------------------------------
 
菜单只是用户和计算机交互手段--图形用户界面的一个元素。没有本质上的关联。 

用例是对需求的捕捉，菜单是对交互的设计。一个用例的一部分可能用菜单实现，一个用例也可以由多个菜单/Button，快捷键实现，菜单可以不反映用例，
 
 03/10/31 22:12 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 j2ee  从方法学上用例更在乎系统的边界，是面向对象方法的一个部分。至于菜单完全可以是功能分解的一个体现。
　
--------------------------------------------------------------------------------
 
 03/10/31 22:14 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 god2000   回复: 您真是一位好导师
　
--------------------------------------------------------------------------------
 
我的理解的确有问题，根源其实在对交互图的使用上，做图时明明想着去实现一个用例，但往往就过细了，成了指导编程的操作实现了。交互图的两种用法 
操作实现和用例实现细化程度不同，只对复杂的操作用交互图。 

您的逻辑设计和物理设计的区分让我收益匪浅，我以前做的都是大都为逻辑设计，然后就开始编程了，问题在于操作实现和复杂算法设计（状态机）应该在逻辑阶段还是物理设计阶段呢