故事一：疯子与呆子

一个心理学教授到疯人院参观，了解疯子的生活状态。一天下来，觉得这些人疯疯癫癫，行事出人意料，可算大开眼界。想不到准备返回时，发现自己的车胎被人卸掉了。“一定是哪个疯子干的！”教授这样愤愤地想道，动手拿备用胎准备装上。

事情严重了。卸车胎的人居然将螺丝也都卸掉。没有螺丝有备用胎也装不上去啊！教授一筹莫展。在他着急万分的时候，一个疯子蹦蹦跳跳地过来了，嘴里唱着不知名的欢乐歌曲。他发现了困境中的教授，停下来问发生了什么事。教授懒得理他，但出于礼貌还是告诉了他。疯子哈哈大笑说：“我有办法！”他从每个轮胎上面下了一个螺丝，这样就拿到三个螺丝将备用胎装上去了。教授惊奇感激之余，大为好奇：“请问你是怎么想到这个办法的？”疯子嘻嘻哈哈地笑道：“我是疯子，可我不是呆子啊！”其实，世上有许多的人，由于他们发现了工作中的乐趣，总会表现出与常人不一样的狂热，让人难以理解。许多人在笑话他们是疯子的时候，别人说不定还在笑他呆子呢。

做人呆呆，处事聪明，在中国尤其不失为一种上佳做人姿态。

故事二：机会与准备

A在合资企业做白领，觉得自己满腔抱负，没有得到上级的赏识，经常想：如果有一天能见老总，有机会展示一下自己的才干就好了！！

　 A的同事B，也有同样的想法，他更进一步，去打听老总上下班的时间，算好他大概会在何时进电梯，他也在这个时候去坐电梯，希望能遇到老总，有机会可以打个招呼。

他们在合资公司做白领，觉得自己满腔抱负没有得的同事C更进一步。他详细了解老总的奋斗历程，弄清老总毕业的学校，人际风格，关心的问题，精心设计了几句简单却有份量的开场 白，在算好的时间去乘坐电梯，跟老总打过几次招后，

终于有一天跟老总长谈了一次，不久就争取到了更好的职位。

　愚者错失机会，智者善抓机会，成功者创造机会。机会只给准备好的人，这准备二字，并非说说而已。

故事三：谁的身价最高？

一个人去买鹦鹉，看到一只鹦鹉前标：此鹦鹉会两门语言，售价二百元。　另一只鹦鹉前则标道：此鹦鹉会四门语言，售价四百元。该买哪只呢？两只都毛色光鲜，非常灵活可爱。这人转啊转，拿不定主意。结果突然发现一只老掉了牙的鹦鹉，毛色暗淡散乱，标价八百元。

这人赶紧将老板叫来：这只鹦鹉是不是会说八门语言？

店主说：不。

这人奇怪了：那为什么又老又丑，又没有能力，会值这个数呢？

店主回答：因为另外两只鹦鹉叫这只鹦鹉老板。

这故事告诉我们，真正的领导人，不一定自己能力多强，只要懂信任，懂放权，懂珍惜，就能团结比自己更强的力量，从而提升自己的身价。相反许多能力强的人却因为过于完美主义，事必躬亲，什么人都不如自己， 最后只能做最好的攻关人员，销售代表，成不了优秀的领导人。

故事四：成功与习惯

父子俩住山上，每天都要赶牛车下山卖柴。老父较有经验，坐镇驾车，山路崎岖，弯道特多，儿子眼神较好，总是在要转弯时提醒道：“爹，转弯啦！”

有一次父亲因病没有下山，儿子一人驾车。到了弯道，牛怎么也不肯转弯，儿子用尽各种方法，下车又推又拉，用青草诱之，牛一动不动。到底是怎么回事？儿子百思不得其解。最后只有一个办法了，他左右看看无人，贴近牛的耳朵大声叫道：“爹，转弯啦！”牛应声而动。

　牛用条件反射的方式活着，而人则以习惯生活。

一个成功的人晓得如何培养好的习惯来代替坏的习惯，当好的习惯积累多了，自然会有一个好的人生。

　故事五：积极与消极

有位秀才第三次进京赶考，住在一个经常住的店里。考试前两天他做了三个梦，第一个梦是梦到自己在墙上种白菜，第二个梦是下雨天，他戴了斗笠还打伞，第三个梦是梦到跟心爱的表妹脱光了衣服躺在一起，但是背靠着

这三个梦似乎有些深意，秀才第二天就赶紧去找算命的解梦。算命的一听，连拍大腿说：“你还是回家吧。你想想，高墙上种菜不是白费劲吗？戴斗笠打雨伞不是多此一举吗？跟表妹都脱光了躺在一张床上了，却背靠背，不是没戏吗？”

秀才一听，心灰意冷，回店收拾包袱准备回家。店老板非常奇怪，问：“不是明天才考试吗，今天你怎么就回乡了？”秀才如此这般说了一番，店老板乐了：“哟，我也会解梦的。我倒觉得，你这次一定要留下来。你想想，墙上种菜不是高种吗？戴斗笠打伞不是说明你这次有备无患吗？跟你表妹脱光了背靠靠躺在床上，不是说明你翻身的时候就要到了吗？”

秀才一听，更有道理，于是精神振奋地参加考试，居然中了个探花。

积极的人，象太阳，照到哪里亮，消极的人，象月亮，初一十五不一样。想法决定我们的生活，有什么样的想法，就有什么样的未来。

故事六：三个金人

曾经有个小国到中国来，进贡了三个一模一样的金人，金壁辉煌，把皇帝高兴坏了。可是这小国不厚道，同时出一道题目：这三个金人哪个最有价值？皇帝想了许多的办法，请来珠宝匠检查，称重量，看做工，都是一模一样的。怎么办？使者还等着回去汇报呢。泱泱大国，不会连这个小事都不懂吧？最后，有一位退位的老大臣说他有办法。

皇帝将使者请到大殿，老臣胸有成足地拿着三根稻草，插入第一个金人的耳朵里，这稻草从另一边耳朵出来了。第二个金人的稻草从嘴巴里直接掉出来，而第三个金人，稻草进去后掉进了肚子，什么响动也没有。老臣说：第三个金人最有价值！使者默默无语，答案正确。

    这个故事告诉我们，最有价值的人，不一定是最能说的人的人。老天给我们两只耳朵一个嘴巴，本来就是让我们多听少说的。善于倾听，才是成熟的人最基本的素质。

　故事七：因材施用

去过庙的人都知道，一进庙门，首先是弥陀佛，笑脸迎客，而在他的北面，则是黑口黑脸的韦陀。但相传在很久以前，他们并不在同一个庙里，而是分别掌管不同的庙。

弥乐佛热情快乐，所以来的人非常多，但他什么都不在乎，丢三拉四，没有好好的管理账务，所以依然入不敷出。而韦陀虽然管账是一把好手，但成天阴着个脸，太过严肃，搞得人越来越少，最后香火断绝。

佛祖在查香火的时候发现了这个问题，就将他们俩放在同一个庙里，由弥乐佛负责公关，笑迎八方客，于是香火大旺。而韦陀铁面无私， 锱珠必较，则让他负责财务，严格把关。在两人的分工合作中，庙里一派欣欣向荣景象。

其实在用人大师的眼里，没有废人，正如武功高手，不需名贵宝剑，摘花飞叶即可伤人，关键看如何运用。

故事八：善用资源

有个富家子弟特别爱吃饺子，每天都要吃。但他又特别刁，只吃馅，两头的皮尖尖就丢到后面的小河里去。好景不长，在他十六岁那年，一把大火烧了他的全家，父母急怒中相继病逝。这下他身无分文，又不好意思要饭。邻居家大嫂非常好，每餐给他吃一碗面糊糊。他则发奋读书，三年后考取官位回来，一定要感谢邻居大嫂。

大嫂对他讲：不要感谢我。我没有给你什么，都是我收集的当年你丢的饺子皮>尖，晒干后装了好凡麻袋，本来是想备不时之需的。正好你有需要，就又还给你了。大官思考良久，良久……

有一个有名的三八理论：八小时睡觉，八小时工作，这个人人一样。人与人之间的不同，是在于业余时间怎么渡过。时间是最有情，也最无情的东西，每人拥有的都一样，非常公平。但拥有资源的人不一定成功，善用资源的人才会成功。

白天图生存，晚上求发展，这是二十一世纪对人才的要求。

故事九：沟通与团队

有一个博士分到一家研究所，成为学历最高的一个人。

有一天他到单位后面的小池塘去钓鱼，正好正副所长在他的一左一右，也在钓鱼。他只是微微点了点头，这两个本科生，有啥好聊的呢？不一会儿，正所长放下钓竿，伸伸懒腰，蹭蹭蹭从水面上如飞地走到对面上厕所。博士眼睛睁得都快掉下来了。水上飘？不会吧？这可是一个池塘啊。正所长上完厕所回来的时候，同样也是蹭蹭蹭地从水上飘回来了。怎么回事？博士生又不好去问，自己是博士生哪！

过一阵，副所长也站起来，走几步，蹭蹭蹭地飘过水面上厕所。这下子博士更是差点昏倒：不会吧，到了一个江湖高手集中的地方？博士生也内急了。这个池塘两边有围墙，要到对面厕所非得绕十分钟的路，而回单位上又太远，怎么办？博士生也不愿意去问两位所长，憋了半天后，也起身往水里跨：我就不信本科生能过的水面，我博士生不能过。只听咚的一声，博士生栽到了水里。两位所长将他拉了出来，问他为什么要下水，他问：“为什么你们可以走过去呢？”两所长相视一笑：“这池塘里有两排木桩子，由于这两天下雨涨水正好在水面下。我们都知道这木桩的位置，所以可以踩着桩子过去。你怎么不问一声呢？”

　学历代表过去，只有学习力才能代表将来。尊重经验的人，才能少走弯路。一个好的团队，也应该是学习型的团队。

　故事十：大师与弟子

有一位表演大师上场前，他的弟子告诉他鞋带松了。大师点头致谢，蹲下来仔细系好。等到弟子转身后，又蹲下来将鞋带解松。有个旁观者看到了这一切，不解地问：“大师，您为什么又要将鞋带解松呢？”大师回答道：“因为我饰演的是一位劳累的旅者，长途跋涉让他的鞋事松开，可以通过这个细节表现他的劳累憔悴.”“那你为什么不直接告诉你的弟子呢？”“他能细心地发现我鞋带松了，并热心地告诉我，我要保护他这种热情的积极性，及时地给他鼓励，至于为什么要将鞋带解开，将来会有更多的机会教他表演，可以下一次再说啊。”

　人一个时间只能做一件事，懂抓重点，才是真正的人才。

故事十一：心态与舞台

在动物园里的小骆驼问妈妈：“妈妈，为什么我们的睫毛那么地长？”骆驼妈妈说：“当风沙来的时候，长长的睫毛可以让我们在风暴中都能看得到方向。”小骆驼又问：“妈妈，为什么我们的背那么驼，丑死了！”骆驼妈妈说：“这个叫驼峰，可以帮我们储存大量的水和养分，让我们能在沙漠里耐受十几天的无水无食条件。”小骆驼又问：“妈妈，为什么我们的脚掌那么厚？”骆驼妈妈说：“那可以让我们重重的身子不至于陷在软软的沙子里，便于长途跋涉啊。”小骆驼高兴坏了：“哗，原来我们这么有用啊！！可是妈妈，为什么我们还在动物园里，不去沙漠远足呢？”　　天生我才必用，可惜现在没人用。一个好的心态+一本成功的教材+一个无限的舞台=成功。每人的潜能是无限的，关键是要找到一个能充分发挥潜能的舞台。

故事十二：不同的分配制度

有七个人曾经住在一起，每天分一大桶粥。要命的是，粥每天都是不够的。一开始，他们抓阄决定谁来分粥，每天轮一个。于是乎每周下来，他们只有一天是饱的，就是自己分粥的那一天。后来他们开始推选出一个道德高尚的人出来分粥。强权就会产生腐败，大家开始挖空心思去讨好他，贿赂他，搞得整个小团体乌烟障气。然后大家开始组成三人的分粥委员会及四人的评选委员会，互相攻击扯皮下来，粥吃到嘴里全是凉的。最后想出来一个方法：轮流分粥，但分粥的人要等其它人都挑完后拿剩下的最后一碗。为了不让自己吃到最少的，每人都尽量分得平均，就算不平，也只能认了。大家快快乐乐，和和气气，日子越过越好。

　　同样是七个人，不同的分配制度，就会有不同的风气。所以一个单位如果有不好的工作习气，一定是机制问题，一定是没有完全公平公正公开，没有严格的奖勤罚懒。如何制订这样一个制度，是每个领导需要考虑的问题。

故事十三：选择

有三个人要被关进监狱三年，监狱长给他们三个一人一个要求。

　美国人爱抽雪茄，要了三箱雪茄。法国人最浪漫，要一个美丽的女子相伴。而犹太人说，他要一部与外界沟通的电话。

　三年过后，第一个冲出来的是美国人，嘴里鼻孔里塞满了雪茄，大喊道：“给我火，给我火！”原来他忘了要火了。接着出来的是法国人。只见他手里抱着一个小孩子，美丽女子手里牵着一个小孩子，肚子里还怀着第三个。　　最后出来的是犹太人，他紧紧握住监狱长的手说：“这三年来我每天与外界联系，我的生意不但没有停顿，反而增长了200％，为了表示感谢，我送你一辆劳施莱斯！”

　　这个故事告诉我们，什么样的选择决定什么样的生活。今天的生活是由三年前我们的选择决定的，而今天我们的抉择将决定我们三年后的生活。我们要选择接触最新的信息，了解最新的趋势，从而更好的创造自己的将来。

故事十四：强者

五岁的汉克和爸爸妈妈哥哥一起到森林干活，突然间下起雨来，可是他们只带了一块雨披。爸爸将雨披给了妈妈，妈妈给了哥哥，哥哥又给了汉克。汉克问道：“为什么爸爸给了妈妈，妈妈给了哥哥，哥哥又给了我呢？”爸爸回答道：“因为爸爸比妈妈强大，妈妈比哥哥强大，哥哥又比你强大呀。我们都会保护比较弱小的人。”汉克左右看了看，跑过去将雨披撑开来挡在了一朵风雨中飘摇的娇弱小花上面。

这个故事告诉我们，真正的强者不一定是多有力，或者多有钱，而是他对别人多有帮助。

责任可以让我们将事做完整，爱可以让我们将事情做好。

故事十五：跑鞋的故事

两个人在森林里，遇到了一只大老虎。A就赶紧从背后取下一双更轻便的运动鞋换上。B急死了，骂道：“你干嘛呢，再换鞋也跑不过老虎啊！”　A说：“我只要跑得比你快就好了。”

二十一世纪，没有危机感是最大的危机。特别是入关在即，电信，银行，保险，甚至是公务员这些我们以为非常稳定和有保障的企业，也会面临许多的变数。

当更多的老虎来临时，我们没有有准备好自己的跑鞋？

故事十六：我要离开这个公司

A对B说：“我要离开这个公司。我恨这个公司！”

B建议道：“我举双手赞成你报复！！破公司一定要给它点颜色看看。不过你现在离开，还不是最好的时机。”   　A问：？？？

 B说：“如果你现在走，公司的损失并不大。你应该趁着在公司的机会，拼命去为自己拉一些客户，成为公司独挡一面的人物，然后带着这些客户突然离开公司，公司才会受到重大损失，非常被动。” A觉得B说的非常在理。于是努力工作，事遂所愿，半年多的努力工作后，他有了许多的忠实客户。

再见面时B问A：现在是时机了，要跳赶快行动哦！

A淡然笑道：老总跟我长谈过，准备升我做总经理助理，我暂时没有离开的打算了。

其实这也正是B的初衷。一个人的工作，永远只是为自己的简历。

只有付出大于得到，让老板真正看到你的能力大于位置，才会给你更多的机会替他创造更多利润。

故事十七：“我是陈阿土！”

陈阿土是台湾的农民，从来没有出过远门。攒了半辈子的钱，终于参加一个旅游团出了国。国外的一切都是非常新鲜的，关键是，陈阿土参加的是豪华团，一个人住一个标准间。这让他新奇不已。

早晨，服务生来敲门送早餐时大声说道：“GOODMORNING SIR！”陈阿土愣住了。这是什么意思呢？在自己的家乡，一般陌生的人见面都会问：“您贵姓？”于是陈阿土大声叫道：“我叫陈阿土！”

如是这般，连着三天，都是那个服务生来敲门，每天都大声说：“GOODMORNINGSIR！”而陈阿土亦大声回道：“我叫陈阿土！”但他非常的生气。这个服务生也太笨了，天天问自己叫什么，告诉他又记不住，很烦的。终于他忍不住去问导游，“GOODMORNING SIR！”是什么意思，导游告诉了他，天啊！！真是丢脸死了。陈阿土反复练习“GOODMORNING SIR！”这个词，以便能体面地应对服务生。又一天的早晨，服务生照常来敲门，门一开陈阿土就大声叫道：“GOODMORNINGSIR！”与此同时，服务生叫的是：“我是陈阿土！”

这个故事告诉我们，人与人交往，常常是意志力与意志力的较量。不是你影响他，就是他影响你，而我们要想成功，一定要培养自己的影响力，只有影响力大的人才可以成为最强者。

故事十八：我想跟什么样的人合作

　曾经有人采访比尔盖次成功的秘决。比尔盖次说：因为又有更多的成功人士在为我工作。成功的人很多，但在我生活中我不认识，也没有办法去为他工作，而让成功的人为我工作，在现阶段，我更没有这个实力。只有合作，是我最喜欢和最欣赏的。我也力图借助一个宽松的环境和积极的团队，与更多的人公平合作，以便在未来替自己经营一个抵抗风险的事业。我最喜欢合作的人应该有以下几个特点：

一、 不甘心。二十一世纪，最大的危机是没有危机感，最大的陷阱是满足。人要学会用望远镜看世界，不是用近视眼看世界。顺境时要想着为自己找个退路，逆境时要懂为自己找出路.

二、 学习力强.学历代表过去,学习力掌握将来.懂得从任何的细节,所有的人身上学习和感悟,并且要懂得举一反三。主要的是，学习，其实是学与习两个字。学一次，做一百次，才能真正掌握。学，做，教是一个完整的过程，只有达到教的程度，才算真正吃透。而且在更多时候，学习是一种态度。只有谦卑的人，才真正学到东西。大海之所以成为大海，是因为它比所有的河流都低。

三、 行动力强。只有行动才会有结果。行动不一样，结果才不一样。知道不去做，等于不知道，做了没有结果，等于没有做。不犯错误，一定会错，因为不犯错误的人一定没有尝试。错了不要紧，一定要善于总结，然后再做，一直到正确的结果出来为止。

四、 要懂付出。要想杰出一定得先付出。斤斤计较的人，一生只得两斤。有点奉献精神，是不可能创业的。要先用行动让别人知道，你有超过所得的价值，别人才会开更高的价。

五、 有强烈的沟通意识。沟通无极限，这更是一种态度，而非一种技巧。一个好的团队当然要有共同的愿景，非一日可以得来。需要无时不在的沟通，从目标到细节，甚至到家庭等等，都在沟通的内容之列。

六、 诚恳大方。每人都有不同的立场，不可能要求利益都一致。关键是大家都要开诚布公地谈清楚，不要委屈求全。相信诚信才是合作的最好基石。

七、 有最基本的道德观。曾经有一个记者在家写稿时，他的四岁儿子吵着要他陪。记者很烦，就将一本杂志的封底撕碎，对他儿子说：“ 你先将这上面的世界地图拼完整，爸爸就陪你玩。”过了不到五分钟，儿子又来拖他的手说：“爸爸我拼好了，陪我玩！”记者很生气：“小孩子要玩是可以理解的，但如果说谎话就不好了。怎么可能这么快就拼好世界地图！”儿子非常委屈：“可是我真的拼好了呀！”记者一看，果然如此：不会吧？家里出现了神童？他非常好奇地问：“你是怎么做到的？”儿子说：世界地图的背面是一个人的头像。我反过来拼，只要拼这个人了，世界就完整了。所以做事先做人。做人做好了，他的世界也就是好的。

　陈安之的超级成功学也有提到：先为成功的人工作，再与成功的人合作，最后是让成功的人为你工作。

jdbc和jndi的区别

JDBC -最基本的连接数据库的方式， 每次对数据库打交道的时候 ，连接数据库是需要实例下你实现连接数据库的方法或者类。
JNDI DataSource 英文全称是:Java Naming and Directory Interface java 命明接口，当服务启动时 事先把连接数据库的已经连好多条，具体多少条你可以设置，存放在tomcat容器里，用的时候可以直接使用， 不用再实例化得到连接， 相对与jdbc效率要快点

在eclipse设计报表的时候，我们使用jdbc链接数据库做测试，当到了tomcat运行环境中切换到jndi连接池，这是比较方便的开发方法。

实现步骤：

1.tomcat配置jndi连接池

在 {tomcat目录}\webapps\{项目名}\META-INF 中新增context.xml文件，配置代码如下

<?xml version="1.0" encoding="UTF-8"?>
<Context>
 <Resource
      auth="Container"
      name="jdbc/travel_agency"
      type="javax.sql.DataSource"
      maxIdle="5"
      maxWait="-1"
   driverClassName="com.mysql.jdbc.Driver"
      username="itravel"
   password="709394"
      url="jdbc:mysql://192.168.1.100/travel_agency?useUnicode=true&amp;characterEncoding=UTF-8"
      maxActive="10"/>
</Context>

2.在web.xml中加入配置

<resource-ref>
    <description>Database Source</description>
    <res-ref-name>jdbc/travel_agency</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
</resource-ref>

3.实例报表中数据源代码

1 <data-sources>
2        <oda-data-source extensionID="org.eclipse.birt.report.data.oda.jdbc" name="数据源" id="227">
3            <property name="odaDriverClass">com.mysql.jdbc.Driver</property> 
4            <property name="odaURL">jdbc:mysql://192.168.1.100/travel_agency</property> 
5            <property name="odaUser">itravel</property>
6            <encrypted-property name="odaPassword" encryptionID="base64">NzA5Mzk0</encrypted-property>
7            <property name="odaJndiName">java:comp/env/jdbc/travel_agency</property>
8        </oda-data-source>
9    </data-sources>

除了第7行 <property name="odaJndiName">java:comp/env/jdbc/travel_agency</property>，其余是我们的之前的配置。用了第7行的代码，表示该报表支持jndi数据源，birt在运行报表的时候，会先用jndi去连接，如果失败了再用jdbc链接，这样做的好处就是，我们在开发报表的时候，没有放到web环境中，可以使用jdbc，当放到tomcat中，因为有了第7行的配置。默认采用jdni连接。

4.步骤3中第6行密码的生成程序（JAVA程序）
package com.hollycrm.birt.security;

import java.io.BufferedReader;

import java.io.IOException;

import java.io.InputStreamReader;

import sun.misc.BASE64Encoder;

public class CreateBirtBase64Password {

public static void main(String[] args) {

InputStreamReader inStreamReader = new InputStreamReader(System.in);

BufferedReader buffReader = new BufferedReader(inStreamReader);

System.out.println("请输入需要通过Base64加密的字符串：");

String strSrcPassword = null;

try {

strSrcPassword = buffReader.readLine();

if (strSrcPassword != null) {

// 通过用户输入的密码信息生成Base64的加密密码

String strBase64Password = new BASE64Encoder().encode(strSrcPassword.trim().getBytes());

System.out.println("您输入的原始密码为：" + strSrcPassword + "\r对应生成的Base64密码值为：" + strBase64Password);

}

} catch (IOException e) {

e.printStackTrace();

}

}

}

  }
 </script>
</head>
<body>

 <!-- 总结: 动态生成页面表格 -->
 <!--    1: 在页面中本身就没有<table>标签时, 必须创建<table>、<tbody>、<tr>、<td>这四个标签,并且缺一不可; -->
 <!--   参见：“第一部分代码” -->
 <!--    2: 在页面中本身存在<table>标签时, 依据上边四个标签必须有的原则：在页面中有的标签我们直接取 -->
 <!--   最内层的标签, 然后把缺的标签补上即可;参见：“第二部分代码” -->
 <!--    3: 对于没有父子关系的标签，如ID为8的标签（即：div标签）与tr标签就没有父子关系。-->
 <!--   此时，就不能直接添加tbody标签到div标签内部. 参见：“第三部分代码”。-->

 <!-- 此处仅有div标签 -->
 <div id='1'>
    
 </div>

 <!-- 此处仅有table标签 -->
 <table id='2'>
  
 </table>

 <!-- 此处有table、tbody二种标签 -->
 <table id='3'>
  <tbody id='4'>

  </tbody>
 </table>

 <table id='5'>
  <tbody id='6'>
   <tr id=7>
    
   </tr>
   <div id='8'>
    
   </div>
  </tbody>
 </table>
</body>
<html>

<script language='javascript'>
 addNode();
</script>

作为基于MVC模式的Web应用最经典框架，Struts已经正式推出了1.1版本，该版本在以往版本的基础上，提供了许多激动人心的新功能。本文就将带你走进Struts 1.1去深入地了解这些功能。

本文内容包括：
	Model 2
	Struts 1.1 和Model 2
	模块
	ActionServlet
	ActionForm
	Action
	宣称式异常处理
	taglib
	Commons Logging 接口
	关于作者
	对本文的评价

说明：希望本文的读者能有一定的Struts使用基础。

Model 2

Struts是基于Model 2之上的，而Model 2是经典的MVC（模型－视图－控制器）模型的Web应用变体，这个改变主要是由于网络应用的特性--HTTP协议的无状态性引起的。Model 2的目的和MVC一样，也是利用控制器来分离模型和视图，达到一种层间松散耦合的效果，提高系统灵活性、复用性和可维护性。在多数情况下，你可以将Model 2与MVC等同起来。

下图表示一个基于Java技术的典型网络应用，从中可以看出Model 2中的各个部分是如何对应于Java中各种现有技术的。

在利用Model 2之前，我们是把所有的表示逻辑和业务逻辑都集中在一起（比如大杂烩似的JSP），有时也称这种应用模式为Model 1，Model 1的主要缺点就是紧耦合，复用性差以及维护成本高。

回页首

Struts 1.1 和Model 2

既然Struts 1.1是基于Model 2之上，那它的底层机制也就是MVC，下面是Struts 1.1中的MVC实现示意图：

图解说明：其中不同颜色代表MVC的不同部分：红色（控制器）、紫色（模型）和绿色（视图）

首先，控制器（ActionServlet）进行初始化工作，读取配置文件（struts-config.xml），为不同的Struts模块初始化相应的ModuleConfig对象。比如配置文件中的Action映射定义都保存在ActionConfig集合中。相应地有ControlConfig集合、FormBeanConfig集合、ForwardConfig集合和MessageResourcesConfig集合等。

提示：模块是在Struts 1.1中新提出的概念，在稍后的内容中我们将详细介绍，你现在可以简单地把模块看作是一个子系统，它们共同组成整个应用，同时又各自独立。Struts 1.1中所有的处理都是在特定模块环境中进行的。模块的提出主要是为了解决Struts 1.0中单配置文件的问题。

控制器接收HTTP请求，并从ActionConfig中找出对应于该请求的Action子类，如果没有对应的Action，控制器直接将请求转发给JSP或者静态页面。否则控制器将请求分发至具体Action类进行处理。

在控制器调用具体Action的execute方法之前，ActionForm对象将利用HTTP请求中的参数来填充自己（可选步骤，需要在配置文件中指定）。具体的ActionForm对象应该是ActionForm的子类对象，它其实就是一个JavaBean。此外，还可以在ActionForm类中调用validate方法来检查请求参数的合法性，并且可以返回一个包含所有错误信息的ActionErrors对象。如果执行成功，ActionForm自动将这些参数信息以JavaBean（一般称之为form bean）的方式保存在Servlet Context中，这样它们就可以被其它Action对象或者JSP调用。

Struts将这些ActionForm的配置信息都放在FormBeanConfig集合中，通过它们Struts能够知道针对某个客户请求是否需要创建相应的ActionForm实例。

Action很简单，一般只包含一个execute方法，它负责执行相应的业务逻辑，如果需要，它也进行相应的数据检查。执行完成之后，返回一个ActionForward对象，控制器通过该ActionForward对象来进行转发工作。我们主张将获取数据和执行业务逻辑的功能放到具体的JavaBean当中，而Action只负责完成与控制有关的功能。遵循该原则，所以在上图中我将Action对象归为控制器部分。

提示：其实在Struts 1.1中，ActionMapping的作用完全可以由ActionConfig来替代，只不过由于它是公共API的一部分以及兼容性的问题得以保留。ActionMapping通过继承ActionConfig来获得与其一致的功能，你可以等同地看待它们。同理，其它例如ActionForward与ForwardConfig的关系也是如此。

下图给出了客户端从发出请求到获得响应整个过程的图解说明。

下面我们就来详细地讨论一下其中的每个部分，在这之前，先来了解一下模块的概念。

回页首

模块

我们知道，在Struts 1.0中，我们只能在web.xml中为ActionServlet指定一个配置文件，这对于我们这些网上的教学例子来说当然没什么问题，但是在实际的应用开发过程中，可能会有些麻烦。因为许多开发人员都可能同时需要修改配置文件，但是配置文件只能同时被一个人修改，这样肯定会造成一定程度上的资源争夺，势必会影响开发效率和引起开发人员的抱怨。

在Struts 1.1中，为了解决这个并行开发的问题，提出了两种解决方案：

1. 多个配置文件的支持
2. 模块的支持

支持多个配置文件，是指你能够为ActionServlet同时指定多个xml配置文件，文件之间以逗号分隔，比如Struts提供的MailReader演示例子中就采用该种方法。

<!-- Action Servlet Configuration --> <servlet> <servlet-name>action</servlet-name> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class> <init-param> <param-name>config</param-name> <param-value>/WEB-INF/struts-config.xml, /WEB-INF/struts-config-registration.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet>

这种方法可以很好地解决修改冲突的问题，不同的开发人员可以在不同的配置文件中设置自己的Action、ActionForm等等（当然不是说每个开发人员都需要自己的配置文件，可以按照系统的功能模块进行划分）。但是，这里还是存在一个潜在的问题，就是可能不同的配置文件之间会产生冲突，因为在ActionServlet初始化的时候这几个文件最终还是需要合并到一起的。比如，在struts-config.xml中配置了一个名为success的<forward>，而在struts-config-registration.xml中也配置了一个同样的<forward>，那么执行起来就会产生冲突。

为了彻底解决这种冲突，Struts 1.1中引进了模块（Module）的概念。一个模块就是一个独立的子系统，你可以在其中进行任意所需的配置，同时又不必担心和其它的配置文件产生冲突。因为前面我们讲过，ActionServlet是将不同的模块信息保存在不同的ModuleConfig对象中的。要使用模块的功能，需要进行以下的准备工作：

1、为每个模块准备一个配置文件

2、配置web.xml文件，通知控制器

决定采用多个模块以后，你需要将这些信息告诉控制器，这需要在web.xml文件进行配置。下面是一个典型的多模块配置：

<init-param> <param-name>config</param-name> <param-value>/WEB-INF/struts-config.xml</param-value> </init-param> <init-param> <param-name>config/customer</param-name> <param-value>/WEB-INF/struts-config-customer.xml</param-value> </init-param> <init-param> <param-name>config/order</param-name> <param-value>/WEB-INF/struts-config-order.xml</param-value> </init-param>

要配置多个模块，你需要在原有的一个<init-param>（在Struts 1.1中将其对应的模块称为缺省模块）的基础之上，增加模块对应的<init-param>。其中<param-name>表示为config/XXX的形式，其中XXX为对应的模块名，<param-value>中还是指定模块对应的配置文件。上面这个例子说明该应用有三个模块，分别是缺省模块、customer和order，它们分别对应不同的配置文件。

3、准备各个模块所需的ActionForm、Action和JSP等资源

但是要注意的是，模块的出现也同时带来了一个问题，即如何在不同模块间进行转发？有两种方法可以实现模块间的转发，一种就是在<forward>（全局或者本地）中定义，另外一种就是利用org.apache.struts.actions.SwitchAction。

下面就是一个全局的例子：

... <struts-config> ... <global-forwards> <forward name="toModuleB" contextRelative="true" path="/moduleB/index.do" redirect="true"/> ... </global-forwards> ... </struts-config>

可以看出，只需要在原有的path属性前加上模块名，同时将contextRelative属性置为true即可。此外，你也可以在<action>中定义一个类似的本地<forward>。

<action-mappings> <!-- Action mapping for profile form --> <action path="/login" type="com.ncu.test.LoginAction" name="loginForm" scope="request" input="tile.userLogin" validate="true"> <forward name="success" contextRelative="true" path="/moduleA/login.do"/> </action> </action-mappings>

如果你已经处在其他模块，需要转回到缺省模块，那应该类似下面这样定义，即模块名为空。

<forward name="success" contextRelative="true" path="/login.do"/>

此外，你也可以使用org.apache.struts.actions.SwitchAction，例如：

... <action-mappings> <action path="/toModule" type="org.apache.struts.actions.SwitchAction"/> ... </action-mappings> ...

回页首

ActionServlet

我们首先来了解MVC中的控制器。在Struts 1.1中缺省采用ActionServlet类来充当控制器。当然如果ActionServlet不能满足你的需求，你也可以通过继承它来实现自己的类。这可以在/WEB-INF/web.xml中来具体指定。

要掌握ActionServlet，就必须了解它所扮演的角色。首先，ActionServlet表示MVC结构中的控制器部分，它需要完成控制器所需的前端控制及转发请求等职责。其次，ActionServlet被实现为一个专门处理HTTP请求的Servlet，它同时具有servlet的特点。在Struts 1.1中它主要完成以下功能：

• 接收客户端请求
• 根据客户端的URI将请求映射到一个相应的Action类
• 从请求中获取数据填充Form Bean（如果需要）
• 调用Action类的execute()方法获取数据或者执行业务逻辑
• 选择正确的视图响应客户

此外，ActionServlet还负责初始化和清除应用配置信息的任务。ActionServlet的初始化工作在init方法中完成，它可以分为两个部分：初始化ActionServlet自身的一些信息以及每个模块的配置信息。前者主要通过initInternal、initOther和initServlet三个方法来完成。

我们可以在/WEB-INF/web.xml中指定具体的控制器以及初始参数，由于版本的变化以及Struts 1.1中模块概念的引进，一些初始参数被废弃或者移入到/WEB-INF/struts-config.xml中定义。下面列出所有被废弃的参数，相应地在web.xml文件中也不鼓励再使用。

• application
• bufferSize
• content
• debug
• factory
• formBean
• forward
• locale
• mapping
• maxFileSize
• multipartClass
• nocache
• null
• tempDir

ActionServlet根据不同的模块来初始化ModuleConfig类，并在其中以XXXconfig集合的方式保存该模块的各种配置信息，比如ActionConfig，FormBeanConfig等。

初始化工作完成之后，ActionServlet准备接收客户请求。针对每个请求，方法process(HttpServletRequest request, HttpServletResponse response)将被调用。该方法指定具体的模块，然后调用该模块的RequestProcessor的process方法。

protected void process(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { RequestUtils.selectModule(request, getServletContext()); getRequestProcessor(getModuleConfig(request)).process(request, response); }

RequestProcessor包含了Struts控制器的所有处理逻辑，它调用不同的processXXX方法来完成不同的处理。下表列出其中几个主要的方法：

方法	功能
processPath	获取客户端的请求路径
processMapping	利用路径来获得相应的ActionMapping
processActionForm	初始化ActionForm（如果需要）并存入正确的scope中
processActionCreate	初始化Action
processActionPerform	调用Action的execute方法
processForwardConfig	处理Action返回的ActionForward

回页首

ActionForm

对于ActionForm你可以从以下几个方面来理解它：

1. ActionForm表示HTTP窗体中的数据，可以将其看作是模型和视图的中介，它负责保存视图中的数据供模型或者视图使用。Struts 1.1文档中把它比作HTTP和Action之间的防火墙，这体现了ActionForm具有的过滤保护的作用，只有通过ActionForm验证的数据才能够发送到Action处理。
2. ActionForm是与一个或多个ActionConfig关联的JavaBean，在相应的action的execute方法被调用之前，ActionForm会自动利用请求参数来填充自己（初始化属性）。
3. ActionForm是一个抽象类，你必须通过继承来实现自己的类。

ActionForm首先利用属性的getter和setter方法来实现初始化，初始化完毕后，ActionForm的validate方法被调用，你可以在其中来检查请求参数的正确性和有效性，并且可以将错误信息以ActionErrors的形式返回到输入窗体。否则，ActionForm将被作为参数传给action的execute方法以供使用。

ActionForm bean的生命周期可以设置为session（缺省）和request，当设置为session时，记得在reset方法中将所有的属性重新设置为初始值。

由于ActionForm对应于HTTP窗体，所以随着页面的增多，你的ActionForm将会急速增加。而且可能同一类型页面字段将会在不同的ActionForm中出现，并且在每个ActionForm中都存在相同的验证代码。为了解决这个问题，你可以为整个应用实现一个ActionForm或者至少一个模块对应于一个ActionForm。

但是，聚合的代价就是复用性很差，而且难维护。针对这个问题，在Struts 1.1中提出了DynaActionForm的概念。

DynaActionForm类

DynaActionForm的目的就是减少ActionForm的数目，利用它你不必创建一个个具体的ActionForm类，而是在配置文件中配置出所需的虚拟ActionForm。例如，在下表中通过指定<form-bean>的type为"org.apache.struts.action.DynaActionForm"来创建一个动态的ActionForm--loginForm。

<form-beans> <form-bean name="loginForm" type="org.apache.struts.action.DynaActionForm"> <form-property name="actionClass" type="java.lang.String"/> <form-property name="username" type="java.lang.String"/> <form-property name="password" type="java.lang.String"/> </form-bean> </form-beans>

动态的ActionForm的使用方法跟普通的ActionForm相同，但是要注意一点。普通的ActionForm对象需要为每个属性提供getter和setter方法，以上面的例子而言，我们需要提供getUsername() 和 setUsername()方法取得和设置username属性，同样地有一对方法用于取得和设置password属性和actionClass属性。

如果使用DynaActionForm，它将属性保存在一个HashMap类对象中，同时提供相应的get(name) 和 set(name)方法，其中参数name是要访问的属性名。例如要访问DynaActionForm中username的值，可以采用类似的代码：

String username = (String)form.get("username")；

由于值存放于一个HashMap对象，所以要记得对get()方法返回的Object对象做强制性类型转换。正是由于这点区别，如果你在Action中非常频繁地使用ActionForm对象，建议还是使用普通的ActionForm对象。

在Struts 1.1中，除了DynaActionForm以外，还提供了表单输入自动验证的功能，在包org.apache.struts.validator中提供了许多有用的类，其中最常见的就是DynaValidatorForm类。

DynaValidatorForm类

DynaValidatorForm是DynaActionForm的子类，它能够提供动态ActionForm和自动表单输入验证的功能。和使用DynaActionForm类似，你必须首先在配置文件中进行配置：

<form-beans> <form-bean name="loginForm" type="org.apache.struts.validator.DynaValidatorForm"> <form-property name="actionClass" type="java.lang.String"/> <form-property name="username" type="java.lang.String"/> <form-property name="password" type="java.lang.String"/> </form-bean> </form-beans>

同时要定义验证的插件：

<plug-in className="org.apache.struts.validator.ValidatorPlugIn"> <set-property property="pathnames" value="/WEB-INF/validator-rules.xml, /WEB-INF/validation.xml"/> </plug-in>

其中的validator.xml和validator-rules.xml分别表示验证定义和验证规则的内容（可以合并在一起），比如针对上例中的DynaValidatorForm，我们有如下验证定义（validator.xml）：

<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE form-validation PUBLIC "-//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.0//EN" "http://jakarta.apache.org/commons/dtds/validator_1_0.dtd"> <!-- Validation Rules $Id: validation.xml--> <form-validation> <!-- ========== Default Language Form Definitions ===================== --> <formset> <form name="loginForm"> <field property="username" depends="required, minlength,maxlength"> <arg0 key="prompt.username"/> <arg1 key="${var:minlength}" name="minlength" resource="false"/> <arg2 key="${var:maxlength}" name="maxlength" resource="false"/> <var> <var-name>maxlength</var-name> <var-value>16</var-value> </var> <var> <var-name>minlength</var-name> <var-value>3</var-value> </var> </field> <field property="password" depends="required, minlength,maxlength" bundle="alternate"> <arg0 key="prompt.password"/> <arg1 key="${var:minlength}" name="minlength" resource="false"/> <arg2 key="${var:maxlength}" name="maxlength" resource="false"/> <var> <var-name>maxlength</var-name> <var-value>16</var-value> </var> <var> <var-name>minlength</var-name> <var-value>3</var-value> </var> </field> </form> </formset> </form-validation>

从上述定义中，我们可以看到对于字段username有三项验证：required, minlength, maxlength，意思是该字段不能为空，而且长度在3和16之间。而validator-rules.xml文件则可以采用Struts提供的缺省文件。注意在<form-bean>中定义的form是如何与validation.xml中的form关联起来的。最后，要启动自动验证功能，还需要将Action配置的validate属性设置为true。

<action path="/login" type="com.ncu.test.LoginAction" name="loginForm" scope="request" input="tile.userLogin"validate="true">

此时，Struts将根据xml配置文件中的定义来检验表单输入，并将不符合要求的错误信息输出到页面。但是你可能会想：这个功能虽然好，可是什么检验都跑到服务器端执行，效率方面和用户易用性方面是不是有些问题？你可能会怀念起那简单的JavaScript客户端验证。

不用担心，在Struts 1.1中也支持JavaScript客户端验证。如果你选择了客户端验证，当某个表单被提交以后，Struts 1.1启动客户端验证，如果浏览器不支持JavaScript验证，则服务器端验证被启动，这种双重验证机制能够最大限度地满足各种开发者的需要。JavaScript验证代码也是在validator-rules.xml文件中定义的。要启动客户端验证，你必须在相应的JSP文件中做如下设置：

1. 为<html:form>增加onsubmit属性
2. 设置Javascript支持

下表中列出了一JSP文件的示例代码，红字部分为Javascript验证所需代码。

<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %> <table bgcolor="#9AFF9A" cellspacing="0" cellpadding="10" border="1" width="100%"> <tr> <td> <table cellspacing="0" cellpadding="0" border="0" width="100%"> <tr bgcolor="#696969"> <td align="center"> <font color="#FFFFFF">Panel 3: Profile</font> </td> </tr> <tr> <td><br> <html:errors/> <html:form action="/login.do" focus="username" onsubmit="return validateLoginForm(this);"> <html:hidden property="actionClass"/> <center> <table> <tr> <td>UserName:</td> <td><html:text property="username" size="20"/></td> </tr> <tr> <td>Password:</td> <td><html:password property="password" size="20"/></td> </tr> <tr> <td colspan=2><html:submit property="submitProperty" value="Submit"/></td> </table> </center> </html:form> <html:javascript formName="loginForm" dynamicJavascript="true" staticJavascript="false"/> <script language="Javascript1.1" src="staticJavascript.jsp"></script> </td> </tr> </table> </td> </tr> </table>

其中onsubmit的值为"return validateLoginForm(this);"，它的语法为：

return validate + struts-config.xml中定义的form-bean名称 + (this);

staticJavascript.jsp的内容为：

<%@ page language="java" %> <%-- set document type to Javascript (addresses a bug in Netscape according to a web resource --%> <%@ page contentType="application/x-javascript" %> <%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %> <html:javascript dynamicJavascript="false" staticJavascript="true"/>

如果validator-rules.xml中定义的基本验证功能不能满足你的需求，你可以自己添加所需的验证类型。

回页首

Action

我们通过继承Action类来实现具体的执行类。具体Action类的功能一般都在execute（以前是perform方法）方法中完成，其中主要涉及到以下几个方面：

1. 辅助ActionForm进行一些表单数据的检查。
2. 执行必要的业务逻辑，比如存取数据库，调用实体bean等。
3. 更新服务器端的bean数据，后续对象中可能会用到这些数据，比如在JSP中利用bean:write来获得这些数据。
4. 根据处理结果决定程序的去处，并以ActionForward对象的形式返回给ActionServlet。

提示：由于在Action和ActionForm中都可以实现验证方法，那么如何来安排它们之间的分工呢？一般来说，我们秉着MVC分离的原则，也就是视图级的验证工作放在ActionForm来完成，比如输入不能为空，email格式是否正确，利用ValidatorForm可以很轻松地完成这些工作。而与具体业务相关的验证则放入Action中，这样就可以获得最大ActionForm重用性的可能。

前面我们提到过，我们主张将业务逻辑执行分离到单独的JavaBean中，而Action只负责错误处理和流程控制。而且考虑到重用性的原因，在执行业务逻辑的JavaBean中不要引用任何与Web应用相关的对象，比如HttpServletRequest，HttpServletResponse等对象，而应该将其转化为普通的Java对象。关于这一点，可以参考Petstore中WAF框架的实现思路。

此外，你可能还注意到execute与perform的一个区别：execute方法简单地掷出Exception异常，而perform方法则掷出ServletException和IOException异常。这不是说Struts 1.1在异常处理功能方面弱化了，而是为了配合Struts 1.1中一个很好的功能--宣称式异常处理机制。

回页首

宣称式异常处理

和EJB中的宣称式事务处理概念类似，宣称式异常处理其实就是可配置的异常处理，你可以在配置文件中指定由谁来处理Action类中掷出的某种异常。你可以按照以下步骤来完成该功能：

1. 实现org.apache.struts.action.ExceptionHandler的子类，覆盖execute方法，在该方法中处理异常并且返回一个ActionForward对象
2. 在配置文件中配置异常处理对象，你可以配置一个全局的处理类或者单独为每个Action配置处理类

下表就定义了一个全局的处理类CustomizedExceptionHandler，它被用来处理所有的异常。

<global-exceptions> <exception handler="com.yourcorp.CustomizedExceptionHandler" key="global.error.message" path="/error.jsp" scope="request" type="java.lang.Exception"/> </global-exceptions>

其中具体的参数含义，可以参考ExceptionHandler.java源文件。

回页首

taglib

讲完了模型和控制器，接下来我们要涉及的是视图。视图的角色主要是由JSP来完成，从JSP的规范中可以看出，在视图层可以"折腾"的技术不是很多，主要的就是自定义标记库的应用。Struts 1.1在原有的四个标记库的基础上新增了两个标记库--Tiles和Nested。

其中Tiles除了替代Template的基本模板功能外，还增加了布局定义、虚拟页面定义和动态页面生成等功能。Tiles强大的模板功能能够使页面获得最大的重用性和灵活性，此外可以结合Tiles配置文件中的页面定义和Action的转发逻辑，即你可以将一个Action转发到一个在Tiles配置文件中定义的虚拟页面，从而减少页面的数量。比如，下表中的Action定义了一个转发路径，它的终点是tile.userMain，而后者是你在Tiles配置文件中定义的一个页面。

<!-- ========== Action Mapping Definitions ============================== --> <action-mappings> <!-- Action mapping for profile form --> <action path="/login" type="com.ncu.test.LoginAction" name="loginForm" scope="request" input="tile.userLogin" validate="true"> <forward name="success" path="tile.userMain"/> </action> </action-mappings>

Tiles配置文件：tiles-defs.xml

<!DOCTYPE tiles-definitions PUBLIC "-//Apache Software Foundation//DTD Tiles Configuration//EN" "http://jakarta.apache.org/struts/dtds/tiles-config.dtd"> <tiles-definitions> <!-- ======================================================= --> <!-- Master definitions --> <!-- ======================================================= --> <!-- Page layout used as root for all pages. --> <definition name="rootLayout" path="/tiles-layouts/rootLayout.jsp"> <put name="titleString" value="CHANGE-ME"/> <put name="topMenu" value="/tiles-components/topMenu.jsp"/> <put name="leftMenu" value="/tiles-components/panel1.jsp"/> <put name="body" value="CHANGE-ME"/> <put name="footer" value="/tiles-components/footer.jsp"/> </definition> <!-- ======================================================= --> <!-- Page definitions --> <!-- ======================================================= --> <!-- User Login page --> <definition name="tile.userLogin" extends="rootLayout"> <put name="titleString" value="User Login"/> <put name="body" value="/src/userLogin.jsp"/> </definition> <!-- User Main page --> <definition name="tile.userMain" extends="rootLayout"> <put name="titleString" value="User Main"/> <put name="body" value="/src/userMain.jsp"/> </definition> </tiles-definitions>

而Nested标记库的作用是让以上这些基本标记库能够嵌套使用，发挥更大的作用。

回页首

Commons Logging 接口

所谓的Commons Logging接口，是指将日志功能的使用与日志具体实现分开，通过配置文件来指定具体使用的日志实现。这样你就可以在Struts 1.1中通过统一的接口来使用日志功能，而不去管具体是利用的哪种日志实现，有点于类似JDBC的功能。Struts 1.1中支持的日志实现包括：Log4J，JDK Logging API， LogKit，NoOpLog和SimpleLog。

你可以按照如下的方式来使用Commons Logging接口（可以参照Struts源文中的许多类实现）：

package com.foo; // ... import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; //... public class Foo { // ... private static Log log = LogFactory.getLog(Foo.class); // ... public void setBar(Bar bar) { if (log.isTraceEnabled()) { log.trace("Setting bar to " + bar); } this.bar = bar; } // ... }

而开启日志功能最简单的办法就是在WEB-INF/classes目录下添加以下两个文件：

commons-logging.properties文件：

# Note: The Tiles framework now uses the commons-logging package to output different information or debug statements. Please refer to this package documentation to enable it. The simplest way to enable logging is to create two files in WEB-INF/classes: # commons-logging.properties # org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog # simplelog.properties # # Logging detail level, # # Must be one of ("trace", "debug", "info", "warn", "error", or "fatal"). #org.apache.commons.logging.simplelog.defaultlog=trace org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog

simplelog.properties文件：

# Logging detail level, # Must be one of ("trace", "debug", "info", "warn", "error", or "fatal"). org.apache.commons.logging.simplelog.defaultlog=fatal

这里我们采用的日志实现是SimpleLog，你可以在simplelog.properties文件指定日志明细的级别：trace，debug，info，warn，error和fatal，从trace到fatal错误级别越来越高，同时输出的日志信息也越来越少。而这些级别是和org.apache.commons.logging.log接口中的方法一一对应的。这些级别是向后包含的，也就是前面的级别包含后面级别的信息。

• 配置Struts应用--解读Struts应用的两大配置文件
• struts配置

1. 什么是用例？

在介始用例方法之前，我们首先来看一下传统的需求表述方式-"软件需求规约"(Software Requirement Specification)。传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。一个典型的软件需求规约可能具有以下形式：

采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。在有些公司的开发流程中，这种需求被称为"内部需求"，而对应于用户的原始要求则被称之为"外部需求"。

功能分解方法的另一个缺点是这种方法分割了各项系统功能的应用环境，从各项功能项入手，你很难了解到这些功能项是如何相互关联来实现一个完成的系统服务的。所以在传统的SRS文档中，我们往往需要另外一些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得SRS需求更象是一个设计文档。

1.1 参与者和用例

从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。用例模型主要由以下模型元素构成：

• 参与者(Actor)
  参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。
• 用例(Use Case)
  用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
• 通讯关联(Communication Association)
  通讯关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。

这大三种模型元素在UML中的表述如下图所示。

以银行自动提款机(ATM)为例，它的主要功能可以由下面的用例图来表示。ATM的主要使用者是银行客户，客户主要使用自动提款机来进行银行帐户的查询、提款和转帐交易。

通讯关联表示的是参与者和用例之间的关系，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者；如果你不想强调对话中的主动与被动关系，可以使用不带箭头的关联实线。在参与者和用例之间的信息流不是由通讯关联来表示的，该信息流是缺省存在的（用例本身描述的就是参与者和系统之间的对话），并且信息流向是双向的，它与通讯关联箭头所指的方向亳无关系。

1.2 用例的内容

用例图使我们对系统的功能有了一个整体的认知，我们可以知道有哪些参与者会与系统发生交互，每一个参与者需要系统为它提供什么样的服务。用例描述的是参与者与系统之间的对话，但是这个对话的细节并没有在用例图中表述出来，针对每一个用例我们可以用事件流来描述这一对话的细节内容。如在ATM系统中的"提款"用例可以用事件流表述如下：

提款-基本事件流

1. 用户插入信用卡

2. 输入密码

3. 输入提款金额

4. 提取现金

5. 退出系统，取回信用卡

但是这只描述了提款用例中最顺利的一种情况，作为一个实用的系统，我们还必须考虑可能发生的各种其他情况，如信用卡无效、输入密码错、用户帐号中的现金余额不够等，所有这些可能发生的各种情况（包括正常的和异常的）被称之为用例的场景(Scenario)，场景也被称作是用例的实例(Instance)。在用例的各种场景中，最常见的场景是用基本流(Basic Flow)来描述的，其他的场景则是用备选流(Alternative Flow)来描述。对于ATM系统中的"提款"用例，我们可以得到如下一些备选流：

提款-备选事件流

备选流一：用户可以在基本流中的任何一步选择退出，转至基本流步骤5。

备选流二：在基本流步骤1中，用户插入无效信用卡，系统显示错误并退出信用卡，用例结束。

备选流三：在基本流步骤２中，用户输入错误密码，系统显示错误并提示用户重新输入密码，重新回到基本流步骤2；三次输入密码错误后，信用卡被系统没收，用例结束。

…

通过基本流与备选流的组合，就可以将用例所有可能发生的各种场景全部描述清楚。我们在描述用例的事件流的时候，就是要尽可能地将所有可能的场景都描述出来，以保证需求的完备性。

1.3 用例方法的优点

用例方法完全是站在用户的角度上（从系统的外部）来描述系统的功能的。在用例方法中，我们把被定义系统看作是一个黑箱，我们并不关心系统内部是如何完成它所提供的功能的。用例方法首先描述了被定义系统有哪些外部使用者（抽象成为Actor），这些使用者与被定义系统发生交互；针对每一参与者，用例方法又描述了系统为这些参与者提供了什么样的服务（抽象成为Use Case），或者说系统是如何被这些参与者使用的。所以从用例图中，我们可以得到对于被定义系统的一个总体印象。

与传统的功能分解方式相比，用例方法完全是从外部来定义系统的功能，它把需求与设计完全分离开来。在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求，系统的设计主要由对象模型来记录表述。另外，用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务。用例方法比传统的SRS更易于被用户所理解，它可以作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。

在RUP中，用例被作为整个软件开发流程的基础，很多类型的开发活动都把用例作为一个主要的输入工件(Artifact)，如项目管理、分析设计、测试等。根据用例来对目标系统进行测试，可以根据用例中所描述的环境和上下文来完整地测试一个系统服务，可以根据用例的各个场景(Scenario)来设计测试用例，完全地测试用例的各种场景可以保证测试的完备性。

回页首

2. 建立用例模型

使用用例的方法来描述系统的功能需求的过程就是用例建模，用例模型主要包括以下两部分内容：

• 用例图(Use Case Diagram)
  确定系统中所包含的参与者、用例和两者之间的对应关系，用例图描述的是关于系统功能的一个概述。
• 用例规约(Use Case Specification)
  针对每一个用例都应该有一个用例规约文档与之相对应，该文档描述用例的细节内容。

在用例建模的过程中，我们建议的步聚是先找出参与者，再根据参与者确定每个参与者相关的用例，最后再细化每一个用例的用例规约。

2.1 寻找参与者

所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。通俗地讲，参与者就是我们所要定义系统的使用者。寻找参与者可以从以下问题入手：

• 系统开发完成之后，有哪些人会使用这个系统？
• 系统需要从哪些人或其他系统中获得数据？
• 系统会为哪些人或其他系统提供数据？
• 系统会与哪些其他系统相关联？
• 系统是由谁来维护和管理的？

这些问题有助于我们抽象出系统的参与者。对于ATM机的例子，回答这些问题可以使我们找到更多的参与者：操作员负责维护和管理ATM机系统、ATM机也需要与后台服务器进行通讯以获得有关用户帐号的相关信息。

2.1.1 系统边界决定了参与者

参与者是由系统的边界所决定的，如果我们所要定义的系统边界仅限于ATM机本身，那么后台服务器就是一个外部的系统，可以抽象为一个参与者。

如果我们所要定义的系统边界扩大至整个银行系统，ATM机和后台服务器都是整个银行系统的一部分，这时候后台服务器就不再被抽象成为一个参与者。

值得注意的是，用例建模时不要将一些系统的组成结构作为参与者来进行抽象，如在ATM机系统中，打印机只是系统的一个组成部分，不应将它抽象成一个独立的参与者；在一个MIS管理系统中，数据库系统往往只作为系统的一个组成部分，一般不将其单独抽象成一个参与者。

2.1.2 特殊的参与者――系统时钟

有时候我们需要在系统内部定时地执行一些操作，如检测系统资源使用情况、定期地生成统计报表等等。从表面上看，这些操作并不是由外部的人或系统触发的，应该怎样用用例方法来表述这一类功能需求呢？对于这种情况，我们可以抽象出一个系统时钟或定时器参与者，利用该参与者来触发这一类定时操作。从逻辑上，这一参与者应该被理解成是系统外部的，由它来触发系统所提供的用例对话。

2.2 确定用例

找到参与者之后，我们就可以根据参与者来确定系统的用例，主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的。寻找用例可以从以下问题入手（针对每一个参与者）：

• 参与者为什么要使用该系统？
• 参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？
• 参与者是否会将外部的某些事件通知给该系统？
• 系统是否会将内部的某些事件通知该参与者？

综合以上所述，ATM系统的用例图可表示如下，

在用例的抽取过程中，必须注意：用例必须是由某一个主角触发而产生的活动，即每个用例至少应该涉及一个主角。如果存在与主角不进行交互的用例，就可以考虑将其并入其他用例；或者是检查该用例相对应的参与者是否被遗漏，如果是，则补上该参与者。反之，每个参与者也必须至少涉及到一个用例，如果发现有不与任何用例相关联的参与者存在，就应该考虑该参与者是如何与系统发生对话的，或者由参与者确定一个新的用例，或者该参与者是一个多余的模型元素，应该将其删除。

可视化建模的主要目的之一就是要增强团队的沟通，用例模型必须是易于理解的。用例建模往往是一个团队开发的过程，系统分析员在建模过程中必须注意参与者和用例的名称应该符合一定的命名约定，这样整个用例模型才能够符合一定的风格。如参与者的名称一般都是名词，用例名称一般都是动宾词组等。

对于同一个系统，不同的人对于参与者和用例都可能有不同的抽象结果，因而得到不同的用例模型。我们需要在多个用例模型方案中选择一种"最佳"（或"较佳"）的结果，一个好的用例模型应该能够容易被不同的涉众所理解，并且不同的涉众对于同一用例模型的理解应该是一致的。

2.3 描述用例规约

应该避免这样一种误解――认为由参与者和用例构成的用例图就是用例模型，用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有一个总体的认识。除此之外，我们还需要描述每一个有例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每一个用例的详细描述――用例规约所组成的。RUP中提供了用例规约的模板，每一个用例的用例规约都应该包含以下内容：

• 简要说明 (Brief Description)
  简要介绍该用例的作用和目的。
• 事件流 (Flow of Event)
  包括基本流和备选流，事件流应该表示出所有的场景。
• 用例场景 (Use-Case Scenario)
  包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。
• 特殊需求 (Special Requirement)
  描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。
• 前置条件 (Pre-Condition)
  执行用例之前系统必须所处的状态。
• 后置条件 (Post-Condition)
  用例执行完毕后系统可能处于的一组状态。

用例规约基本上是用文本方式来表述的，为了更加清晰地描述事件流，也可以选择使用状态图、活动图或序列图来辅助说明。只要有助于表达的简洁明了，就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。如活动图有助于描述复杂的决策流程，状态转移图有助于描述与状态相关的系统行为，序列图适合于描述基于时间顺序的消息传递。

2.3.1 基本流

基本流描述的是该用例最正常的一种场景，在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。我们建议用以下格式来描述基本流：

1) 每一个步骤都需要用数字编号以清楚地标明步骤的先后顺序。

2) 用一句简短的标题来概括每一步骤的主要内容，这样阅读者可以通过浏览标题来快速地了解用例的主要步骤。在用例建模的早期，我们也只需要描述到事件流步骤标题这一层，以免过早地陷入到用例描述的细节中去。

3) 当整个用例模型基本稳定之后，我们再针对每一步骤详细描述参与者和系统之间所发生的交互。建议采用双向(roundtrip)描述法来保证描述的完整性，即每一步骤都需要从正反两个方面来描述:(1)参与者向系统提交了什么信息；(2)对此系统有什么样的响应。具体例子请参见附录。

在描述参与者和系统之间的信息交换时，需指出来回传递的具体信息。例如，只表述参与者输入了客户信息就不够明确，最好明确地说参与者输入了客户姓名和地址。通常可以利用词汇表让用例的复杂性保持在可控范围内，可以在词汇表中定义客户信息等内容，使用例不至于陷入过多的细节。

2.3.2 备选流

备选流负责描述用例执行过程中异常的或偶尔发生的一些情况，备选流和基本流的组合应该能够覆盖该用例所有可能发生的场景。在描述备选流时，应该包括以下几个要素：

1) 起点：该备选流从事件流的哪一步开始；

2) 条件：在什么条件下会触发该备选流；

3) 动作：系统在该备选流下会采取哪些动作；

4) 恢复：该备选流结束之后，该用例应如何继续执行。

备选流的描述格式可以与基本流的格式一致，也需要编号并以标题概述其内容，编号前可以加以字母前缀A(Alternative)以示与基本流步骤相区别。

2.3.3 用例场景

用例在实际执行的时候会有很多的不同情况发生，称之为用例场景；也可以说场景是用例的实例，我们在描述用例的时候要覆盖所有的用例场景，否则就有可能导致需求的遗漏。在用例规约中，场景的描述可以由基本流和备选流的组合来表示。场景既可以帮助我们防止需求的遗漏，同时也可以对后续的开发工作起到很大的帮助：开发人员必须实现所有的场景、测试人员可以根据用例场景来设计测试用例。

2.3.4 特殊需求

特殊需求通常是非功能性需求，它为一个用例所专有，但不适合在用例的事件流文本中进行说明。特殊需求的例子包括法律或法规方面的需求、应用程序标准和所构建系统的质量属性（包括可用性、可靠性、性能或支持性需求等）。此外，其他一些设计约束，如操作系统及环境、兼容性需求等，也可以在此节中记录。

需要注意的是，这里记录的是专属于该用例的特殊需求；对于一些全局的非功能性需求和设计约束，它们并不是该用例所专有的，应把它们记录在《补充规约》中。

2.3.5 前置和后置条件

前置条件是执行用例之前必须存在的系统状态，后置条件是用例一执行完毕后系统可能处于的一组状态。

2.4 检查用例模型

用例模型完成之后，可以对用例模型进行检查，看看是否有遗漏或错误之处。主要可以从以下几个方面来进行检查：

• 功能需求的完备性
  现有的用例模型是否完整地描述了系统功能，这也是我们判断用例建模工作是否结束的标志。如果发现还有系统功能没有被记录在现有的用例模型中，那么我们就需要抽象一些新的用例来记录这些需求，或是将他们归纳在一些现有的用例之中。
• 模型是否易于理解
  用例模型最大的优点就在于它应该易于被不同的涉众所理解，因而用例建模最主要的指导原则就是它的可理解性。用例的粒度、个数以及模型元素之间的关系复杂程度都应该由该指导原则决定。
• 是否存在不一致性
  系统的用例模型是由多个系统分析员协同完成的，模型本身也是由多个工件所组成的，所以我们要特别注意不同工件之前是否存在前后矛盾或冲突的地方，避免在模型内部产生不一致性。不一致性会直接影响到需求定义的准确性。
• 避免二义性语义
  好的需求定义应该是无二义性的，即不同的人对于同一需求的理解应该是一致的。在用例规约的描述中，应该避免定义含义模糊的需求，即无二义性。

回页首

3. 系统需求

RUP中根据FURPS+模型将系统需求分为以下几类：

• 功能(Functionality)
• 可用性(Usability)
• 可靠性(Reliability)
• 性能(Performance)
• 可支持性(Supportability)
• 设计约束等

除了第一项功能性需求之外的其他需求都归之为非功能性需求。

3.1 需求工件集

用例模型主要用于描述系统的功能性需求，对于其他的非功能性需要用其他文档来记录。RUP中定义了如下的需求工件集合。

• 用例模型：记录功能性需求
  • 用例图：描述参与者和用例之间的关系
  • 用例规约：描述每一个用例的细节信息
• 补充规约：记录一些全局性的功能需求、非功能性需求和设计约束等
• 词汇表：记录一些系统需求相关的术语

在实际应用中，除了这些工件之外，我们还可以根据实际需求灵活选用其他形式的文档来补充说明需求。并不是所有的系统需求都适保合用用例模型来描述的，如编译器，我们很难用用例方法来表述它所处理的语言的方法规则，在这种情况下，采用传统的BNF范式来表述更加合适一些。在电信软件行业中，很多电信标准都是采用SDL语言来描述的，我们也不必用UML来改写这些标准（UML对SDL存在着这样的兼容性），只需将SDL形式的电信标准作为需求工件之一，在其他工件中对其加以引用就可以了。总之，万万不可拘泥于用例建模的形式，应灵活运用各种方式的长处。

3.2 补充规约

补充规约记录那些在用例模型中不易表述的系统需求，主要包括以下内容。

• 功能性
  功能性需求主要在用例模型中刻画，但是也有部分需求不适合在用例中表述。有些功能性需求是全局性的，适用于所有的用例，如出错处理、I18N支持等，我们不需要在所有的用例中描述这些功能性需求，只需要在补充规约中统一描述就可以了。
• 可用性
  记录所有可用性相关的需求，如系统的使用者所需要的培训时间、是否应附合一些常见的可用性标准如Windows界面风格等。
• 可靠性
  定义系统可靠性相关的各种指标，包括：
  
  • 可用性：指出可用时间百分比(xx.xx%)，系统处于使用、维护、降级模式等操作的小时数；
  • 平均故障间隔时间(MTBF)：通常表示为小时数，但也可表示为天数、月数或年数；
  • 平均修复时间(MTTR)：系统在发生故障后可以暂停运行的时间；
  • 精确度：指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）；
  • 最高错误或缺陷率：通常表示为bugs/KLOC（每千行代码的错误数目）或bugs/function-point（每个功能点的错误数目）。
• 性能
  记录系统性能相关的各种指标，包括：
  
  • 对事务的响应时间（平均、最长）；
  • 吞吐量（例如每秒处理的事务数）；
  • 容量（例如系统可以容纳的客户或事务数）；
  • 降级模式（当系统以某种形式降级时可接受的运行模式）；
  • 资源利用情况：内存、磁盘、通信等。
• 可支持性
  定义所有与系统的可支持性或可维护性相关的需求，其中包括编码标准、命名约定、类库、如何来对系统进行维护操作和相应的维护实用工具等。
• 设计约束
  设计约束代表已经批准并必须遵循的设计决定，其中包括软件开发流程、开发工具、系统构架、编程语言、第三方构件类库、运行平台和数据库系统等等。

3.3 词汇表

词汇表主要用于定义项目特定的术语，它有助于开发人员对项目中所用的术语有统一的理解和使用，它也是后续阶段中进行对象抽象的基础。

回页首

4. 调整用例模型

在一般的用例图中，我们只表述参与者和用例之间的关系，即它们之间的通讯关联。除此之外，我们还可以描述参与者与参与者之间的泛化(generalization)、用例和用例之间的包含(include)、扩展(extend)和泛化(generalization)关系。我们利用这些关系来调整已有的用例模型，把一些公共的信息抽取出来重用，使得用例模型更易于维护。但是在应用中要小心选用这些关系，一般来说这些关系都会增加用例和关系的个数，从而增加用例模型的复杂度。而且一般都是在用例模型完成之后才对用例模型进行调整，所以在用例建模的初期不必要急于抽象用例之间的关系。

4.1 参与者之间的关系

参与者之间可以有泛化(Generalization)关系（或称为"继承"关系）。例如在需求分析中常见的权限控制问题（如下图所示），一般的用户只可以使用一些常规的操作，而管理员除了常规操作之外还需要进行一些系统管理工作，操作员既可以进行常规操作又可以进行一些配置操作。

在这个例子中我们会发现管理员和操作员都是一种特殊的用户，他们拥有普通用户所拥有的全部权限，此外他们还有自己独有的权限。这里我们可进一步把普通用户和管理员、操作员之间的关系抽象成泛化(Generalization)关系，管理员和操作员可以继承普通用户的全部特性（包括权限），他们又可以有自己独有的特性（如操作、权限等）。这样可以显著减速少用例图中通讯关联的个数，简化用例模型，使之更易于理解。

4.2 用例之间的关系

用例描述的是系统外部可见的行为，是系统为某一个或几个参与者提供的一段完整的服务。从原则上来讲，用例之间都是并列的，它们之间并不存在着包含从属关系。但是从保证用例模型的可维护性和一致性角度来看，我们可以在用例之间抽象出包含(include)、扩展(extend)和泛化(generalization)这几种关系。这几种关系都是从现有的用例中抽取出公共的那部分信息，然后通后过不同的方法来重用这部公共信息，以减少模型维护的工作量。

4.2.1 包含(include)

包含关系是通过在关联关系上应用<<include>>构造型来表示的，如下图所示。它所表示的语义是指基础用例(Base)会用到被包含用例(Inclusion)，具体地讲，就是将被包含用例的事件流插入到基础用例的事件流中。

包含关系是UML1.3中的表述，在UML1.1中，同等语义的关系被表述为使用(uses)，如下图。

在ATM机中，如果查询、取现、转帐这三个用例都需要打印一个回执给客户，我们就可以把打印回执这一部分内容提取出来，抽象成为一个单独的用例"打印回执"，而原有的查询、取现、转帐三个例都会包含这个用例。每当以后要对打印回执部分的需求进行修改时，就只需要改动一个用例，而不用在每一个用例都作相应修改，这样就提高了用例模型的可维护性。

在基础用例的事件流中，我们只需要引用被包含用例即可。

查询-基本事件流

1. 用户插入信用卡

2. 输入密码

3. 选择查询

4. 查看帐号余额

5. 包含用例"打印回执"

6. 退出系统，取回信用卡

在这个例子中，多个用例需要用到同一段行为，我们可以把这段共同的行为单独抽象成为一个用例，然后让其他的用例来包含这一用例。从而避免在多个用例中重复性地描述同一段行为，也可以防止该段行为在多个用例中的描述出现不一致性。当需要修改这段公共的需求时，我们也只需要修改一个用例，避免同时修改多个用例而产生的不一致性和重复性工作。

有时当某一个用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

4.2.2 扩展(extend)

扩展（extend）关系如下图所示，基础用例(Base)中定义有一至多个已命名的扩展点，扩展关系是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例(Base)中。对于包含关系而言，子用例中的事件流是一定插入到基础用例中去的，并且插入点只有一个。而扩展关系可以根据一定的条件来决定是否将扩展用例的事件流插入基础用例事件流，并且插入点可以有多个。

例如对于电话业务，可以在基本通话(Call)业务上扩展出一些增值业务如：呼叫等待(Call Waiting)和呼叫转移(Call Transfer)。我们可以用扩展关系将这些业务的用例模型描述如下。

在这个例子中，呼叫等待和呼叫转移都是对基本通话用例的扩展，但是这两个用例只有在一定的条件下（如应答方正忙或应答方无应答）才会将被扩展用例的事件流嵌入基本通话用例的扩展点，并重用基本通话用例中的事件流。

值得注意的是扩展用例的事件流往往可以也可抽象为基础用例的备选流，如上例中的呼叫等待和呼叫转移都可以作为基本通话用例的备选流而存在。但是基本通话用例已经是一个很复杂的用例了，选用扩展关系将增值业务抽象成为单独的用例可以避免基础用例过于复杂，并且把一些可选的操作独立封装在另外的用例中。

4.2.3 泛化(generalization)

当多个用例共同拥有一种类似的结构和行为的时候，我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。

以下是一个用例泛化关系的例子，执行交易是一种交易抽象，执行房产交易和执行证券交易都是一种特殊的交易形式。

用例泛化关系中的事件流示例如下：

4.3 调整用例模型

用例模型建成之后，我们可以对用例模型进行检视，看是否可以进一步简化用例模型、提高重用程度、增加模型的可维护性。主要可以从以下检查点(checkpoints)入手:

• 用例之间是否相互独立？如果两个用例总是以同样的顺序被激活，可能需要将它们合并为一个用例。
• 多个用例之间是否有非常相似的行为或事件流？如果有，可以考虑将它们合并为一个用例。
• 用例事件流的一部分是否已被构建为另一个用例？如果是，可以让该用例包含(include)另一用例。
• 是否应该将一个用例的事件流插入另一个用例的事件流中？如果是，利用与另一个用例的扩展关系(extend)来建立此模型。

回页首

5. 管理用例模型复杂度

一般小型的系统，其用例模型中包含的参与者和用例不会太多，一个用例图就可以容纳所有的参与者，所有的参与者和用例也可以并存于同一个层次结构中。对于较复杂的大中型系统，用例模型中的参与者和用例会大大增加，我们需要一些方法来有效地管理由于规模上升而造成的复杂度。

5.1 用例包

包(Package)是UML中最常用的管理模型复杂度的机制，包也是UML中语义最简单的一种模型元素，它就是一种容器，在包中可以容纳其他任意的模型元素（包括其他的包）。在用例模型中，我们可以用构造型(Sterotype)<<use case>>来扩展标准UML包的语义，这种新的包叫作用例包(Use Case Package)，用于分类管理用例模型中的模型元素。

我们可以根据参与者和用例的特性来对它们进行分类，分别置于不同的用例包管理之下。例如对于一个大型的企业管理信息系统，我们可以根据参与者和用例的内容将它们分别归于人力资源、财务、采购、销售、客务服务这些用例包之下。这样我们将整个用例模型划分成为两个层次，在第一层次我们看到的是系统功能总共分为五部分，在第二层次我们可以分别看到每一用例包内部的参与者和用例。

一个用例模型需要有多少个用例包取决你想怎么样来管理用例模型的复杂度（包括参与者和用例的个数，以及它们之间的相互关系）。UML中的包其实就类似于文件系统中的目录，文件数量少的时候不需要额外的目录，文件数量一多就需要有多个目录来分类管理，同样一组文件不同的人会创建不同的目录结构来进行管理，关键是要保证在目录结构下每一个文件都要易于访问。同样的道理存在于用例建模之中，如何创建用例包以及用例包的个数取决于不同的系统和系统分析员，但要保证整个用例模型易于理解。

5.2 用例的粒度

我的系统需要有多少个用例？这是很多人在用例建模时会产生的疑惑。描述同一个系统，不同的人会产生不同的用例模型。例如对于各种系统中常见的"维护用户"用例，它里面包含了添加用户、修改用户信息、删除用户等操作，这些操作在该用例的事件流可以表述成为基本流的子事件流(subflow)。

维护用户-基本事件流

该基本流由三个子事件流构成：

1) 添加用户子事件流
…

2) 修改用户 子事件流
…

3) 删除用户子事件流
…

但是你也可以根据该用例中的具体操作把它抽象成为三个用例，它所表示的系统需求和单个用例的模型是完全一样的。

应该如何确定用例的粒度呢？在一次技术研讨会上，有人问起Ivar Jacoboson博士，一个系统需要有多少个用例？大师的回答是20个，当然他的意思是最好将用例模型的规模控制在几十个用例左右，这样比较容易来管理用例模型的复杂度。在用例个数大致确定的条件下，我们就很容易来确定用例粒度的大小。对于较复杂的系统，我们需要控制用例模型一级的复杂度，所以可以将复杂度适当地移往每一个用例的内部，也就是让一个用例包含较多的需求信息量。对于比较简单的系统，我们则可以将复杂度适度地曝露在模型一级，也就是我们可以将较复杂的用例分解成为多个用例。

用例的粒度不但决定了用例模型级的复杂度，而且也决定了每一个用例内部的复杂度。我们应该根据每个系统的具体情况，因时因宜地来把握各个层次的复杂度，在尽可能保证整个用例模型的易理解性前提下决定用例的大小和数目。

5.3 用例图

用例图的主要作用是描述参与者和用例之间的关系，简单的系统中只需要有一个用例图就可以把所有的关系都描述清楚。复杂的系统中可以有多个用例图，例如每个用例包都可以有一个独立的用例图来描述该用例包中所有的参与者和用例的关系。

在一个用例模型中，如果参与者和用例之间存在着多对多的关系，并且他们之间的关系比较复杂，如果在同一个用例图中表述所有的参与者和用例就显得不够清晰，这时我们可创建多个用例图来分别表示各种关系。

如果想要强调某一个参与者和多个用例的关系，你就可以以该参与者为中心，用一个用例图表述出该参与者和多个用例之间的关系。在这个用例图中，我们强调的是该参与者会使用系统所提供的哪些服务。

如果想要强调某一个用例和多个参与者之间的关系，你就可以以该用例为中心，用一个用例图表述出该用例和多个参与者之间的关系。在这个用例图中，我们强调的是该用例会涉及到哪些参与者，或者说该用例所表示的系统服务有哪些使用者。

总之在用例建模过程中，你可以根据自己的需要创建任意多个用例图，用不同的用例来强调参与者和用例之间不同的关系。但是最重要的是要考虑整个用例模型的可理解性，如果可以用一个用例图把意思表述清楚，就不要再用第二个，因为越是简洁的模型越易于理解。

参考资料

• 样例代码
  
  
  
  
• Jeffrey Friedl, Mastering Regular Expressions, O'Reilly
  
  
• Mendel Cooper, Advanced Bash-Scripting Guide
  
  
• Michael Jang, Mastering Redhat 9
  

关于作者

		傅纯一，IBM中国有限公司软件部Rational中国区技术销售经理

一、安装JDK
首先下载JDK 5.0 Update7（JDK 5.0 Update7的下载页面为：
http://java.sun.com/javase/downloads/index.jsp）；
然后运行JDK 5.0安装程序jdk-1_5_0_07-windows-i586-p.exe，安装过程中所有选项保持默认；
最后配置JDK的环境变量：在“我的电脑”上点右键—>“属性”—>“高级”—> “环境变量(N)”。

新建系统变量JAVA_HOME：C:\Program Files\Java\jdk1.5.0_06
新建系统变量CLASSPATH：.;%JAVA_HOME%\lib;（注意：点号表示当前目录，不能省略）
在系统变量Path的值的前面加入以下内容：%JAVA_HOME%\bin;(注意:这里的分号不能省略)
到这里，JDK安装完毕。
下面我们测试一下JDK是否安装成功：
将以下内容复制到记事本中：
public class HelloJAVA
{
public static void main(String srg[])
{
System.out.println("Hello JAVA!");
}
}
另存为“HelloJAVA.java”（不含引号，下同），并保存到D盘根目录下。
在命令行依次输入下图中红线所标注的命令：

如果出现上图红框中所标注的内容，则说明JDK安装成功！

注意:如果以后要安装诸如Eclipse、Borland JBuilder、JCreator、IntelliJ IDEA等集成开发环境(IDE,Integrated Development Environment),应该在IDE中编译运行一个简单的HelloWorld程序，以保证IDE可以识别出JDK的位置。

二、安装Tomcat
首先下载jakarta-tomcat-5.0.30.zip，之所以下载免安装版的好处是可以使用多个Tomcat（jakarta-tomcat-5.0.30.zip的下载页面为：
http://apache.linuxforum.net/tomcat/tomcat-5/v5.0.30/bin/）；
然后将jakarta-tomcat-5.0.30.zip直接解压到D盘根目录：

最后配置Tomcat的环境变量：在“我的电脑”上点右键—>“属性”—>“高级”—> “环境变量(N)”。
新建系统变量CATALINA_HOME：D:\jakarta-tomcat-5.0.30
在系统变量CLASSPATH的值的后面加入：%CATALINA_HOME%\common\lib;
在系统变量Path的值中"%JAVA_HOME%\bin;"的后面加入以下内容：%CATALINA_HOME%\bin;

到这里，Tomcat安装完毕。

相关链接：
Tomcat 4和Tomcat 5安装配置指南
Tomcat 5.5安装配置指南

进行完一、二两步的设置以后，各系统变量的值如下：

JAVA_HOME:C:\Program Files\Java\jdk1.5.0_06
CATALINA_HOME:D:\jakarta-tomcat-5.0.30
CLASSPATH:.;%JAVA_HOME%\lib;%CATALINA_HOME%\common\lib;
Path:%JAVA_HOME%\bin;%CATALINA_HOME%\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem

三、安装Eclipse
首先下载eclipse-SDK-3.1.2-win32.zip（eclipse-SDK-3.1.2-win32.zip下载地址为：
http://www.eclipse.org/downloads/）；
然后将eclipse-SDK-3.1.2-win32.zip直接解压到D盘根目录：

到这里， Eclipse安装完毕。

四、安装MyEclipse
首先下载EnterpriseWorkbenchInstaller_4.1.1GA_E3.1.exe（EnterpriseWorkbenchInstaller_4.1.1GA_E3.1.exe 的下载地址为：
http://www.myeclipseide.com/ContentExpress-display-ceid-10.html）；
然后安装EnterpriseWorkbenchInstaller_4.1.1GA_E3.1.exe。注意：当安装到下图所示的步骤的时候要选择Eclipse的安装路径（如图），其他选项保持默认。

安装完毕之后，将MyEclipse安装目录下的features和plugins这2个目录覆盖到Eclipse的安装目录下。
最后将刚才安装的 MyEclipse 卸载。
解释一下上面这样做的原因： 因为MyEclipse是Eclipse的插件，所以只要把features和plugins这2个目录覆盖到Eclipse的安装目录，Eclipse就会自动认出这些插件。
到这里，MyEclipse安装完毕。

五、破解MyEclipse
运行MyEclipse4.1.1注册机MyEclipseKeyGen.exe，选择MyEclipse的版本号，输入注册名，生成序列号。（MyEclipse4.x注册机的下载地址为：
http://esoft.g8.com.cn/UploadFiles/2006-5/520753587.rar）
运行eclipse.exe（首次运行要求指定Workspace），依次点击Window ----> Preferences ---->MyEclipse---->Subscription ----> Enter Subscription，输入注册名以及注册机生成的注册码。
到这里，MyEclipse破解完毕。

六、指定Eclipse+MyEclipse的JRE 和Tomcat 服务器
1.设定Eclipse+MyEclipse的JRE
一般情况下，Eclipse可以自动找到JRE，我们不用进行过多的设置。
2.设定Eclipse+MyEclipse的Tomcat 服务器
只需设置图中所标注的两处即可，图中其余部分是自动生成的。

到这里，我们的Eclipse+MyEclipse开发环境就搭建完毕了！

七、新建一个项目来测试一下Eclipse+MyEclipse开发环境是否搭建成功
1.在Eclipse中依次点击“ File ----> New ----> Project” , 在弹出的“New Project”对话框中依次点击“Web Project ---->MyEclipse---->J2EE Projects---->Web Project”， 再点“Next”，在“Project Name”中输入项目的名字“test”,最后点“Finish”。
2.在Eclipse左边Package Explorer列表中点击“test”，将项目test展开。右键点击 WebRoot ----> New ----> JSP , 新建一个名为hello.jsp的 JSP 页面 。 代码如下图（图中标注部分需要我们手动添加，其余部分是系统自动生成的）：

3. 再用同样的方法， 新建一个叫 hello_result.jsp 的JSP文件， 代码如下图：

4. deploy（部署）项目。
点击 deploy 按钮（用红线画了的按钮就是 deploy 按钮）， 在弹出的窗口中点击Add， 部署test项目（如图所示）。

5. 启动Tomcat服务器。
如下图所示（用红线画了的按钮就是 启动Tomcat 的按钮）：

Tomcat 启动输出信息如下图：

6.项目test的运行结果：

我们可以去Eclipse的Workspace目录下看看test项目的代码，也可以去Tomcat的webapps目录下，看看部署之后的 test项目的结构。

一个完善的项目管理体系建设是与企业本身的行业背景、业务领域是分不开的，出现上面的问题的根本原因就在于项目管理和业务流程的交叉，导致项目管理过程复杂化，不可控，这也就是为什么大家说一套方法不可以适用所有的项目的根本原因。

企业的项目运作包括业务流程、项目管理、技术工作三个方面，业务流程是如何运作业务，是由企业的行业特点、业务背景所决定，项目管理是如何管理项目，而技术工作则是实现项目目标所需要的技术手段。对于一个企业而言，建立企业的项目管理方法论就需要依照企业的业务流程、技术手段来设计相应的管理方法。

项目管理方法是一个结构化的方法，是可以在大部分项目中应用的方法，具体实践过程中，项目管理方法需要针对行业特点，建立适合行业特色的项目管理体系。

依照项目管理理论，项目管理过程按阶段划分为启动、计划、实施、收尾，对于任何一个项目我们都可以依此进行阶段的划分，这是项目的共性，而对于项目中的个性就是项目的业务和技术层面，对于具体的企业，项目阶段划分就需要由业务流程和技术方法决定，在实施过程中，针对具体的项目进行客户化，项目管理方法论的核心就是综合所有项目的特点，建立一套包括技术、工具、管理技巧在内的一站式服务的指南和模板。这种将项目管理方法和业务流程相互配合，并在实践中进行优化的管理方法，就是项目管理方法论。

         项目管理体方法论的重要表现形式是项目管理手册，这是组织规范项目标准管理过程的重要手段，通过正确的决策、高效的流程、标准的操作、可控的过程，确保项目的有效实施。

企业项目管理手册编制的基本方法可分为三个层面，一是项目管理理论知识体系，目前世界范围内比较通用的主流项目管理知识体系，包括美国项目管理协会（PMI）推出的《项目管理知识体系指南PMBOK》，英国商务部开发的项目管理方法《PRINCE2成功的项目管理》可作为理论支撑。二是在管理方法上跨国企业实施项目的管理方法，中国著名企业的项目管理经验可作为最佳实践基础，在此基础上则是对企业本身项目管理实践经验的总结。从三个层面对企业的项目管理过程进行梳理、定义、借鉴，即可固化出企业本身的项目管理方法。

具体到项目管理手册内容就是描述项目输入转变为输出的过程。通过项目阶段过程的定义，将项目管理过程、项目实施支撑、项目监控方法及项目作业指导，系统化地与项目管理理论及产品要求融入到具体的操作实践过程中。具体包括以下主要内容：
　　1. 项目过程控制阶段划分：通常需要考虑两类过程，一是按照项目的管理过程，对项目过程进行阶段划分；另外是按照项目的技术过程，将项目过程进行阶段划分。企业的业务流程，主要关注项目的管理阶段划分，而项目经理执行和管理项目时，必须将项目的管理阶段和项目的技术阶段划分结合起来，进行项目管理。
　　2. 阶段输入和输出：包括数据和信息、计划和报告、风险及可以交付的成果等；
　　3. 过程控制：包括工作流程，工作方法、操作规则和作业指导；
　　4. 角色职责：在实践中，项目管理职责，不能简单归于项目经理一个人，而是由一组角色共同完成，包括职能部门和角色对项目阶段和实施步骤的贡献。
　　依照项目管理方法论编制的项目管理手册，将项目实施过程中的项目管理方法与企业的业务流程、技术方法有机地集成起来，从而建立以项目管理为核心的业务流程。

      “要马儿好，又要马儿不吃草”这句话不知是谁“发明”的；发明这句话的人，想来是项目管理的高手。为什么？因为项目管理的精义，就是“又要马儿好，又要马儿不吃草。” 一个成功的项目，通常有三个要素：

            时间的要素──完成的时间要“快”
            成本的要素──完成的成本要“便宜”
            效果的要素──完成后的表现要“好”

       这三个彼此互斥的要素，就像一个等边三角形的三边一样，缺了一边，或任何一边比其它两面边短，我们就不能再称这个三角形为等边三角形了。在我的经验中，如果在这三个要素中袛要做到一项的话，这种专案好做，百分之八、九十以上的项目经理大概都可以胜任愉快。如果在三个要素中要做到两项，就不是一般的项目经理能胜任的了。在比率上，我认为能把以上三个要素中的任何两项做到的项目经理，大概不会超过百分之五十。真正能够把项目中三个主要需求都能做到的高手，在一百位项目经理中，最多不到十个。 有人听我这么说也许会不服气，认为我在这里危言耸听，乱吓唬人。他们不了解我的本意。我的本意祗有两点：

            第一、项目成功的要素，彼此之间是鱼与熊掌的关系。
            第二、要兼顾的难度，是照几何级数上升而不是按算术级数上升。
           

       这样一个三角难题，要我们怎么去解呢？我如果是个项目经理，一定要问：
            。什么是“好”？
            。什么是“快”？
            。什么是“便宜”？

       “好”字咱们中国人用来真是千变万化，神奇不已。有时用来作副词，像说：这颜色“好”漂亮。有时用来做动词；说那个家伙很“好”色，可不是什么恭维之词。“好”字用到恰处，又变成了另外意思的代名词了。别人问：“这个女孩子怎么样？”你说：“她很好”，言下之意，就是不很漂亮。别人问：“这个人怎么样？”，你回答：“他很好”，言下之意，就是他不太能干。同时，某一个人认为好的，另外一个并不认为好，这是我们日常生活中常遭遇到的问题。 在项目管理中，好就是好，不好就是不好，这没有什么主观或客观的差异，也没有什么明示或暗示的问题存在。要谈到项目管理中“好”的定义，第一个条件就是要看它是不是有用。“有用”和“能用”是两回事。很多“能用的”东西不一定“有用”，这牵涉到客观价值的问题。有一天，我在台北的街上看到一个年轻人开了一部德国制的跑车，车尾上还有一块压风板的那型。我心想，在台北这种交通堵塞、寸步难行的情况下，开这种跑车真是龙游浅水，英雄无用武之地。这部跑车算不算是部好车呢？当然算。但在台北街头这种客观环境之下，它还算不算是部好车？当然不算。 我从前有一只瑞士制的名表，是属于那种很贵，很多仿制品那型。因为要动，它才会上炼，不动它，隔一阵就停了。我后来不胜其烦，换了一个日本制的石英表，价钱祗有那只瑞士表的几十分之一，不但不用上炼，并且有两个时间，能让我不用花脑筋就可以同时知道台湾和美国加州的时间。早上六点它会把我闹醒，打球、洗澡也懒得把它脱掉，并且是夜明的。你说这两个表那个比较好？我可以很坦白地告诉你，因为后者比较有用，后者比较好。因此，在项目管理上，关于“好”的定义，是“有用”而非“能用”。

      “好”的第二个条件，要看它是不是能达到原先要达到的目的。如果说目的是代步，汽车比脚踏车好；如果说目的是运动，脚踏车却比汽车好。在日常生活中，有人叫你去买苹果，结果你买了橘子回来。苹果和橘子虽然不是一样，但也许还勉强可以混过去。在项目管理上，如果要的是苹果，交货的时候却变成了橘子，这就不能算是一个成功的项目。为了避免这种错误，项目经理必须在项目设计时把项目结果的规格先弄清楚。口说无凭，要的东西都要写下来。交货的时候，如果我交给你的是规格上写明的东西，那我就算给你一个“好”东西。

       不管项目的成果是什么，也许是一套软件系统，或一部新的机器，或一条新修的铁路。。。。凡是好的东西，一定是容易用的东西。当录像机刚出来旳时候，懂得怎么用它去录电视节目，真是一门大学问。在我的朋友中，大多数人都不会用，尤其是太太们，十有九人不会用它。不会用、不敢用之人中，很多还都拥有博士学位哩。为什么？因为它设计得太复杂，太不容易用了。后来有两个中国工程师，想出一个办法，请每个电视台把每个节目都用一个不同的数字来代替，到时候任何人祗要把他想录节目的代号输进录像控制器中，节目时间一到，录像开始，这样一来，人人会用录像机。从项目管理“好”的定义来看，简单、好用的东西，就是“好”的东西。

       一个项目的产品，除了有用和好用之外，还要具有可塑性和可扩展的弹性。前者表示它的功能，在必要时可以加以改变。后者表示在时间上，它不但可以持久并能扩展。美国的超级公路，是艾森豪主政时的德政，在设计上，考虑到必要时可供喷射战斗机起落。扩充性比可塑性更重要。如果说一套计算机实用软件的设计，在开发完成上线不久，就不能满足公司业务上的新需要的话，设计这套系统的项目还够格称为一个好项目吗？当然，未来的需要也许不是目前能预料的，为了不可预测的将来而牺牲了现在的需要当然不对，但无论如何，一个好的项目，它所设计的产品必须具有容易修改，可以扩充，并且不会马上就失效的弹性。缺乏有这种弹性的产品，就不是一个好的产品。一个生产没有弹性产品的项目，就不能算是一个好的项目。

       但是一般所谓好的项目，究竟指的是什么呢？换句话说，怎么知道这个项目是成功的项目或失败的项目呢？你祗要问：
            项目的结果能否使公司的收入增加？
            项目的结果能否使公司的支出减少？
            项目的结果能否使公司的服务加强？
           

       能达到这三个目的，就是好的项目。

       接着，让我们来谈谈什么是“快”？在我们日常的生活中，“快”和“好”一样，往往是主观的而非客观的。有时它又是凭感觉而非凭理性的。小时候写作文，常喜欢用“光阴似箭”来破题。遇到做自己不喜欢做的事情，老喜欢用“度日如年”来形容。在项目管理上，时间是绝对的，而非凭感觉的──能在半年内完工，就是比在九个月内完工要快三个月。但这个项目能在半年内完工就算快吗？谁说的？我们搞项目管理的人常讲一个笑话：“如果你问你的老板他希望什么时候要这个项目完工，他一定会回答说：昨天。”

       因此，项目经理最容易犯的一个错误，就是在完工日期的预测上，为了讨好上司的要求而尽量乐观。同时，老是用历史的数据或别人的经验来影响自己的预测，殊不知每个项目的客观条件和外在环境都不一样。项目经理在作完工预测时，千万要记得一个教训：你的老板或客户不会记得你告诉他多快可以完工，因为再快他们都会嫌慢，但如果你告诉他们该完工的时候完不了工，那你的麻烦可大了。所以在预估时，胆子放小点，时间放长些。

       还有一点更重要：老板们当然不喜欢听坏消息，但更不喜欢听出人意外的坏消息，因此当完工的预测如果出问题的时候，绝不能隐瞒，硬着头皮也要让老板知道。  要达到预期完工的要求，项目经理一定要懂得怎么把一个规模大、时间长的项目，分成不同的阶段来完成。在每个阶段中，又要根据每阶段不同的重点分别来作完工预测。工程分得越细，预测的准确性就越高。这道理很普通，但做起来却很困难，因为需要很周详的计划和分析。计划和分析要花脑筋，可不是每个人都能做到的。说了半天，快字诀祗有一点，如果一切按照计划，这就合乎快的原则，否则就是不快。该完工时完工就是快，否则就是慢。

       至于什么是“便宜”？我以为省钱不是项目管理中最重要的目的。一个项目该花多少钱，是应该早就算出来的。一般来说，如果实际的花费和预估的花费差别在三○％左右，应该是能接受的范围；超过百分之三十，表示预算做得不彻底。 在项目管理里，最难预估的不是完工的时间，而是项目的预算。项目经理在这方面遭受的压力，比什么都大，因此，在做预算的时候，必须面对现实，既不能故意灌水，也不能故意过份乐观。 一个聪明的主管，要重视的是产品的价值，而非只是重视价钱。不懂得在价值上动脑筋，祗懂得在价钱上打算盘的项目经理，前途不乐观。但是价值有两种：有形的价值和无形的价值。在项目管理中，强调无形价值是致命伤。坦白地说，如果一个项目没有有形价值当后台，其存在的价值就很有限。在我刚才提到那三个项目的目的中，增加收入和减少支出属于有形价值，增强服务属于无形价值。有形价值高的项目，就是“便宜”的项目。否则，就是不便宜的项目。

       项目经理了解项目管理三角关系的定义之后，至少对项目追求的目标不会太迷糊。但这不能担保从此就天下太平。任何项目经理都想把他的项目管得又快、又好、又便宜，但事实上，不是每个项目都能达到这个境界，有时候，也并非一定要达到这个境界不可。 一位有经验的项目经理，一定要懂得怎么做“取舍分析”(Trade-offAnalysis)；换言之，懂得“弃车保帅”的重要性。如果我们用我提到过的“快、好、便宜”来作标准，有的时候三者可以祗取其一，或者祗取其二，这就是我们所谓的“取舍分析”。
           

        现在，让我举几个例子来说明一下，我在这方面的看法：
       

        一般来说，凡是属于研究发展的项目，尤其是有关药品方面的研究发展，钱和时间都很有弹性，但对项目产品的品质却没有任何弹性。换句话说，快、好、便宜的这个三角形，“好”的那边比什么都重要。反过来说，一般重工业机械或房屋建筑等有关项目，“快”却是最重要的因素，因为祗有在项目结束交货后，才能收款来继续以后的项目。
           

       再看有关制造环保控制机器的发展项目，由于它的订价和效果已经按法律的规定而不能再有太多弹性，但在交货的时间上，快不快并不是那么重要。相反地，所有的咨询项目，在时间和价钱上没什么弹性，但在成品的品质方面，好不好就大有融通的余地。
       

       有些项目是没有什么“弃车保帅”那套的。一九六○年代初期，美国受苏联发射史泼尼克号人造卫星的刺激，甘乃迪总统下命令要在一九六○年代结束前把人送上月球，并安全地带回来。这个庞大的专案，在时间上要快，必须赶在苏联之前完成；要好，绝不能出现任何差错；并且在预算上有限制，因为预算来自老百姓交的税，经国会通过才行。结果，美国果真抢先把人类送上月球，并平安地带回来。在历史上可以和这个项目媲美的，大概祗有造原子弹的曼哈顿项目了。
  

       我提到“弃车保帅”的观念，并不是要国内的项目经理们放弃理想，不追求项目三角关系的完美。我祗是强调一点：当这个三角难题无解的时候，要懂得顾全大局，两害相权取其轻。很多时候，由于外在和内在的压力，“取舍分析”是免不了的。要做好取舍分析，项目经理至少要懂得六件事：

            第一，要很清楚地了解项目冲突的基本原因。
            第二，重新确认项目的目的。
            第三，了解项目现处的环境及目前状况。
            第四，寻求可行的其它方法。
            第五，选择最佳的其它方法。
            第六，重新策划项目计画。

       项目的目的，不外乎增加公司收入、节省公司支出和提升公司服务水准三者。项目的成功与否，取决于项目完成是否又快又好又便宜。这个三角关系虽然难解，但并非无解。运用之妙，存乎一心。我在此文中谈到的一些技巧，有点像野人献曝，希望有些参考价值。

Java代码

1. import java.io.Serializable;   
2. public class TreeNode implements Serializable{   
3.     private String id ;          //节点编号   
4.     private String pid ;         //父节点编号   
5.     private String name ;        //节点名称   
6.     private String url ;         //链接地址   
7.     private String title ;       //节点描述   
8.     private String target ;      //Target   
9.     private String icon ;        //图标路径   
10.     private String iconOpen ;    //展开状态下的图标路径   
11.     private String open ;        //是否展开   
12.        
13.     //构造函数   
14.     public TreeNode(){   
15.         id = "" ;   
16.         pid = "" ;   
17.         name = "" ;   
18.         url = "" ;   
19.         title = "" ;   
20.         target = "" ;   
21.         icon = "" ;   
22.         iconOpen = "" ;   
23.         open = "" ;   
24.     }   
25.     //------get set functions  

import java.io.Serializable;
public class TreeNode implements Serializable{
private String id ;          //节点编号
private String pid ;         //父节点编号
private String name ;        //节点名称
private String url ;         //链接地址
private String title ;       //节点描述
private String target ;      //Target
private String icon ;        //图标路径
private String iconOpen ;    //展开状态下的图标路径
private String open ;        //是否展开
//构造函数
public TreeNode(){
id = "" ;
pid = "" ;
name = "" ;
url = "" ;
title = "" ;
target = "" ;
icon = "" ;
iconOpen = "" ;
open = "" ;
}
//------get set functions

Java代码

1. public class TreeNodeUtil {   
2.     //返回js代码   
3.     public static String createJsArray(TreeNode[] tn , String dtree) {   
4.         if(tn == null || tn.length == 0 ){   
5.             System.out.println("TreeNode is empty");   
6.             return "";   
7.         }   
8.         StringBuffer contents = new StringBuffer(100);   
9.         contents.append("new dTree('"+dtree+"');");   
10.         for (int i = 0; i < tn.length; i++) {    
11.             contents.append("\n");   
12.             contents.append(dtree+".add('");   
13.             contents.append(tn[i].getId());   
14.             contents.append("','");   
15.             contents.append(tn[i].getPid());   
16.             contents.append("','");   
17.             contents.append(tn[i].getName());   
18.             contents.append("','");   
19.             contents.append(tn[i].getUrl());   
20.             contents.append("','");   
21.             contents.append(tn[i].getTitle());   
22.             contents.append("','");   
23.             contents.append(tn[i].getTarget());   
24.             contents.append("','");   
25.             contents.append(tn[i].getIcon());   
26.             contents.append("','");   
27.             contents.append(tn[i].getIconOpen());   
28.             contents.append("','");   
29.             contents.append(tn[i].getOpen());   
30.             contents.append("');");   
31.         }   
32.         return contents.toString();   
33.     }   
34. }  

public class TreeNodeUtil {
//返回js代码
public static String createJsArray(TreeNode[] tn , String dtree) {
if(tn == null || tn.length == 0 ){
System.out.println("TreeNode is empty");
return "";
}
StringBuffer contents = new StringBuffer(100);
contents.append("new dTree('"+dtree+"');");
for (int i = 0; i < tn.length; i++) {
contents.append("\n");
contents.append(dtree+".add('");
contents.append(tn[i].getId());
contents.append("','");
contents.append(tn[i].getPid());
contents.append("','");
contents.append(tn[i].getName());
contents.append("','");
contents.append(tn[i].getUrl());
contents.append("','");
contents.append(tn[i].getTitle());
contents.append("','");
contents.append(tn[i].getTarget());
contents.append("','");
contents.append(tn[i].getIcon());
contents.append("','");
contents.append(tn[i].getIconOpen());
contents.append("','");
contents.append(tn[i].getOpen());
contents.append("');");
}
return contents.toString();
}
}

Java代码

1. public void execute() throws EpochalException {   
2.     // TODO Auto-generated method stub   
3.     String sql = "";   
4.     String url = "" ;   
5.     sql = "SELECT id,parentId,name,seq ,remark FROM t_testtree ORDER BY  seq DESC" ;   
6.     TableData tableData = null;   
7.     TreeNode[] treeNodes = null;   
8.     try{   
9.         tableData = TableSelector.select(sql);   
10.         if(tableData!=null){   
11.             treeNodes = new TreeNode[tableData.getRowCount()] ;   
12.             for(int i = 0; i<tableData.getRowCount();i++){   
13.                 treeNodes[i] = new TreeNode();   
14.                 treeNodes[i].setId(tableData.getString(i,"id"));   
15.                 treeNodes[i].setName(tableData.getString(i,"name"));   
16.                 treeNodes[i].setPid(tableData.getString(i,"parentId"));   
17.                 //根据实际情况生成连接地址   
18.                 url = "programList.x?category="+tableData.getString(i,"name") ;   
19.                 treeNodes[i].setUrl(url);   
20.                 treeNodes[i].setTitle(tableData.getString(i,"remark"));   
21.                 treeNodes[i].setTarget("_blank");//打开新窗口   
22.             }   
23.             dataBean.setParameter("treeNodeArray",treeNodes) ;   
24.         }   
25.     }catch(Exception e){   
26.         System.out.println(e.toString());   
27.     }   
28. }  

public void execute() throws EpochalException {
// TODO Auto-generated method stub
String sql = "";
String url = "" ;
sql = "SELECT id,parentId,name,seq ,remark FROM t_testtree ORDER BY  seq DESC" ;
TableData tableData = null;
TreeNode[] treeNodes = null;
try{
tableData = TableSelector.select(sql);
if(tableData!=null){
treeNodes = new TreeNode[tableData.getRowCount()] ;
for(int i = 0; i<tableData.getRowCount();i++){
treeNodes[i] = new TreeNode();
treeNodes[i].setId(tableData.getString(i,"id"));
treeNodes[i].setName(tableData.getString(i,"name"));
treeNodes[i].setPid(tableData.getString(i,"parentId"));
//根据实际情况生成连接地址
url = "programList.x?category="+tableData.getString(i,"name") ;
treeNodes[i].setUrl(url);
treeNodes[i].setTitle(tableData.getString(i,"remark"));
treeNodes[i].setTarget("_blank");//打开新窗口
}
dataBean.setParameter("treeNodeArray",treeNodes) ;
}
}catch(Exception e){
System.out.println(e.toString());
}
}

Java代码

1. <%   
2. TreeNode[] treeNodes = (TreeNode[])dataBean.getParameterObject("treeNodeArray") ;   
3. %>   
4. <p><a href="javascript: d.openAll();">全部展开</a> | <a href="javascript: d.closeAll();">全部关闭</a></p>   
5. <script language="javascript">   
6. d = <%=TreeNodeUtil.createJsArray(treeNodes,"d")%>   
7. document.write(d);   
8. </script>  

<%
TreeNode[] treeNodes = (TreeNode[])dataBean.getParameterObject("treeNodeArray") ;
%>
<p><a href="javascript: d.openAll();">全部展开</a> | <a href="javascript: d.closeAll();">全部关闭</a></p>
<script language="javascript">
d = <%=TreeNodeUtil.createJsArray(treeNodes,"d")%>
document.write(d);
</script>

Java代码

1. <script language="javascript">   
2. d = new dTree('d');   
3. d.add('1','-1','栏目','programList.x?category=栏目','','_blank','','','');   
4. d.add('2','1','电影','programList.x?category=电影','','_blank','','','');   
5. d.add('3','1','电视剧','programList.x?category=电视剧','','_blank','','','');   
6. d.add('4','1','专题','programList.x?category=专题','','_blank','','','');   
7. d.add('5','1','远程教育','programList.x?category=远程教育','','_blank','','','');   
8. d.add('6','1','期刊','programList.x?category=期刊','','_blank','','','');   
9. d.add('7','2','动作片','programList.x?category=动作片','','_blank','','','');   
10. d.add('8','2','喜剧片','programList.x?category=喜剧片','','_blank','','','');   
11. d.add('9','2','鬼片','programList.x?category=鬼片','','_blank','','','');   
12. d.add('10','3','韩剧','programList.x?category=韩剧','','_blank','','','');   
13. d.add('11','3','古装剧','programList.x?category=古装剧','','_blank','','','');   
14. d.add('12','5','英语沙龙','programList.x?category=英语沙龙','','_blank','','','');   
15. d.add('13','4','热门推荐','programList.x?category=热门推荐','','_blank','','','');   
16. d.add('14','7','港台片','programList.x?category=港台片','','_blank','','','');   
17. d.add('15','7','欧美片','programList.x?category=欧美片','','_blank','','','');   
18. d.add('16','14','成龙全集','programList.x?category=成龙全集','','_blank','','','');   
19. d.add('17','14','李连杰全集','programList.x?category=李连杰全集','','_blank','','','');   
20. document.write(d);   
21. </script>  

<script language="javascript">
d = new dTree('d');
d.add('1','-1','栏目','programList.x?category=栏目','','_blank','','','');
d.add('2','1','电影','programList.x?category=电影','','_blank','','','');
d.add('3','1','电视剧','programList.x?category=电视剧','','_blank','','','');
d.add('4','1','专题','programList.x?category=专题','','_blank','','','');
d.add('5','1','远程教育','programList.x?category=远程教育','','_blank','','','');
d.add('6','1','期刊','programList.x?category=期刊','','_blank','','','');
d.add('7','2','动作片','programList.x?category=动作片','','_blank','','','');
d.add('8','2','喜剧片','programList.x?category=喜剧片','','_blank','','','');
d.add('9','2','鬼片','programList.x?category=鬼片','','_blank','','','');
d.add('10','3','韩剧','programList.x?category=韩剧','','_blank','','','');
d.add('11','3','古装剧','programList.x?category=古装剧','','_blank','','','');
d.add('12','5','英语沙龙','programList.x?category=英语沙龙','','_blank','','','');
d.add('13','4','热门推荐','programList.x?category=热门推荐','','_blank','','','');
d.add('14','7','港台片','programList.x?category=港台片','','_blank','','','');
d.add('15','7','欧美片','programList.x?category=欧美片','','_blank','','','');
d.add('16','14','成龙全集','programList.x?category=成龙全集','','_blank','','','');
d.add('17','14','李连杰全集','programList.x?category=李连杰全集','','_blank','','','');
document.write(d);
</script>

　　随着计算机技术的不断革新，出现了很多种呼叫中心平台的架构方式，从架构的实现方式归纳起来，无外乎两种：基于交换机、板卡的硬件架构呼叫中心平台和纯软件架构的呼叫中心平台。呼叫中心发展到现在，已经进入到重应用、轻技术的阶段，但在同等规模、同样应用的呼叫中心平台下，我们选择什么样的架构呢？以下就是纯软件架构方式与基于硬件的传统架构方式的对比：

CTI论坛编辑

　　经过50年的发展，呼叫中心的服务内容、服务方式、服务技术以及服务领域等各方面都发生了巨大变化。Internet的崛起，以及数据、话音和视频传输网络三网合一技术的发展，给呼叫中心的应用带来了新的空间。尤其体现在呼入呼出功能实现上，由原来只能通过电话一种方式，发展到通过电话、网络电话、Email、传真、留言等多种方式，由此Call Center也就演变成现在的Contact Center。

　　在呼叫中心的发展历程中，最早出现的是基于PBX的呼叫中心，通常称为传统型或常规型呼叫中心，它尚未引入Internet。这类呼叫中心一般成本较高，客户对象为电信及大中型企业。随着计算机和电信技术的发展，开始引入CTI技术（计算机电话集成，Computer Telephony Integration），此时的呼叫中心不仅可以实现人工和自动服务，也可以让用户的语音、文字在任意客服人员之间进行互相转接，提高了系统的服务质量。这种方案的特点是规模小，价格便宜，但不适合于较大的应用场合。第三种呼叫中心是随着Internet的广泛应用产生的，称为基于Internet的呼叫中心。但大多数厂家仍然是将来自Internet的呼叫请求通过一个电话网关，转换成普通的电话请求，再接回到原有的呼叫系统中。IP呼叫中心的出现不再是简单地把Internet信息提供给呼叫中心，而是把呼叫中心与Internet融合为一体。这样的系统中充分利用了VoIP技术，达到节省成本的目的；同时把呼叫中心与互联网集成为一个整体，互联网上的用户请求和电话请求完全等同对待 ，并且支持宽带多媒体呼叫。

　　IP呼叫中心作为一个现代化的呼叫中心，不仅能支持语音电话，还能提供包括音频视频在内的多媒体通信；不仅能支持传统的电话终端，还能支持来自Internet的文字、语音、短消息等交互方式；不仅提供了完整的坐席功能，还具有实用的呼叫中心管理体系。由于采用了先进的VoIP及软件交换技术，就能为电话和Internet的客户提供统一的客户服务。因此相比较传统呼叫中心，IP呼叫中心将更具有的成本优势，同时处理能力也将大幅度提升。

　　相对与传统的呼叫中心而言，“IP呼叫中心”有着不可比拟的优势：

• 分布式支持

　　“IP呼叫中心”系统采用全分布式结构，可以实现多点的、虚拟统一的客户服务中心，座席人员不必拘泥于地理位置，随时随地可以接入呼叫中心为客户提供服务，实现了真正意义上的移动办公。

• 易于面向NGN的升级

　　下一代网络（NGN）的发展已经越来越成熟，“三网合一”也将变为现实，而这一切都是建立在IP的基础之上。从NGN的特点我们不难看出，“IP呼叫中心”符合NGN体系结构，所以“IP呼叫中心”是很容易向NGN进行过渡和升级的。

• 极强的系统扩充能力

　　随着新技术和新产品层出不穷的推出，企业客户服务的任务加剧，呼叫中心的升级就是不可避免的，为了避免升级带来的损失，企业在选择呼叫中心产品时，都异常地谨慎，非常关注其扩展性。这一点对于资金薄弱的中小企业来说尤其重要。IP呼叫中心具有优秀的可扩充性，系统中的每一个组件都是相互独立的，组件之间的通讯采用了国际标准的通讯协议H.323，MGCP，RTP等。对语音媒体的压缩也采用了国际上通用的G.711、G.723.1和G.729。这表明系统中的任何一个部件都可以单独进行升级，并且可以与其它公司符合国际标准的设备进行通信，具有非常好的扩展性。

　　同时，IP呼叫中心也极易根据客户的需要集成其它富有科技含量的模块，如：声纹识别系统和自然语言自动应答系统。通过声纹识别，系统可以通过说话人声音的基本特征来判断其身份，而不只是仅仅依赖于来电号码。自然语言应答系统则支持中文自然语言的语音、文字请求，可自动给出答案。

• 低成本

　　从技术实现角度来看，“IP呼叫中心”相对于传统的呼叫中心而言，由于充分利用了VoIP技术，因此在整个系统中处理的完全是数据，这样很多功能便可以通过软件来实现，比如：ACD、IVR、ServiceSwitch等核心处理模块，省去了大量的硬件投资，同时系统处理流程也得到了进一步优化。

　　除了以上这些优势以外，“IP呼叫中心”在系统功能上具备了传统呼叫中心的一切功能外，还提供了极具特色的一些功能模块：

• IP-IVR

　　IVR（交互语音应答系统）是呼叫中心系统较重要的一部分。IP呼叫中心利用了IP技术来实现IVR的功能。

　　IP-IVR是一个IP驱动的交互式语音响应（IVR）解决方案，可以提供一个开放、可扩展和功能丰富的媒体服务器，通过标准协议访问控制。通过与用户的自主交互，IP IVR能够实现电话处理的自动化。IP-IVR显著地减少了部署传统IVR/专用分支交换机（PBX）集成所需要的成本高昂的T1设备。

　　IP-IVR还充分支持VoiceXML（Voice Extensible Markup Language）语言，可快速完成应用构建；不要求用户学习复杂的高级语言，就可灵活扩充新业务。IP-IVR支持通过开放数据库连接（ODBC）访问数据库, 根据数据库中的内容自动更新语音提示,只需要网络接入，不要求数字信号处理器（DSP）卡。同时，IP-IVR还提供了基于Web的激活和管理功能。

　　另外，可视化的定制方式，使得部署IVR变得异常的简单和容易。

• 移动办公

　　IP呼叫中心支持多种移动平台的接入：PDA、手机、笔记本电脑，WEB化的管理模式，使得异地管理变为现实，只要连入Internet，便可实现呼叫中心服务的支持和管理。

• 穿越防火墙

　　目前国际上的VoIP的产品已经很多，比如NetMeeting、Net2Phone等，但这些产品无一例外的都不支持防火墙的穿透，这就使得服务无法为很多在企业防火墙内部的用户使用，而这个问题在“IP呼叫中心”中得到了很好的解决，通过虚拟代理和IP隧道的手段，系统可以突破VoIP应用瓶颈，顺利穿越防火墙和NAT,并且支持多层防火墙和NAT嵌套的复杂网络环境。

　　几种呼叫中心的比较：

　　IP呼叫中心为融合通信环境提供了统一的IP业务支持平台，同时从营销的角度看，IP呼叫中心产品无疑会开辟一个更为广阔的市场，企业可以利用电信运营商提供的服务平台开展各种更具吸引力的新业务，实现更远的腾飞目标！

南京北极星公司供稿　CTI论坛编辑

网上倒是找到了不少的资料，发现一段javascript的功能实现代码，很不错：
var elTable = document.getElementById("tb");
var oRangeRef = document.body.createTextRange();
oRangeRef.moveToElementText( elTable );
oRangeRef.execCommand( "Copy" );

var appExcel = new ActiveXObject( "Excel.Application" );
appExcel.Visible = true;
appExcel.Workbooks.Add().Worksheets.Item(1).Paste();
appExcel = null;

实现功能就是把id为tb的表格内的数据都生成为excel，我试试了可行，但是放到服务器来运行就是script error的提示，然后网上到处求问，也找了百度空间的几位高手朋友问了下，可是还是不得其法。。不过还是很感谢他们的热心帮助

没办法，我只能用别的方法来实现了，其实满喜欢上面的这个javascript的功能的，比较人性化。。可惜我黔驴技穷，无法用上它，哎！~

既然我帮客户用jsp写的程序，那么我就还是用jsp来实现这个功能吧。。

于是找到了这么一个方法：
原文出自：http://www.jsp.mlc.edu.tw/viewitem.jsp?itemid=0000000065

***************************************************************************************************
一、将网页资料以excel报表以线上浏览方式呈现
xls651.jsp原始码如下