CSDN博客

img baijian_8d

UML案例讨论

发表于2004/11/4 9:54:00  3215人阅读

来源:UMLCHINA

网址:www.umlchina.com


作者 内容
 frankfufjf   一个案例分析,请各位参与讨论
 

最近在上软件工程的课程,这道题是练习课老师给出的一个案例分析。我估计所有的知识点都是通过这个案例给出的。所以把这个案例贴过来,有兴趣的朋友可以一起参与讨论,我也会定期更新,把老师的参考方案贴出来。高手们如果觉得我们老师的方案有问题,也希望能够提出不同的看法。
因为我的外语水平还不够好,所以翻译的有点拗口,其中重要的单词我都留下了原文的单词以便理解。如果大家在文字上有什么不明白的,可以回帖,我会尽快解释。

会议管理系统需求说明
1. 每年一部分研究者(chercheur)都会聚集并组织召开科学研究会议(conference),通常这个会议为国际间会议。
2. 委员会由五名组织者(organisateurs)(负责组织会议的研究者)以及一定数量的评审者(rapporteur)(他们主要负责阅读论文,并提交每篇论文的评审报告)。
3. 在会议(conference)被创建的同时还需要决定会议的主题、会议的举办地(宾馆或者会议中心)以及一个包含会议日程(重要日期)的日程表。此外还应该包括参加会议的最大允许人数和最少人数。
4. 论文征稿的启事(通知)将会随后在世界范围内发出。
5. 无论哪一个研究者都有资格提交他论文,论文的主要内容是介绍研究者本人的工作情况以及科学成果。
6. 允许多个研究者完成一篇论文。如果超过了截止日期,将不再接受研究者的论文(这个截止日期随同日程表的确定而同时确定)
7. 一旦超过了截止日期,委员会将召开会议,并决定把所收到的论文分配给评审者(rapporteur)。
8. 在让各个领域的专家进行复审之前,论文的分配主要依据论文的课题以及研究者的专业领域。为了得到比较独立的评审结果,对同一篇论文要产生2篇以上的评审报告。(评审报告的数量取决于会议的规模,但对于同一次会议来说,所有的论文应该有相同数量的评审报告)
9. 将所有的报告寄给评审者。
10. 评审者应该在评审报告截止日期前提供一份论文的分数以及对该论文的评审报告。
11. 委员会再次召开会议,根据评审报告以及分数,挑选入围论文。
12. 所有作者(auteur)将会被通知其论文是否被接受。
13. 每一届会议都有一份会议记录,该文件将会收录所有的入围论文。
14. 每一个入围作者都会收到一份会议记录,其中包括他的最终版本的论文。
15. 每一次会议的最后接待截止日期也是在日程表中确定。
16. 组织者(organisateurs)的任务之一就是整理所有文稿、编号并将其寄给出版商(editeur)以便出版会议纪要。
17. 为了选择合适的出版商,我们希望系统能够记录所有出版商关于价格方面的信息。
18. 在挑选论文工作的同时,会议的具体规划工作也要同时展开,这一工作由组织者负责。
19. 会议的创建,开始和结束日期都已在一开始就已确定,因此剩下的就是将每一届会议(conference)分解成一个个小会(sessions)。
20. 每次小会都有其主题,日期,场地,开始时间和结束时间。
21. 多个小会可以同时召开,我们称它为“分组会议”(平行会议)(sessions paralleles)。
22. 也有一些会议是所有人一起参加也称为“全体会议”(sessions plenieres)。
23. 这一点区别对于组织者来说非常重要,因为人们可能参加所有的全体会议,但不可能同时参加所有的分组会议。因此我们可以在“全体会议”中传达一些重要信息(比如参加者的接待会议,大会的介绍会议以及闭幕会议等等)。
24. 另一方面,有一些小会(sessions)是需要付费的。每一个付费小会(sessions),组织者将会给出一个费率清单(每一个参与者只能参加其已注册并付费的小会)。
25. 所有的小会都是由一系列的介绍(presentations)组成的。
26. 组织者根据科学的标准,为每个小会安排各个介绍(presentations)。
27. 每一个介绍都有其开始时间和持续时间。
28. 所谓介绍分为两种:嘉宾介绍和优秀论文介绍。
29. 嘉宾介绍由大会邀请一位卓越的研究者来进行,大会支付相关费用。需要再次提醒的是,嘉宾并没有向大会投稿过任何论文,大会和委员会之所以邀请该嘉宾,是因其良好的声誉。
30. 优秀作品介绍则是介绍相关的作品,论文。
31. 一旦本系统建立,征集参与者(participation)的工作就自动开始,所有的研究者都可以参加。
32. 所有的参与者都需要在注册时交纳一定的注册费用。
33. 如果某一小会是需要付费的,那么参与者在注册交费时,还需要加上准备参加的小会的费用。
34. 所有的注册的文件资料需要在注册截止日期前寄到(注册截止日期同样也是在日程表中确定)。
35. 所有的参与者都需要注册,包括嘉宾(invites)、组织者(organisateurs),评审者(rapporteur)。当然,嘉宾、组织者、评审者都能够在收费上有所优惠。
36. 在所有的注册文件中,包括研究者的信息,他所选择的收费小会清单,缴纳的总费用以及他的身份(组织者、嘉宾或评审者等)。
37. 如前面所说,各个小会(sessions)由组织者进行分解。一到注册的截止日期,我们就可以知道有多少人注册,并有多少人注册了每个收费小会。这时,秘书(secretaire)将能够开始进行后勤组织工作了。
38. 最后一个特殊的问题就是会议室的分配,这涉及到每一个会议室对于参加的人来说是否足够大,并且对于“平行会议”和“全体会议”也将会有不同的处理方法,每一间会议室都有房间号和容纳人数的信息。

 03/10/19 23:22 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory   提问
 

0:31中参与者的信息是否需要跨会议保存?研究者的信息是否需要跨会议保存?


1:会议中是否可以包含多个主题,既:关于某个会议的征稿启事可以有多个版本么
2:征稿启事的数目等于sessions 的数目么?既:确定sessions 的大体原则是什么
3:sessions 的‘主题’是如何使用的?既:不同sessions 间的‘主题’有可能重复么,和参与者注册收费小会的用况图
4:25-28所描述的‘presentations’是否可以理解为‘一次演讲’


5:8所描述的‘领域专家’是否一定是评审者
6:8所描述的评审报告的数量是否等于会议中评审者的数量,既:9中如何确定论文到若干评审者对应关系的用况图
7:评审者确认有期限么,如果有,是发出征稿启事、确定入围论文的那个时间?
8:sessions 的嘉宾确认有期限么,如果有,是分解成sessions、会议开幕,sessions 开幕的那个时间?

 03/10/20 00:59 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 frankfufjf  回复: 提问
 

1.研究者和参与者的信息只需要保留在每次大会(conference)内就可以了,因为只是一个案例,不是实际项目。
2.大会(conference)的主题应该只有一个,但可以涉及不同的领域,这样也就有了所谓论文分配的问题。而每个小会(sessions)都应该有不同的主题。
3.征稿启事只有一个,但sessions却可以有很多。sessions的分解我个人认为是组织者根据收到的论文所涉及的不同领域、邀请的嘉宾数目和其工作领域等作决定的。我觉得对于小会的分解原则不需要系统来实现,只要提供功能让组织者通过系统分解小会即可。
4.presentations可以理解为‘一次演讲’:)
5.领域专家就是评审者,我原来想这么翻译,但原文如此,我没敢动,呵呵。
6.我个人觉得评审者的报告数量未必等于评审者的数量,这取决于每个评审者是否只能拿到一篇论文。我的理解,对于同一个评审者,应该能拿到超过一篇的论文,否则资源太浪费了。当然,这只是我的猜测,原文中似乎没提到过,或者是我的外语不够,没看出来:)如果老师以后提到,我会来说明的。
7.我不太清楚你指的评审者确认是什么意思,如果是指评审者身分确认的话,我想应该是比较早的,可能在创建会议时就产生了,因为我第二条中提到过,委员会包括评审者。不过这样的话,评审者的注册就产生了一个问题。如果每个人注册都需要交纳注册费以及参加小会的费用,那么评审者应该什么时候注册呢?因为评审者身份的确认应该至少是论文接受的截止日期前。但注册交费却要等到sessions分解完毕。或许对于组织者、评审者来说可以先注册,后交费。或者系统角色和注册的角色分开,所谓注册仅仅牵涉到交钱的问题,而不牵涉系统管理问题。这一点我还没想清楚,可能要问问老师。:)
8.sessions的嘉宾名单,我觉得应该早就确定好了,但身份的注册和确认我觉得应该是在sessions分解完到大会的开幕之间。(我觉得所有研究者的注册也是在这个时候)

你提的这些问题很好:)由于语言问题,我花了半天的时间才把这个案例看懂,看得晕头转向,所以没有仔细想,你的问题让我开阔了不少思路,多谢多谢:)

 03/10/20 05:22 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 sealw  您现在需要完成的工作是什么?
 
 03/10/20 12:00 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory   我还是不清楚“确定sessions 的原则”
 

确定sessions 的大体原则是什么?

1:某个会议可能有多个征稿启事么
2:征稿启事的数目等于sessions 的数目么
3:不同sessions 间的‘主题’有可能重复么


或者说:
论文是基于征稿启事的
presentations 是基于论文的
sessions 只是presentations 的任意排列

 03/10/20 22:49 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  回复: 我还是不清楚“确定sessions 的原则”
 

因为“presentation”肯定是要对应一个对象实例的

这是最简化的系统:
论文是基于征稿启事的,按征稿启事管理论文
presentation 是基于论文的,按论文管理presentations
sessions 只是presentation 的任意排列,可以把sessions 作为presentation 的一个叫Schema 的属性(sessions plenieres也是一个Schema 的取值)

否则,sessions 必须作为一个类型,系统就复杂了许多
论文是基于征稿启事的,按征稿启事管理论文
我们按照某种原则创建sessions,sessions直接被conference 管理
再在sessions 内创建关于某个论文的presentations 对象



个人觉得,从语义上说sessions 的主题是有歧义的,可能应该是指其中的presentations 都是属于某个主题,而presentation 的主题是源于论文
这样理解的话,应该是前种更合理且简单
你必须明确描述出“什么是sessions”

 03/10/21 01:12 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 frankfufjf  回复: 我还是不清楚“确定sessions 的原则”
 

可能是我没有说清楚。我举个例子:一个经济学研究委员会召开一个经济学会议(conference),主题是“宏观经济学研究”,征稿启事只有这一个,所有的论文都是围绕这一主题。但所有研究者提供的论文肯定涉及宏观经济学的各个领域(宏观经济政策、宏观经济模型建立、金融市场、投资等等),而组织者则根据这些差别,结合评审者所在的领域,分配给评审者(如何分类领域,根据什么原则,分类分到多细由组织者根据实际情况决定,系统不参与,只接受结果)。
所谓的小会(sessions)也是在这个基础上产生的,比如宏观经济政策研讨会就是一个sessions。不过sessions的确定和论文分配相互独立,没有任何关系,因为1.并不是所有论文最后都被录用。2.sessions中还要考虑嘉宾(invitee)的情况(比如他的研究领域)3.sessions还包括一些参加者的接待会议,大会的介绍会议以及闭幕会议等非研究性会议。不同sessions的主题应该不会重复。
另外,我觉得不能说presentations 是基于论文的,因为presentations 分为两种:嘉宾介绍和优秀论文介绍,其中嘉宾介绍和论文没有关系(嘉宾不提供论文)。也不能说sessions 是presentations 的任意排列,因为每个sessions都有其主题,presentations必须与相应sessions的主题相符合。
我觉得你的第二种理解可能更确切一些。sessions 必须作为一个类型,我们按照某种原则创建sessions,sessions直接被conference 管理 ,再在sessions 内创建presentations 对象。

 03/10/21 05:58 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 frankfufjf  回复: 您现在需要完成的工作是什么?
 

目前我正在学习软件工程这门课,所以想找一些实例,因为觉得书上的例子过于简单,可能不能说明什么问题。但是完整的实力有比较难找,恰好老师在习题课上提供了这样一个案例,我觉得复杂程度适中,而且又可以得到老师的参考方案的帮助,所以想贴上来,让大家讨论讨论,一方面想帮助自己理解,另一方面也想抛砖引玉,听听一些不同的方案,毕竟老师参加的项目不多,提供的参考方案未必是最佳方案。

 03/10/21 06:03 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 frankfufjf  关于acteur的确定
 

因为老师讲解得比较慢,所以只能一步步来了
我们老师提供的参考方案是
组织者(organisateur)
评审者(rapporteur)
作者(auteur,相当于研究者,但是是指那些写了论文的,因为文中提到,组织者就是研究者的一部分)
出版者(editeur,这个角色不是很重要)
参与者(participant)
秘书(secretaire)

其中最让我感到迷惑的是参与者这个角色,他实际上包括了组织者,评审者和作者还有嘉宾。不知道大家对此有什么看法

 03/10/21 06:11 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  参与者不是角色
 

参与者应该是指业务人员,与之相对的是服务人员(比如秘书或出版者)

 03/10/21 10:22 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory   终于摸清楚啦,鬼子只有两条枪!
 

0:研究者的信息是否需要跨会议保存?
答:不是。每次会议相关人员都必须报一次名

1:会议中是否可以包含多个主题,既:关于某个会议的征稿启事可以有多个版本么
答:是。会议中是可能多个课题的,但征稿启事只有一个版本,征稿启事只是用来确认论文的课题范围

2:确定sessions 的大体原则是什么
3:sessions 的‘主题’是如何使用的?既:不同sessions 间的‘主题’有可能重复么
答:论文会按照其课题被归类为不同专业领域,基本上一个专业领域将对应与一个sessions,它代表参与者大体上都是同一批人,不同sessions的‘主题’不可能重复
同一个sessions中的所有meeting 不允许同时举行

4:25-28所描述的‘presentations’是否可以理解为‘一次演讲’
答:是

5:8所描述的‘领域专家’是否一定是评审者
答:是

6:8所描述的评审报告的数量是否等于会议中评审者的数量
答:不是

7:评审者确认有期限么,如果有,是发出征稿启事、确定投稿论文的那个时间?
答:是在确定所有投稿论文的时候开始邀请评审员,得到确认后,开始评审工作

8:sessions 的嘉宾确认有期限么,如果有,是分解成sessions、会议开幕,sessions 开幕的那个时间?
答:是在确定入围论文的时候,根据评审员对论文的评价,开始邀请嘉宾




你看看有没有异议,根据以上答案理解的稿件过程是否正确:
1.发布征稿启事,在最后期限以后收集所有投稿论文
2.将投稿论文按照专业领域归类,为专业领域确定邀请评审员,开始评审工作
3.对于入围论文的数量过少和质量太差的专业领域,放弃讨论
4.为保留下来的专业领域(既session),确定邀请嘉宾
5.为高质量的论文联系出版事宜

> sessions 可以理解为专业领域么?

> 评审员确认还是应该在收到所有投稿论文以后,否则
> 先邀请了某名人为评审员,然后可能由于相关的专业领域无人投稿而辞退之
> 这种做法肯定是不合适的

> 我建议你把conference 理解为只有目的、口号、征稿范围...
> 而避免使用‘主题’这个词,毕竟术语混乱是一个隐患

 03/10/21 11:30 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  不同的sessions 的主题还是应该可以一样
 

不同的sessions 的主题还是应该可以一样
因为sessions 最终将作为一个收费单位,“专业相关的presentations 必须放在一个sessions 里”是不恰当的



conference 对象应该具有这样的能力:
1.根据论文的专业领域,为每个专业领域建立至少一个sessions
2.建立至少一个“辅助sessions”

“专业sessions”
可能包含以下presentations:论文演讲、嘉宾演讲

“辅助sessions”
至少包含以下presentations:开幕、闭幕、颁奖
可能包含以下presentations:会餐、茶话

 03/10/21 12:11 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 smilemac  回复: 不同的sessions 的主题还是应该可以一样
 

呵呵,老兄把这样的session定义解释给会议组织者,估计解释上两个小时他也
不会明白. session就是用会议组织者定的主题方向来分的. 有时划分的也可
能不够科学,但影响一般不太大,而作为一种规则却是很明确的.

 03/10/21 13:19 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 smilemac  回复: 关于acteur的确定
 

你把其他人去掉后,剩下的听众就是participant了.

 03/10/21 13:25 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory   多谢,我试试看,敬请继续指点
 

> 至于“不够科学却很实用的规则”
> 个人是万万不敢把它放在自己的方案当中
> 且看潘某人慢慢演示


//第一页 大会的阶段
大会的整个过程可以按时间划分为三个阶段

开始
------------------------> 制定征稿启示
第一阶段是征稿、评审
------------------------> 确定所有的入围论文
第二阶段是会议
------------------------> 大会闭幕式完毕
第三阶段是优秀论文的推广
------------------------> 出版费用结算完毕
结束



//第二页 会议阶段的管理
在大会的会议阶段,所有的工作被划分为一些“活动”
活动具有开始时间和持续时间,是大会组织工作的管理和控制对象
每个活动有其负责人,活动负责人向大会保证活动顺利实施
大会参与者至少要参加一项“活动”,有些活动是要向参与者额外收费的,另一些活动对大会所有参与者都是免费

“活动”可以分为三类:学术会议、辅助会议、其它活动
学术会议,比如经济学研究大会委员会把关于‘金融市场’五个讲座安排为一个学术会议内;把关于‘宏观经济模型’三个讲座安排在另一个学术会议内
辅助会议,比如大会的开幕式
其它活动,比如经济学研究大会委员会安排所有参与者参观某证券公司




//第三页 “活动activity”与“节目presentation”的关系
某个活动总是有若干节目组成的,比如
开幕式包括以下节目:主席致词、剪彩、歌舞{{瞎写的,根据实际情况改改,呵呵}}
金融市场主题会议包括以下节目:负责人致词、嘉宾演讲、论文1演讲、论文2演讲、论文3演讲

“学术会议”类的活动中的节目主要是基于入围论文
所以大会需要对其中的“节目”进行一些控制,大会必须保证会议中的节目都属于同一个专业领域
比如,安排了十一个节目的大会委员会可能这样安排活动:
五个关于‘金融市场’的讲座被放在“金融市场I”活动中
另外四个关于‘金融市场’的讲座被放在“金融市场II”活动中
另外两个关于‘宏观经济模型’的讲座被放在“宏观经济模型”活动中

 03/10/22 00:23 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 smilemac  回复: 多谢,我试试看,敬请继续指点
 

我的意思是session是用户的术语,你重新给定义恐怕不太合适,你觉得不过瘾可以再加一个名词:activity.
另外你的设计也不能代替用户进行分类,那是用户的工作。是requirement-driven,而不是deisgn-driven.
 

 03/10/22 00:39 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  同意,但是我觉得那是理想状态
 

这个观点是有合理性,我是无法反驳这个观点!


但是我觉得那是理想状态
你会为了惬意而为使用电钻,淘汰螺丝刀么

不规范的术语是否会增加交流的成本呢,我避免使用原来的术语就是为了减少客户的反感

 03/10/22 00:46 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 smilemac  we are not user, we are maker.
 

我们不是使用电钻或螺丝刀的,我们是制造者,造什么是由用户说了算的,何况不同的会议有不同的需要,你给分类不见得会比用户分的好,什么是理想状态我不知道。

 03/10/22 00:51 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  也许我的改动没有想象中那么可怕(还没到偷粱换柱的地步)
 

requirement-driven 是比deisgn-driven 优秀、得体
“用客户的术语与客户交流”是最突出的表现

仔细考虑了一下以后发现:实际上activity 就是session
应该说是我起了一个别名,然后扩展了第三类活动
就“用别名”这一点上我做得是不好,应该改
至于“扩展第三类活动”值得再商榷

 03/10/22 01:03 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  是啊,用户觉得电钻用起来爽,那就改电钻吧(反正有人会掏钱的,呵呵)
 
 03/10/22 01:06 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 smilemac  回复: 也许我的改动没有想象中那么可怕(还没到偷粱换柱的地步)
 

呵呵,其实如果单独考察这两个英语单词的含义,activity和session还是有区别的,一般不会把开幕式这类活动称之为session的。

 03/10/22 01:13 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  回马枪?顶楼的条件中的22,23条中用到了sessions 这个词描述闭幕会
 
 03/10/22 01:16 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  第二版
 

//第一页 大会的阶段
大会的整个过程可以按时间划分为三个阶段

开始
------------------------> 制定征稿启示
第一阶段是征稿、评审
------------------------> 确定所有的入围论文
第二阶段是会议
------------------------> 大会闭幕式完毕
第三阶段是优秀论文的推广
------------------------> 出版费用结算完毕
结束



//第二页 会议阶段的管理
在大会的会议阶段,所有的工作被划分为一些“会话”
会话具有开始时间和持续时间,是大会组织工作的管理和控制对象
每个会话有其负责人,会话负责人向大会保证会话顺利实施
大会参与者至少要参加一项“会话”,有些会话是要向参与者额外收费的,另一些会话对大会所有参与者都是免费


“会话”基本对应与一个会议
它与meeting的区别在于“会话”将包含“多个meetings” 和“meetings 间的休息”
“会话”可以分为两类:学术会议、辅助会议
学术会议,比如经济学研究大会委员会把关于‘金融市场’五个讲座安排为一个学术会议内;把关于‘宏观经济模型’三个讲座安排在另一个学术会议内
辅助会议,比如大会的开幕式




//第三页 “会话session”与“节目presentation”的关系
某个会话总是有若干节目组成的,比如
开幕式包括以下节目:主席致词、剪彩、歌舞{{{瞎写的,根据实际情况改改,呵呵}}}
金融市场主题会议包括以下节目:负责人致词、嘉宾演讲、论文1演讲、论文2演讲、论文3演讲

“学术会议”类的会话中的节目主要是基于入围论文
所以大会需要对其中的“节目”进行一些控制,大会必须保证会议中的节目都属于同一个专业领域。比如,安排了十一个节目的大会委员会可能这样安排会话
五个关于‘金融市场’的讲座被放在“金融市场I”会话中
另外四个关于‘金融市场’的讲座被放在“金融市场II”会话中
另外两个关于‘宏观经济模型’的讲座被放在“宏观经济模型”会话中

 03/10/22 01:23 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  没法子,见了不好的客户就得说鬼话
 

是啊,这个术语太别扭,要不咋会有“活动”之说呢

 03/10/22 01:25 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 smilemac  呵呵,所有这样连续几天的会议中的会都叫seesion呀,应该和客户没关系吧。
 

你非让他换个说法,那来参加会议的可能又不明白了。:-)

 03/10/22 01:29 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 smilemac  回复: 回马枪?顶楼的条件中的22,23条中用到了sessions 这个词描述闭幕会
 

是,如果有主席较长时间的讲话,或者其他持续一段时间并内容不可忽视的会议也叫session,但很多会议开幕式是很简单的。我没有仔细看楼主的贴子,只是看到你提的session问题,就看了一下。

 03/10/22 01:30 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  有这回事?“连续几天的会议中的会都叫seesion”,那感情好
 

早知道我就不想了,全用seesion!

 03/10/22 01:33 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 ashelly  回复: 参与者应该是角色
 

见31,32,参与者应该是听众,即参见会议但不一定发表论文的,他们也会使用本系统

 03/10/22 11:18 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  第35条对参与者的概念进行了补充
 
 03/10/22 11:23 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 babituo  非常好的例子,我会跟进
 

你们老师首先给出了业务过程的描述。
他首先带领你们在这个业务描述中去发现未来会议管理系统的直接用户。
也就是开始系统建模,查找主角。

可能在你们的教学目的中没有包括业务建模过程,所以,你们的老师省略了业务建模过程的介绍。在实际的项目中,业务建模的过程也是可以省略的,但这必须在系统开发的目标和边界都已经比较明确的前提下,才可以省略。最简单的情况就是,待开发系统要帮助在业务上解决哪些问题,应该明确。否则,系统分析中关于特性的取舍问题将很容易引起争论。

你们老师给出的业务过程描述没有直接提供问题信息。

非常好的开端,请继续下去。

 03/10/22 11:47 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 ashelly  回复: 第35条对参与者的概念进行了补充
 

35条仅对参与者的特例做了说明
角色的定义是“谁使用系统”,
除了你们定义的角色,应该还有其他用户使用该系统,这种用户也可为参与者,我理解参与者可以定义为一个基类,其他的嘉宾,组织者等都是它的子类。

 03/10/22 11:49 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 orangutang   Model上载到小组相册conference project里面了
 

肯定有错误、不全、不合适的地方,欢迎指出更改。
XMI输出文件更大,就先用这个方法交流一下了。
谁改了,再上载一个更新了的图片吧。

 03/10/23 03:50 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 frankfufjf   回复: 也许我的改动没有想象中那么可怕(还没到偷粱换柱的地步)
 

呵呵,忘了补充一点了,原文是法语,不是英语,个别单词英语和法语长得一样,但意思还是有差别的。不过还好,session在英语和法语里都是会议的意思。meeting是一个英语词汇,在法语里是运动会的意思(也有表达会议的意思,但是不常用),所以这里不用meeting,但我觉得这里的sessions可以理解为英语里的meetin。

 03/10/23 08:30 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 frankfufjf  没想到两天没看居然这么多回帖
 

感到非常高兴,也希望大家能够深入讨论,我也能够向大家多多学习。
babituo网友,很高兴您能对这个案例感兴趣。关于业务建模过程,我也吃不准老师是不是介绍了。软件工程是我比较没把握的一门课,主要原因是这门课对语言要求相对比较高,上课的时候一不留神就听不懂了(其实留神了也听不懂多少,呵呵)所以不敢肯定老师是不是介绍过。我以前看书看到过,但没有感性的认识。如果您方便的话,是不是可以给我介绍一下关于系统开发的目标和边界以及业务建模过程,或者提供一些链接资料:)多谢了。
这个星期有一门考试,这两天就不来了。下个星期万圣节放假,我会多多过来参加讨论的,谢谢各位了。:)

 03/10/23 08:38 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 frankfufjf  对于你的理解,我大部分表示一致意见
 

只是关于sessions的主题以及某些细节方面略有不同意见,可能需要进一步讨论。我这个星期有考试,周末再来细说:)

 03/10/23 08:40 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  这就是需求工程了
 

客户提出的需求说明书一般都会存在两个问题:
1.用词不规范(我是指术语的概念在逻辑上不切确的问题)
2.重复要求,有些要求在操作上是有不同的意义的,但数据的处理过程是一样的,那么实现是可以合并的


既然需要整理需求
那么最好还是等对需求框架进行了确认后,然后动手做
我认为对Session 的理解直接影响会议阶段的核心的功能架构
(关于会议阶段参看“第二版 - <1556b> panrglory 2003/10/22 01:23”)

 03/10/23 10:28 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  没有整理完需求框架之前就设计,是不是有点操之过急?
 
 03/10/23 10:32 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 orangutang   回复: 没想到两天没看居然这么多回帖
 

你在国外,是么?
如果老师给的题目原文是英文的,不妨原封不动地给贴上来。谢谢

 03/10/24 01:01 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 orangutang   我认为两者不矛盾,而且互有补充。并且我做的是一个PIM,还是简化的。
 
 03/10/24 01:06 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  同意
 
 03/10/24 10:17 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 babituo  很抱歉,关于业务建模我也提供不了网上资源的链接
 

我是从RUP中学到的业务建模的概念,RUP中提供了大量讲解和链接,只是翻译得不太好或者思想本来就很难翻译。我的思想是在学过RUP后经过大概两年时间的实践领悟到的,有些不一定和RUP相同,但大体一致。
继续您的例子,我会跟着把我的思想一步步分享出来。

 03/10/24 10:42 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  那我就先开始挑刺噜,嘿嘿
 

1.该软件的使用中将包含三个主题:人员模型、论文流程和会务管理
你描述了“人员模型”和“会务管理”,丝毫没有涉及“论文流程”的功能


2.你主题的概念不明确,“人员模型”和“会务管理”应该用两张图表达
人员模型和论文流程是两个独立模块(只是论文有个描述性的属性叫auteur),会务管理模块中:根据入围论文确定Session;根据Session 的报名(人员模型中的数据),确定Session 时间安排


3.“人员模型”中的称谓(除工作人员)是:
在论文的整理阶段是chercheur
在会议的阶段是participation
在论文的推广阶段都是工作人员
注意:楼顶的定义书中的评审者(chercheur)显然是可能成为嘉宾(participation)的




---------
4.出版商好象应该通过论文(而不是‘会议记录’)发生关系
看不出‘会议记录’是什么东西
OOP 中‘记录’是用来实现对象的持续化的,在OOA 的任何时候都别出现这个词

5.现在会务管理模块的需求/概念还很含糊,但是可以肯定的是:
sessions plenieres 是sessions 的实例,而sessions paralleles 则是sessions 间的约束关系
两者是不一样的

 03/10/24 11:13 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 babituo  学习UML建模关键是学习如何建立与业务目标一致,与思想一致的模型
 

你们老师给的案例有一个明显的缺憾。
虽然是一个假设的案例,如果没有假设的业务目标,就不能把建模的过程展示为一个围绕业务目标思考的过程。能演示的,也就只有如何操纵UML的各种语言要素,把一个现实的业务过程表达出来而已。也许这是你们老师考虑到教学规划问题,暂时有所保留。我提醒你这个学习者应该注意的保留,也许是今后进一步学习的方向。因为实际的工作,决不是平铺直叙地把一个过程描述出来,而是要发现和解决业务中的问题。学校的教育,正好缺乏这个,于是造成教师的弟子最适合做教师的缺憾。

另外一点是与思想一致,这一点相信你们能做到。就是你用UML表达的要和你心中所想的模型一致。由于UML并非严格形式化语言,存在较多的语义边界的模糊,这有好处也有坏处。精确地表达模型的思想需要对UML语言元素的语义有足够深刻的理解以及保证上下文的一致性。精确地理解模型思想也需要同样的水平。由于表达和理解人的水平不一致,导致对模型的评价不一致是十分普遍的现象,我们不需要过多纠缠语用上的差异并因此互相批评。关键的是:你心中的模型是否清晰。如果清晰,即使UML的表达不够精确,你还能借助其他方式校正对你的模型的不同的理解。

对于模型的理解者,最容易犯的毛病就是在理解到建模者真实思想之前,提出自己的建模观点对原建模者加以否定。对同一个词有不同的理解,只能根据模型的上下文加以辨识、甚至口头交流、其他形式的进一步落实。这才是达成一致的良策。过早拿出自己的观点,是明显的急于求成,很容易对建模过程造成杀伤。高手之间的对话不同,他们各自后面已经隐藏了对手的多种假设,所以才可以形成切磋的高效局面,不过也容易错杀机会。

模型可以比较优劣,但不能相互作为对错的参照。模型优劣的评判标准就是我标题所列的两个。

 03/10/24 11:15 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 decapli   不知道可不可以把原始的(英文)习题贴上来?
 

楼主没贴过,是吧?

 03/10/24 12:13 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 zhjun_007   回复: 关于acteur的确定
 

参与者应该是使用本系统的,没有在角色列出的人员,应该是角色

 03/10/24 17:53 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 orangutang   回复: 那我就先开始挑刺噜,嘿嘿
 

为了让读者更好的阅读,我引用了原文
1.该软件的使用中将包含三个主题:人员模型、论文流程和会务管理
你描述了“人员模型”和“会务管理”,丝毫没有涉及“论文流程”的功能
答:我想我做的这个模型,都是一个domain的事情。我想你说得这三个方面的角度可能和我不同,但是我的模型中都包含了这些内容的。论文流程是体现在类的field and method里面的,而这两部分我都还没有说明,是需要添加的。

2.你主题的概念不明确,“人员模型”和“会务管理”应该用两张图表达
人员模型和论文流程是两个独立模块(只是论文有个描述性的属性叫auteur),会务管理模块中:根据入围论文确定Session;根据Session 的报名(人员模型中的数据),确定Session 时间安排
答:我认为几个Diagram不是本质问题,关键看是不是一个模型,完全可以把多个Diagram放在一起,至于每个Diagram要体现的多细,也是不确定的。模块的概念是技术性的。我想我建的模型是business model,不应该参杂任何技术问题。

3.“人员模型”中的称谓(除工作人员)是:
在论文的整理阶段是chercheur
在会议的阶段是participation
在论文的推广阶段都是工作人员
注意:楼顶的定义书中的评审者(chercheur)显然是可能成为嘉宾(participation)的
答:我对这个问题的看法是这样的,无论怎样,跟这个会议有关的人一定是一个该领域的研究人员。只是不同阶段,扮演的角色不同。那么他们的继承关系,我想应该是没有问题的。但是你提的“注意”里面的内容是有道理的,不妨可以应用Decorator模式,就很好的解决了这个问题。

---------
4.出版商好象应该通过论文(而不是‘会议记录’)发生关系
看不出‘会议记录’是什么东西
OOP 中‘记录’是用来实现对象的持续化的,在OOA 的任何时候都别出现这个词
答:这个也是让我很烦难的一个问题。注意一下,这个会议记录是唯一一个用中文描述的(幸好人家工具支持中文)。这个会议记录是从原始的文章中得到的,意思大概就是论文集。出版商出版的是论文集也就是这个会议记录了,呵呵

5.现在会务管理模块的需求/概念还很含糊,但是可以肯定的是:
sessions plenieres 是sessions 的实例,而sessions paralleles 则是sessions 间的约束关系两者是不一样的
答:这个跟对需求的认识有关。我的看法是sessions plenieres是独占的session,而sessions paralleles是可以同时存在的session。Session类可以是abstract的。这两种session应该是互斥的。session只是一个逻辑上的概念。好像我们对session理解的就完全不一样呀,不妨去网上找一个conference,看一下他的schedule chart。
另:不能在business modeling期间引入模块的概念,这是大忌。

 03/10/25 06:08 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 smilemac  呵呵,如此开发方式真是有意思。
 
 03/10/26 22:50 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 smilemac  session和meeting感觉不太一样。
 
 03/10/26 22:52 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 smilemac  就是,去找一个会议的agenda看一下不就得了,一个简单的问题被分析的如此复杂。
 
 03/10/26 23:11 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  以武会友
 

[只要你愿意与我同道为伍,我可以“舍身取义,共赴真相”,呵呵]

我想我做的这个模型,都是一个domain的事情。我想你说得这三个方面的角度可能和我不同,但是我的模型中都包含了这些内容的。论文流程是体现在类的field and method里面的,而这两部分我都还没有说明,是需要添加的。
答:^_^



我认为几个Diagram不是本质问题,关键看是不是一个模型,完全可以把多个Diagram放在一起,至于每个Diagram要体现的多细,也是不确定的。模块的概念是技术性的。我想我建的模型是business model,不应该参杂任何技术问题。
答:前半句是对的
我所指的“模块”也许是分而治之的原则,我还没有开始讨论(也不打算讨论)软件的工作任务清单



我对这个问题的看法是这样的,无论怎样,跟这个会议有关的人一定是一个该领域的研究人员。只是不同阶段,扮演的角色不同。那么他们的继承关系,我想应该是没有问题的。但是你提的“注意”里面的内容是有道理的,不妨可以应用Decorator模式,就很好的解决了这个问题。
答:我坚持认为Decorator 不是典型的OOD 的设计模式。你有怎么反驳吧



这个也是让我很烦难的一个问题。注意一下,这个会议记录是唯一一个用中文描述的(幸好人家工具支持中文)。这个会议记录是从原始的文章中得到的,意思大概就是论文集。出版商出版的是论文集也就是这个会议记录了,呵呵
答:这个东东是‘入围论文’的‘评价等级’属性么
如果是,应该还是从‘入围论文’连结到‘出版商’妥当一些



这个跟对需求的认识有关。我的看法是sessions plenieres是独占的session,而sessions paralleles是可以同时存在的session。Session类可以是abstract的。这两种session应该是互斥的。session只是一个逻辑上的概念。好像我们对session理解的就完全不一样呀,不妨去网上找一个conference,看一下他的schedule chart。
答:不好意思,我找不到。如果你确切地知道,可以给我一个链接么?谢谢



另:
我所指的“模块”也许是分而治之的原则
你对“企业信息化”和“企业数据电子化”是怎么理解的么

 03/10/27 00:18 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  session 是一个meetting sequence
 

法语?算了,别贴了
不好意思,没看见才叫你贴原题的,千万别拿我的‘叫你帖原题’那句话当真,反正我是不会去看DI,呵呵

 03/10/27 00:31 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 orangutang    :)
 

重新整合一下问题
1。我想首先要统一一个观点。我们要选择同一个视点来分析这个case。如果两个人说得根本就不是一会事儿,那肯定是说不到一块去的了。我想我对domain model的认识可能和你有些不同,所以才会有很大的差别。
2。关于“模块”问题。我这里是针对domain作的。根据我的经验,最开始就在思路上强加一个划分是会在后来造成很多麻烦的,而且后面的思路似乎总是在肯定前面的划分的情况下给出的,感觉上这种先入为主的划分是不好的思路。这种划分在model中一般是按照package划分的,但package也只是一个管理的工具,不提供任何实质的信息。而且package也是可以在model最后再划分。
3。关于Decorator。我只读过分析模式这本书的一小部分。如果Decorator是一种分析模式那估计就不会产生歧义了。其实,分析模式是在设计模式之后出现的,书里面没有固定下来什么理论的东西,也就是给出了一些现实中的事情,说明了一下在商业模型上作者是怎么做的而已。而设计模式也并没有说明一定要针对高级程序语言级的应用,设计模式只是说了语境和解决方案,从这个层次看这种思路是完全可以应用在分析阶段的。并且这样设计的结果也是可以解释的。
4。关于论文集。我不太明白你说得入围论文是一片论文还是一个集合。这两者是有本质区别的。而我说得论文集并不强调是否入围,是一个集合。出版商出版的都是论文集,一般这样的论文少则两三页,多则不过10多页,最多也就30页左右,不可能单篇出版的。
5。关于session。http://www.oopsla.org/,会直接转到2003的。横条上的tracks就相当于session了。
6。企业信息化和企业数据电子化。我想信息就是information吧。企业的目的就是赚钱啦,信息化一定是要带给企业更多的钱才要信息化的。也就是information是要带来钱的。信息带来钱的方式有两种吧,一个是节省了原来时间空间上的消耗,信息获取成本降低。比如,农民把他们今年的收成都放到网上,贸易公司就知道哪里有多少西红柿土豆大米了,然后直接去拿;如果没有网络,可能他们要派人去一个村一个村的找。另一个就是新的信息带来的经营策略的改变,及时应对市场变化等问题带来的收益了。比如,有个经典的故事,说数据挖掘发现,每逢周五晚上,有baby的爸爸都会去超市买纸尿裤给孩子,并且很多人会顺便带两瓶啤酒回家。商家得到这个信息,然后就在纸尿裤旁边放上啤酒,啤酒的销量就增加了。当然企业信息化并不一定要求用到计算机系统,但是往往计算机系统会带来更多的信息,所以企业信息化和计算机系统是有联系的。重点在于信息会带来什么好处。企业数据电子化,我想只是将数据电子化了,往往只是当前的流程不变,票据什么的都变成用计算机操作了。这个和计算机系统就有必然的联系了,否则没法电子化。但这个似乎是一个低层次的。上面企业信息化中提到的两点也只能体现出来第一点。我没有读过相关的任何资料,只是自己理解的,乱说,不知道你问这个有什么用。

 03/10/28 03:34 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory   让我想想
 

出差中...

有点意思了,过两天再来聊 ^_^

 03/10/28 10:41 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 alexandro  这么多人。也来瞎参与一把。
 

1。如果从业务建模开始,那要抛开系统概念,以组织为边界考察业务功能。在这里组织是委员会,外部人员有研究者,出版商等。
2。以组织提供服务的视角切入,一般可得业务用例,如9,11,12等;管理支持用例如18,19;业务规则如34。前两者可做活动图,图中的每步一般对应系统用例。由此可对系统用例关系有整体把握。包括用例间的前置条件,后置条件。业务规则可对应到系统用例,如34可抽取关闭文件注册的用例,也可对应到别的用例的前置条件。这里没有标准答案。
3。同时可进行领域建模,一般用类图,用CRC方法。抽取领域对象如小会都有其主题,日期,场地,开始时间和结束时间。领域模型一般就是系统累图。数据库模型等的原型。
4。单个项目没有必要对领域模型进行过多抽象,你的业务里面用到什么业务对象直接反映到领域模型。
5。接下来是系统分析。软件技术架构设定就看你的功力了。
 

 03/10/31 17:12 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 babituo  这个案例的业务模型应该包含以下内容
 

1.业务前景
2.业务词汇表
3.业务用例概述

暂时还没有看到建立领域模型的必要。

领域模型是业务对象模型的一种(一个子集),但不等于业务对象模型就是领域模型。
领域模型和其他业务对象模型相比,至少具有以下特点:
1.抽象级别更高;
2.与具体业务环境相关性更少;
3.更加关注构架和通用功能。
领域模型对应的实现可能是通用产品和业务基础平台。

 03/11/05 09:14 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 bbmud  回复: 关于acteur的确定
 

首先,个人觉得“参与者”这个名字的形式不好,有点过于泛化了,没能表达一种对目村系统有意义的意义或需要来,对于理解需求起不到什么作用,因此,我觉得不应该把它作为一个有用的主角来考虑,因为我们使用主角这种模型元素的目的是为了帮助获取或弄清楚需求,这种没有用的词汇,可能反而会对我们的思维起误导的作用,不知不觉提早陷入设计的泥坑。
其次,我觉得,当使用了参与者这种过于泛化名字的时候,一般情形而言,是由于尚未明确明白自已想说什么,这种时候,最好停一停想想究竟想表达的是什么。
一点愚见,请大家指正指正

 03/11/05 23:30 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  回复: :)
 

我想首先要统一一个观点
答:同意。我也是期望达成共识的说



我想我做的这个模型,都是一个domain的事情。我想你说得这三个方面的角度可能和我不同,但是我的模型中都包含了这些内容的。论文流程是体现在类的field and method里面的,而这两部分我都还没有说明,是需要添加的。
答:是不是有点“看到了不足却仍不低头”的倔强味道 ^_^

我所指的三个主题(人员模型/论文流程/会务管理),是对术语的一个划分,这种分法不是必须的
我提出这种分法是因为我考察了‘国际会议’的定义,认为它是指国际学术研讨会,考虑的过程如下:
任何会议都有‘会务管理’的需求,比如产品推广会议
一般会议都有‘人员模型/会务管理’的需求,比如亚太经合会议
只有学术研讨会才会有包括‘论文流程’的三类需求
缺少论文流程可能意味着没有考虑过‘客户所指的国际会议是什么’(或者说,它和其它国际会议的区别)

不是因为有了这种划分才有你偏颇(如果可以这么称呼)的,而是在这种划分下你偏颇表现得尤其明显,我觉得!
我认为你必须在分析阶段明确刻画出‘论文流程’



我认为几个Diagram不是本质问题,关键看是不是一个模型,完全可以把多个Diagram放在一起,至于每个Diagram要体现的多细,也是不确定的。模块的概念是技术性的。我想我建的模型是business model,不应该参杂任何技术问题。
答:这不是你的错误,我提法欠妥
正如“完全可以把多个Diagram放在一起”,这种分法的确不是必须的



-----
入围论文是一片论文还是一个集合。这两者是有本质区别的。
答:是的
我原以为是整个会议出一个‘会议优秀论文集’的书,而分册装订是出版商的事。现在看来,是应该新建一个‘书’的类型
至于‘书’是关于‘入围论文’还是‘投稿论文’的,我觉得前者合理一些,但是这应该不会成为大问题


-----
企业信息化和企业数据电子化
答:我的意思是:如果不敢向客户要求一些变化的的话,最多只是数据电子化
我们应该把信息化作为自己的最终目标,电子化只是第一步

要求客户改变总是项目中验收中的不利因素
所以需要避免,能不提的要求就别提,比如术语措辞之类
如果客户的术语的概念是不准确的/有歧义的,我必须提出来,并要求他们改正

 03/11/06 15:23 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 orangutang  我想我们的知识体系不同才导致的这些分歧(参照babituo的模型参照系的讨论)。暂时搁置,等搂主来主持吧
 
 03/11/07 02:00 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
返回页首
 panrglory  是的。我也在学习模型参照系,babituo同志很聪明的说
 
 03/11/07 09:01 酷帖!    臭帖!    回复  
酷帖评价:           臭帖评价:
阅读全文
0 0

相关文章推荐

img
取 消
img