BBS项目招募志愿人员加入

yining

多谢base兄一直在这里捧场。我前一阵太忙，所以一直没什么机会上来，冷落了很多兄弟，抱歉。看来这个事情还是应该一步一步按部就班的来。我们从明天开始，从头做起吧。

yining

我个人喜欢把作项目比成解题，用户出了一个题目，技术人员需要提供一个解答。当然，有时候这个解答是：本题无解，这也是一种解答。但是，如果要有一个比较准确的解答，就必须先有一个准确的题目。很多软件项目的问题是：用户不能够明确地阐述题目，技术人员在没有了解题目之前就盲目的试图进行解答，最后自然只有失败。

很多公司因此而设立了专门的人员，比如business analyst或者product manager来作为用户和技术人员之间沟通的桥梁。这些人通常都具有业务北京，但是缺乏软件方面的专业知识。而给技术人员的，除了一张嘴之外，我们了解用户题目的工具，就是use case。

实际上，我通常都喜欢把use case写出来，而不是画一张图。原因很简单，用例图的使用者是技术人员，但是制作者却是业务人员，这些人往往不会使用技术人员使用的工具。另外一方面，写的过程，也是一个自己从新思考的过程，可以把思路整理一下，同时发现漏洞。

因此，明天，我会从新把需求写一遍。

base

－－其实在需求调研基本写成后的第一步，并不是直接来做Use case，而是要先地需求进行分析，这个分析是进行问题域的分析，即划定问题边界，这样在后面进行用例分析时才不会满天FLY　FLY的

－－然后画Use case，YN同志说写出来，老朽以为只是写出来，这个断然不妥，因为这与使用UML的本意有悖，Use case在分析的时候是要写出来，但是这个过程使用Use case diagram更为简易且直观，不管用什么工具皆如此耳，这也是用框图的原因，一眼就可以知道大体是怎么回事，这万不是只是写写就能达到的效果。

－－顺带说一下为什么要用UML和Rose之类的工具，可以这样讲，如果没有Rational公司的话，UML的发展定会受到严重影响，甚至流产，这是不重要的一点。下面来说一下我对UML的理解，当然，这只是老朽的理解，倘有误，还请指正

－－UML(United Markup Language)统一标记语言，之所以这样命名也是它本身产生立场的表明，就是要统一标记，为什么要统一标记呐，为了方便交流，也就是制订一个大家都用的标准，像普通话一样。而在此之前，甚至现在，还是有许多种类似的标记，在不同场合起着不同的作用，这也是“隔行如隔山”的原因罢，因为如果你不学就看不懂

－－好了，那么UML在系统分析设计构架中起的作用是什么呐？UML有若干种框图，这个不管它，因为如果让我们来设计UML的话，也是这些东西，只是一个总结。它起的作用如下：

－－１归档　在一个系统进行的过程中，如果还想对其再扩展或进行维护而不是一写完就扔掉不用的话，就需要有文档，为了让别人看懂的文档，大家都知道，如果你主持一个项目(project)，进行到2/3的时候你溜了，如果没有足够的文档资料，那么这个项目会挂掉，大多数时候都会重来，像我们某航空航天研究所，每年这样流产的项目浪费数千万。UML在这里就会起到这个作用，将分析设计规划以及开发的近乎所有内容都形成一个完整的流程文档，也就是将你头脑中的东西尽量文档化，别让后面人找不着北

－－２直观　这个就不用说了，但我说的直观的意义在于，可以使用不同的框图对不同的人来进行系统讲解，如用例可以和需求者，就是那个“道”来进行沟通，修订，“道”也是很容易懂的，而与用例在一起的如序列图也在此列等等如是

－－３印象　便于对整个系统形成完整的印象，从而不会产生只知一点而不知全局的结果，这样便于从整体上来进行把握，前提是你的设计要达到一定水平

－－如老朽所悟，其实不外乎如此，这其实已经不只是UML本身的问题了，众人皆知，“千言万语尚不及廖廖数笔一画”，其出发点亦为此也

－－而用UML来设计类，根据实体为数据库建模，亦是文档，但更多的则是一种方便了，可以从中看得到其关联，如“一”所示耳

－－好了，众人若有意见，老朽顿首以待之，且看YN的需求调研之结果吧

base

－－另外，我想对于YN的“用例图的使用者是技术人员，但是制作者却是业务人员”这种说法提个意见，首先一点，用例图不是业务人员做出来的，而且主要也不是给技术人员使用的，为什么这样讲呐？

－－因为用例是PM或系统分析者根据业务人员或是需求提供者提供的需求和建议，进行建模，用一种直观的方式将需求进行整理，主要是给需求者和项目设计规划者看的，而前者则是核心，因为项目是围绕他们来的。

－－当然这个技术人员的范畴如果足够大的话可以将PM之流也包进去，但老朽以为到PM系列时，其实已经不只是技术人员了，他需要对什么都懂，是“行”与“行”的一个桥梁才对。

－－如此，用例是一个项目的目的之所在，你做成的这个系统就是为了来实现用例的，使actor与use case能够真正交互起来。说白一点，use case是一种条理化后的，直观的需求表达方式，但与直接的需求不同，因为它已经按系统分析的需要进行过规整了

－－然也？

yining

在下的意思是：用例图是业务分析员做给技术人员看的。这里的技术人员，指的是进行设计的人员。个人以为和base兄的见解没有什么两样。

至于base兄所说的问题域的分析，实际上牵涉到用例图的分类。用例图实际上有两类，一类是业务用例，一类是系统用例。这样的分类，至少再Rose 2000中还没有明确的分开。但是在2002中已经有了不同的框图来表示。这样的分类，使得客户与技术人员之间的过渡更为平滑。业务人员，或者产品经理负责的是业务用例，而系统分析员通过整理业务用例来产生系统用例。

但是，我这样说也只是纸上谈兵。我所见过得最完整的系统分析是在IBM，而这种分析至少到目前为止还没有引进业务用例和系统用例的分别。所造成的结果，就是产品经理或者业务人员不得不去做系统用例，或者，技术人员不得不用业务用例来进行系统分析。至于我本人，说句老实话，我的专长在于做系统分析，和设计，而不在于作用例，原因说过了，这部分总是交给别人做的，我没有什么插手的机会。

至于用例是否该画出来，个人认为，画出来的唯一好处，就是你可以看到各个用例之间的继承关系。而这个，实际上是不太重要的。当然，有了这个关系，还是可以有一定的明确作用的。在这方面，Martin Fowler德UML Distilled对于用例图的表述方式可以作为佐证。

base

哦，其实具体应该采用哪种方式，是要因事制宜的，而非定要用某种模式，我在这里所讲的用例主要是指业务用例，即从业务的角度进行的分析，因为这才是需求的真正体现，到系统用例的时候，其实已经建模了。

我们现在心向往之是一个完整的流程，就是从项目经理的角色开始一直到代码实现都要做一遍，如此也就知道实际应该怎么运作，当然，吾等其实应该建立的是一个理想的流程，而非具体到某种实际的方式，所以应该是理论化的标准实现，这里，甚至需求者也是我们自己

所以我一直建议，所有的东西不要跳或是套入某种实际方式，可以讨论实际实现情况，但不是我们要进行的流程。如你的开发流程和立项及分析方式和老朽参预或是带的方式就有很大不同，虽然根本上是同质的。

呵呵，用例的作用是什么呐，一个用例可能会有多个序列实现，如此是这样进行的，从需求分析到用例（就是要做的什么动作）建模，然后用序列（就是你做这个动作的流水过程）和联合来建立对象间的关系，在这里可以知道对象的方法，就是它会对哪些事件产生什么响应，它自己会做什么，然后通过什么状态呀，动作呀的建立一种静态情况和动态情况出来

如此一个完整的对象就形成了，也就成就了一个类，这是进行类分析的根本所在。这里再说一下用例，实际上系统用例是业务用例的细化。这是一个要动很多脑的过程，中间还有许多许多文档，哈哈，像CMM认证样的，你有文档嘛？那你就是CMM2，你有文档的文档嘛，那你就是CMM3......类成了，就可以形成较完整的开发框架，就可以写程序了，然后进行若干次测试和迭代，如此

YN同志可能在想这个项目的时候，总不自觉的会带自己的实际开发情况进来，我们的想法实际上是一样的，只是我更想建立一种简单的开发模式，可以让众人从这里摸到一点系统开发的门道，YN最初的想法也是这样，哈哈，YN更多的是做系统分析，所以嘛这次也应该做做业务分析了吧，:-)　如何？

base

实际上一个WEB应用项目，需要有这样的组合，当然这是我一直使用的组合方式：
１业务人员　提供实际业务需求
２项目经理　与业务人员进行沟通，进行需求分析，建模，一直到类图为止，下面的就和系统分析组进行协调组合进行，并完整的掌控整个系统的进行开发情况
３系统分析组　对系统的实现进行分析，采用架构，语言，以及其他的东西，就是思考如何实现，这与PM进行充分交流协商进行的，然后建立模块，按其关系进行分组开发
４开发组　具体实现功能，并进行自身模块的完整测试，这也是一个迭代过程，可以用XP的一些方式，如先编写测试，再开发代码等等
５测试组　进行整合测试，当然也有模块测试，与开发组是协调进行的
５美工组　设计UI
６数据库组　由PM那边建立的ER来与PM进行协商进行数据建模并做物理实现和DBA的工作，目的是一实现PM的分析结果，二使用开发组在开发中数据操作最简易化，三DBServer的管理
７硬件组　保证不出现硬件问题，如果单机和网络等等

其中，由PM和系统分析组对Application服务器进行完整掌控

这其实已经足够了，但是如果进行的是企业系统的开发，那还需要一个行政的管理人员，级别越高越好

yining

最初由 base 发布
[B]实际上一个WEB应用项目，需要有这样的组合，当然这是我一直使用的组合方式：
１业务人员　提供实际业务需求
３系统分析组　对系统的实现进行分析，采用架构，语言，以及其他的东西，就是思考如何实现，这与PM进行充分交流协商进行的，然后建立模块，按其关系进行分组开发
[/B]

对于小规模的web应用来说，1和3的配置好像比较奢侈了一些。即使是对大规模的企业级应用来说，有这样的人员配置也就很好了。至少，我现在的工作环境是这样的。规模小点的公司，就更不可能有这样的配置了。

星期一是公休假，所以恐怕要到星期二才能上来，还是现在先写一些东西吧。事先声明，本人对用例分析一向不在行，尤其是业务用例的分析。所以真地做起来只能加进不少本人的主观臆想，请大家一起讨论。

用例：

前面说过，一期的用例很少：
1。用户浏览
任何用户，不论是已经登陆的用户还是没有登陆的用户，都有权浏览各个分论坛以及帖子。用户通过点击连接，进入用户选择的分论坛或者是帖子。如果用户选择的是帖子，则该帖子要显示从论坛根目录倒贴字的路径，以方便用户返回。在该帖子中还应该显示所有的跟帖，先是顺序按照发帖的时间顺序排列。每一个铁子都应该显示帖子的题目，作者，回帖时间，以及内容。

如果用户选择进入一个分论坛，首先要显示的是，从论坛根目录到分论坛的路径。然后显示这个分论坛下面的所属分论坛，最后显示这个分论坛中的帖子。所有现实的帖子均为新帖，回帖不显示。现实的顺序根据最后回复的时间逆序排列。所属分论坛现实的顺序根据字母顺序排列。所有的分论坛应显示论坛名字，说明，论坛的帖数，以及最后的回复时间，及回复作者。帖子应显示题目，原作者，最后回复作者，原帖发表时间以及最后回复时间。

2。用户发新帖子
只有以登陆用户有权发新帖子。如果用户状态为尚未登陆，则给出提示要求登陆。如用户已经登陆，则进入发新帖页面。当用户在分论坛中，或者帖子中才允许发新帖。所发的新帖属于用户所处的分论坛。

用户必须给出帖子的题目，以及内容。如果两项中有一项为空，则必须给出提示，并不允许用户发表。当两项都被填充时，允许用户发表帖子，并回到分论坛。

3。用户发回帖
只有以登陆用户有权发回帖。如果用户状态为尚未登陆，则给出提示要求登陆。如用户已经登陆，则进入发回帖页面。当用户在帖子中才允许发新帖。所发的回帖属于用户所处的帖子。

用户可以不给出帖子的题目，但是必须给出内容。如果内容为空，必须给出提示，并不允许用户发表。如果内容以填充，则允许用户发表。

4。用户注册
任何状态的用户都可以注册。注册用户需提交用户名，密码，密码确认，以及email地址。如果用户名已经存在，或者密码和密码确认不符，则给出错误信息，禁止注册。否则注册成功，并自动登陆新注册用户。

5。用户修改
之后登陆用户可以修改自己的信息。用户可以修改密码，密码确认，以及email地址，但是不能修改用户名。如果密码和密码确认不符，则修改失败，给出错误信息。否则修改成功。

6。用户登陆
任何状态的用户都可以登陆。当用户选择登陆时，进入登陆页面，用户必须输入用户名和密码，检验正确通过之后用户状态变为以登陆，并记录用户身份以及登陆时间。如果用户名和/或密码错误，给出出错信息，用户身份为登陆前的身份（如登陆前已经是登陆用户，仍保持登陆用户的身份）

7。用户退出
只有登陆用户允许退出。当登陆用户选择退出时，进入退出页面，要求用户确认。如果用户确认，则将用户身份转变为未登陆。如果用户选择取消，则保持登陆身份。

yining

这就是第一期的全部用例了。

blueocean926

我也算一个
lipeng@softbrain.com.cn