夜已深，我呆坐在凌乱堆着草稿的写字桌旁边，和今天郑州的天气一样，我的心里充满了大雾。
先来介绍一下一个月以前我的一个设想吧，很简单：利用现在很流行的ASP.net技术制作一个我个人的网站。
主题是：关于VC编程的学习网站。网站名称:VC编程空间
目的：1.算是我的一个作品；2.网站制作成功之后，我可以邀请好朋友一起参加网站建设，扩大视野，增加交流；等等。
初步设想：利用家里用宽带上网，我可以把我的机器变成主机，操作系统用2000，利用ASP.NET技术制作网站，后台数据库：SQL。
因为我以前也和朋友制作过几个小的网站，页面和功能都很简单，我对PS、DW、FW、FLASH等工具也比较熟悉，满以为很简单的问题，毕竟是个人的网站嘛，也不是多么复杂的技术，于是11月的时候就开始网站的开发工作，那时候一切进行的非常的顺利，用了两天的时间，我开发了主要的几个栏目的页面，并且在主页上先尝试着添加了一些简单的ASP.NET程序，如：注册的验证，网站的访问统计功能。
可是就在这时候出现了一个我以为的“小问题”：我发现我的思路开始扩大，甚至开始混乱。我为网站设想了许多功能，因为我希望我的网站作成之后能够很好的让朋友们在上面交流、学习、甚至共同开发软件。这样网站的功能需求就开始扩大了，WEB界面也增加很多，我发现我想很好的组织起来就有点困难了，比如，由于我功能的增加，我发现我原先设计的主页的界面上少了一些接口来进入我所设想的功能，其他的页面也一样，这就是说我需要重新再设计一遍所有的WEB页面，我想这样的工作效率是很低，而且很容易出现漏洞，况且我还没有考虑到一些业务逻辑以外的问题如：安全性、后台控制等问题，这样的网站是不成熟的。
另外还有一个问题，因为我最终是想要学习面向对象的设计和编程，不完全拘泥于一种语言（VC是我想重点深入的语言），所以我想网站也是一个信息系统，我应该按照OO的思想来进行分析和设计，我希望能够在有一套设计文档的指导下，我再开始WEB界面的设计和后台代码的编写。
正是在这样的问题下，我开始了SDLC的软件工程过程，分析-设计-实施-测试。我想这也会对我以后的编程工作有很大的帮助，但是问题也从此产生，而且比前面更复杂。
上个月的大部分时间我捧着一本厚厚的《系统分析与设计》和另一个：《UML基础、案例和应用》的书，两本对照着看了起来，匆匆的看了一遍，大概了解了OOA和OOD，但是两本书的差别也很大。比如：《系统》一书中，在分析阶段要求列出详细的事件表，格式：1.事件名；2.触发器；3.来源；4.动作；5.响应；6.目的地。要求从事件表中找出用例。而〈UML〉一书则直接就列出用例。等等，不过我想我实际用的时候就能自己摸索出真正的思想。
接下来的时候我开始了分析，我画出了：事件表、用例图和类图。但是我不知道我画的这些对还是不对，我只是按照我自己的想法罗列了所有我想到的功能，我想到的类。如下：
事件列表：（动作、响应、目的地的内容省略，大家也能大概想到）
事件名
触发器
来源
动作
响应
目的地
1.浏览文章（文件）
http请求
普通用户/管理员
2.下载文件
http请求
普通用户/管理员
3.发表文章（文件）
http请求
用户
4.修改删除文章（文件）
http请求
用户
5.搜索文章（文件）
http请求
普通用户/管理员
6.添加文章（文件）
http请求
管理员
7.修改删除文章（文件）
http请求
管理员
8.发表评论
http请求
普通用户/管理员
9.注册帐号
http请求
匿名用户
10.登陆帐号
http请求
匿名用户
11.修改帐号信息
http请求
用户
12.添加帐号
http请求
管理员
13.修改帐号
http请求
管理员
14.浏览帐号
http请求
管理员
15.搜索帐号
http请求
管理员
16.查询帐号信息
http请求
普通用户/管理员
17.统计系统信息
http请求
管理员
18.统计文件信息
http请求
管理员
19.统计帐户信息
http请求
管理员
20.注销
http请求
普通用户/管理员
21.申请项目
http请求
普通用户/管理员
22.批准项目
http请求
管理员
23.查找项目
http请求
普通用户/管理员
24.查询项目状态
http请求
普通用户/管理员
25.修改项目状态
http请求
组长/管理员
26.撤消项目
http请求
组长/管理员
27.申请项目组员
http请求
普通用户/管理员
28.批准组员
http请求
组长
29.查找组员
http请求
普通用户/管理员
30.查询组员状态
http请求
普通用户/管理员
31.修改组员状态
http请求
组长
32.删除组员
http请求
组长
33.站内实时通信
http请求
普通用户/管理员
分析类图：主要分：项目类、文件类、用户类、组类四大类。文件类的子类：文章类和压缩文件类；用户类的子类：普通用户类和管理员类；项目类由文件类和组类组合而成。文章类子类：文档类和留言类。这是一个初步的分析类图，一开始我还想把界面类也包括进来，但是发现太乱了。注:还有一些关联和基数我没有写明,但在这个系统中,类不多,关系也比较简单,所以省略了。
系统用例图：
1.文件维护子系统：1>查询文件系统; 2>添加文件;3>更新文件;4>查找文件;
2.用户维护子系统: 1>添加用户;2>更新用户信息;3>查找用户;4>查询用户信息;
3.项目管理子系统(包含组维护系统):1>申请项目;2>更新项目状态;3>查找项目;4>查询项目状态;
组维护系统:1>申请加入项目组;2>查找组员;3>查询组员状态;4>更新组员状态;
4.站内通信子系统:1>站点内实时通信;2>站内公告;
写这些图的时间并不长，但是我总是一遍遍的思考着这样一个问题:该怎样分类?怎么确定这是一个用例?还有没有别的类?当然，我用迭代的开发方法，我希望在以后时间的分析设计中可以再回过头来完善我前面的文档。
写到这里我的心情开始舒缓起来，因为我终于算是介绍完了我前面的工作，大概分析了一下我整个网站的需求，下一步是我该开始画用例的顺序图了，这是一个细化的过程，我需要详细的考虑每一个细节。
同时，我陷入了深深的迷茫.因为我开始意识到我想表达的太多，怎么画好顺序图。 还有就是设计顺序图中要牵扯到很多的WEB界面类，我要不要也画上。
比如:查询文件系统吧，说白了就是让用户找到他关心的文章，浏览文章。 但问题是，情况有很多: 如，想要看<ADO教程>这篇文章，有的人是先进入"教程"栏目然后在该页面中的文章列表中找到这篇文章，用鼠标单击观看，但有的人则是在搜索条上键入<ADO教程>的关键字，在搜索结果的列表中找到这篇文章，还有的人是通过别的文章下面的关联文章列表中点击浏览的。 这在顺序图上该怎么表示?
另一个很重要的问题 :有些文章是属于一个项目的开发文档,有的开发小组是不愿意透漏还没有完成的文档的，或者是一些文档只限在一个小组内部观看，这时候我就要在查询文件的顺序图上加上一定的权限禁止项目外或小组外的人观看。这在顺序图上该怎么表示?
由此引申出了这样一个问题，如果我还想统计一下用户浏览的文章，那么我是不是还要在顺序图上画一个返回给用户类的消息，改变用户的属性?这样下去，细节的东西很多，我甚至想要不要把ADO.NET控件也做为一个类画到图上，以显示与数据库的交互，是不是也要加上数据绑定控件...。 这样我的顺序图不是就变的混乱了，要知道作为一个好的UML图应该尽量的做到简明发。 那么什么是该取舍的呢?
还有一些问题，如添加文件用例:有的情况，网友要发表文章在论坛上；有的情况，管理员要添加文章或者是原代码文件到文件数据库以供网友浏览；有的情况，网友要在栏目文章后面发表自己的看法评论；有的情况，网友要写在线日记，也是发表文章的一种(但他可以选择给不给别人看)；有的情况，项目组长或组员要添加文章到一个项目中。这样的情况很多，几乎每一种用例都有不同的场景，是不是每一种情况都要给出相应的顺序图?这样做对以后的设计有好处吗?
这些问题刚开始设计都有一大堆，关键是，你能不能把每一个细节记录下来，在大脑里过一遍,然后仔细分析每一个问题，判断取舍。
我希望通过写这样一系列文章，和朋友们分享我作为一个新手在一个系统建模问题上的经验，同时也希望朋友们对我思考OOA/D的过程提出宝贵的意见与大家分享。
