平平 (11*****84) 2012-10-24 16:56:56
我认为通过用例规约的书写可以找出各种分析类（边界类，控制类，及实体类），所以我认为用例规约中可以名说边界啊。
　平平 (11*****84) 2012-10-24 17:00:12
1：参与者提出注册请求；
2：系统显示注册界面；
3：参与者填写登录名字；
4：系统验证登录名字的有效性；
5：参与者填写密码；
6：系统检验密码的有效性；
7：参与者重复录入密码，确保一致性；
8：参与者选择找回密码需要回答的问题；
9：参与者填写答案；
10：参与者填写信息邮箱；
11：系统验证邮箱的有效性；
12：参与者提交注册信息；
13：系统提示注册成功。
　平平 (11*****84) 2012-10-24 17:00:44
比如说注册这个用例的执行过程，这样写有问题么？
　平平 (11*****84) 2012-10-24 17:01:46
或者：1.用户申请注册2.用户填写注册信息。3.系统保存注册信息。4.注册完成 这样简单写输入输出么？
　平平 (11*****84) 2012-10-24 17:02:32
第一种写法，可以知道有个注册的控制类，及注册的边界类，及注册用户的实体类。
　平平 (11*****84) 2012-10-24 17:03:26
那如何表示注册的路径？
潘加宇 (3504847) 2012-10-24 22:32:23
@3-12应合并，聚焦于输入-处理-输出的信息，而不是交互的细节
潘加宇 (3504847) 2012-10-24 22:33:26
然后再加上相应的补充约束：验证的规则（业务规则），操作次数（非功能需求）。。。
潘加宇 (3504847) 2012-10-24 22:34:06
交互的解决方案应该由有交互设计技能的设计人员来决定
潘加宇 (3504847) 2012-10-24 22:35:36

潘加宇 (3504847) 2012-10-24 22:36:08

潘加宇 (3504847) 2012-10-24 22:36:15
课上幻灯片有
潘加宇 (3504847) 2012-10-24 22:41:10
@平平(11*****84) 2012/10/24 17:01:46 第一种写法，可以知道有个注册的控制类，及注册的边界类，及注册用户的实体类。
--如果是一一对应的东西，知道和不知道一样，没有价值。"哇，我发现一个边界类"，有什么用，谁不知道有边界。
--复杂度就在于需求和设计是多对多的，那个多对那个多更好一点，只能由人脑来权衡，责任分配的焦点是实体类之间的协作
　平平 (11*****84) 2012-10-26 17:15:40
类可以转换成顺序图中的对象，但是顺序图中的对象不能变成类？那先分析用例的实现中的对象，还要在分析中重新定义类？
潘加宇 (3504847) 2012-10-26 17:29:45
先有类，才有对象，你的困惑在那里？
　平平 (11*****84) 2012-10-26 17:31:21
我先分析用例，然后是用例实现（通过用例实现找出了各个对象。）每个对象可能形成某类
Life note (2***9) 2012-10-26 17:33:32
我也这样想的先有对象在从对象形成类哦
　平平 (11*****84) 2012-10-26 17:34:25
先找类，感觉不好下手，而且不全面。
潘加宇(3504847) 8:21:58
参见下文
潘加宇(3504847) 8:22:01

　平平 (11*****84) 2012-10-26 17:38:04
将类从分析拖到设计窗口，总是提问作为一个连接，还是**对象。能不能复制？
潘加宇(3504847) 8:23:43
copy， paste as new
　平平 (11*****84) 2012-10-26 17:37:06
我还有一个问题，类的分析到设计的时候，
　平平 (11*****84) 2012-10-26 17:40:11
就是如何保证设计类包中的类和分析类包中的类数量及名称一致，而仅仅是设计更多属性等内容
潘加宇(3504847) 8:28:59
--"如何保证"的意思是？模型里有什么类都是你自己定的
--分析和设计的区别并不是把分析的"细化"一下
--另外，推荐做法，不需要对所有分析模型做设计的UML模型，只需要针对典型的交互和类做一下就可以。程序员需要的是分析模型和典型用例的实现案例，通过培训，举一反三，根据分析模型来实现。