扑克110

Web Designer 设计资源网站集合

admin — Wed, 21 Oct 2009 09:01:58 +0000

Web Designer 设计资源网站集合

Ajax (Ajax编程类)

Blogs（网页设计类博客）

Colors（色彩工具）

CSS（CSS编写资源）

Flash（flash资源和教程）

Fonts（免费字体）

Forums（网页设计论坛）

Free photos（免费照片资源）

Generators（网页元素生成器）

Graphic sources（图片资源）

Icons（图标资源）

Inspiration（创意设计集合）

Templates（模板资源）

Xhtml（xhtml工具）

有关时间旅行的热门问题，玩偶特工和天才理论传

admin — Wed, 23 Sep 2009 02:34:04 +0000

刚刚看了《有关时间旅行的热门问题》这部电影挺有意思的，跟别的科幻电影不一样的直接和幽默。另，亲爱的美剧已经开播了，刚刚看了《天才理论传》这一季的第一集，Sheldon还是一如既往的可爱啊。等待过25号开播的《玩偶特工》中。。。。。。。没有美剧的日子好难熬啊！

PS:我的手机铃声就是主题曲The Big Bang Theory：

Our whole universe was in a hot dense state,
宇宙一度又烫又稠密
Then nearly fourteen billion years ago expansion started. Wait…
140亿年前终于爆了炸等着瞧…
The Earth began to cool,
地球开始降温
The autotrophs began to drool,
自养生物来起哄
Neanderthals developed tools,
穴居人发明工具
We built a wall (we built the pyramids),
我们建长城（我们建金字塔）
Math, science, history, unraveling the mysteries,
数学自然科学历史揭开神秘
That all started with the big bang!
一切由大爆炸开始

“Since the dawn of man” is really not that long,
其实人类历史没有多久
As every galaxy was formed in less time than it takes to sing this song.
星系形成时间比唱完这支歌还要短
A fraction of a second and the elements were made.
元素在微秒间便形成了
The bipeds stood up straight,
两足动物直立行走
The dinosaurs all met their fate,
恐龙都得认命了
They tried to leap but they were late
想要突变没来得及
And they all died (they froze their asses off)
就死光光了（pp都冻成了化石）

The oceans and pangea
大洋和泛古陆
See ya, wouldn’t wanna be ya
拜拜才不想学你
Set in motion by the same big bang!
都是爆炸惹的祸
It all started with the big BANG!
一切从大爆炸开始

It’s expanding ever outward but one day
宇宙向外膨胀但有一天
It will cause the stars to go the other way,
星球会反方向运动
Collapsing ever inward, we won’t be here, it wont be hurt
向内坍塌反正我们不在了不会觉得疼
Our best and brightest figure that it’ll make an even bigger bang!
我们美好光辉的形象将引发一场更大的爆炸

Australopithecus would really have been sick of us
南方古猿肯定不爽我们
Debating out while here they’re catching deer (we’re catching viruses)
在他们捉鹿时唧唧歪歪（我们现在捉电脑病毒了）
Religion or astronomy, Encarta, Deuteronomy
宗教天文 e百科旧约申命记
It all started with the big bang!
一切从大爆炸开始

Music and mythology, Einstein and astrology
音乐神化爱因斯坦占星术
It all started with the big bang!
一切从大爆炸开始
It all started with the big BANG!
一切从大爆炸开始

PS:转个<有关时间旅行的热门问题>的评论：
非典型科幻

和那些一般意义上的科幻片不同，《有关时间旅行的热门问题》并没有靠特效堆砌出来一个完全空想的未来世界的图景，导演嘉瑞斯·贾里维克用了一种看起来是逃避现实的叙事手法讲述了这个不怎么真实的科幻故事。贾里维克说：“其实，我们每天都会幻想一阵子，要么幻想自己和哪个大明星一夜情了，要么就是幻想自己中了500万。幻想这个东西就像是潘多拉的盒子，一旦打开就没有办法关上。幻想之所以很重要，是因为它给我们的人生提供了安全的、多重的、可靠的体验。如果我像以前一样，单纯用特技把这种想象展示出来，第一我没那么多钱做特效；第二没有这个必要。我想拍摄的是一部能慢慢引导观众走进电影中的影片，一点一点地去认同银幕上的角色和他们的生活。所以是选择了台词和不多的场景来拍摄这部电影。我想，语言的重要性不言而喻，但是我们往往会羞愧于用语言把同样重要的幻想说出来。所以，我就有了拍摄一部重头戏全在台词上的科幻电影的想法。”

当然，在看这部“说教” 为主的电影之前，我们也不需要去看史蒂文·霍金写的《时间简史》。虽然影片的一部分情节有些不符合科学定理，但是这也无伤大雅。编剧杰埃米·麦瑟森（Jamie Mathieson）说：“其实我写的剧本只是个非典型的科幻片剧本，我本人是专写喜剧作品的，再说，我也是把这个剧本当做喜剧片来写的，并没有在里面强调太多的科幻元素。我也并没有想把这个电影搞成《回到未来》的姊妹片，虽然我们在电影里也有一个从未来来的女人。但是我的影片和《回到未来》或者是《比尔和特德历险记》是完全不一样的电影。”

群戏的盛宴

可以这么说，《有关时间旅行的热门问题》把自己掩饰得非常好——最普通的几个场景；看起来毫不起眼的几句对白——这一切都让人觉得这部电影没有什么大不了的。相比较起它的标题，影片的确是有些“奇怪”。不过按照导演的说法，他就是要最求这么一种落差感。

贾里维克说：“我们的影片不会引起任何有关时间旅行的争论或者是讨论，这是一部自成体系的电影。那些痴迷于科幻片的粉丝们也会觉得在这部电影里找什么看点和噱头是没有必要的。影片里有很多幽默的片段，那些是典型的英国式的黑色幽默，我非常喜欢我们的这个幽默的剧本。和那部令人失望的《银河系漫游指南》比起来，我敢说我的电影要优秀许多。”

除了这些，影片获得成功的另一个关键就是演员的表演，毕竟这是一部极其考验演员表演功力的影片。不过选角的这些事情肯定难不住曾经拍摄过《吸烟室的故事》的贾里维克。他在影片中找来了几个杰出的舞台演员。刚刚出演完《海盗电台》的克里斯·奥多德说： “能出演这部电影我觉得非常幸运，同时也非常过瘾。贾里维克是那种有个性、有才华的导演。和别人不一样，他非常有自己的见解，在片场也很有主见。基本上，他定下来的事情是没有办法改变的。不过听他的安排肯定不会出错”。

贾里维克对这群演员的表现充满了赞赏和肯定，他说：“这是一群充满了创造力和活力的家伙，每天一看到他们我自己就觉得浑身是劲。我拍摄的也是一部‘没心没肺’的电影，所以得到这些家伙的参与，我的电影的风格也相得益彰了”。

英式幽默

虽然是一部科幻片，可是影片在CGI动画的使用上却是非常节俭，节俭到了几乎可以忽略不计的地步。除了预算上的限制之外，导演本人也是有意而为之的。贾里维克说：“我不希望我的电影拍出来之后就是CGI动画，也不希望观众看完电影之后就记住了CGI动画。所以，我很节制的使用特效。我觉得一部科幻电影总是要有幻想的成分的，如果把那些仅存于脑子中的事物用电脑制作出来，然后展示给观众看就没有意思了。也许那就不叫科幻电影了，应该叫它科学电影”。

可能这样一部影片最令人着迷的地方就是它的风格了，确切的说是英式的幽默风格。虽然是喜剧片，但是《有关时间旅行的热门问题》并没有去搞夸张的肢体动作，也没有去弄无巧不成书的噱头，更没有拙劣的模仿经典影片的桥段。像是《葬礼上的死亡》，全片透露着一种高雅和低俗并存，睿智和脑残齐举的黑色幽默。贾里维克说：“其实我是一个地道的伦敦人，外国人说的英国幽默是我与生俱来的个性和特点。我没有觉得我在影片里故意要搞英国幽默出来，我只是很平常地把我觉得好笑的东西放了进去而言。我承认，有一部英国电影对我拍摄本片产生了很大的影响，那部电影是《僵尸肖恩》。我在拍摄本片的时候经常会想到它，我觉得那才是典型的黑色幽默，既然让人忍俊不禁，又让人无法自控。”

花絮

·影片的时间跨度为50年。

·“有关时间旅行的热门问题”一共是25个。

·那些无所事事的30来岁的英国男人在影片里一共喝掉了9磅啤酒。

·编剧在创作剧本时，借鉴了很多其他的科幻电影。比如：《ET外星人》、《第三类接触》、《小魔怪》和《异形》。

【转】鲁迅滚蛋了，他笔下的人物欢呼雀跃了

admin — Fri, 21 Aug 2009 01:33:22 +0000

近来，由于人民教育出版社在新版语文教材中逐步剔除鲁迅的文章，引来一片争议，赞者有之，阻者有之。而笔者认为，在近年来对鲁迅话题经历了沉默、回避、冷淡的过程后，现在让其滚蛋，已经是时候了。
鲁迅之所以滚蛋，是因为那些曾经被其攻击、痛斥、讥讽、怜悯的人物又一次复活了，鲁迅的存在，让他们感到恐惧、惊慌、卑怯，甚至无地自容。
看看：
孔乙己们复活了。并且以一篇《‘茴’字有四种写法》的论文，晋级为教授、学者、国学大师；也不再提心吊胆地“窃书”了，而是平心静气地在网络上“窃文” 了；不仅可以舒坦地“温一碗洒”，而且还能以其博导的诱惑力对“伊”来一把潜规则了，他岂能让鲁迅揭了他前世的底？！
“资本家的乏走狗”们复活了。尽管它们披上了精英、专家的外衣，但依然“看到所有的富人都驯良，看到所有的穷人都狂吠”，他们或装神弄鬼地玩弄数字游戏，鼓吹物价与美国接轨、工资与非洲接轨的必然性与合理性；或干脆作了外国人欺诈中国的“乏走狗”，与其里应外合、巧取豪夺。它们岂容鲁迅再一次把它打入水中？！
赵贵翁、赵七爷、康大叔、红眼阿义、王胡、小D们复活了。有的混入警察队伍，有的当上了联防队员、城管。披上制服兴奋得他们脸上“横肉块块饱绽”，手执“ 无形的丈八蛇矛”，合理合法地干起了敲诈勒索，逼良为娼的勾当。如果姓夏那小子在牢里不规矩，不用再“给他两个嘴巴”，令其“躲猫猫”足矣。想想，这些下做的勾当儿怎能让鲁迅这种尖刻的小人评说？！
阿Q们复活了。从土古祠搬到了网吧，但其振臂一呼的口号已经不是“老子革命了！”而是“老子民主了！”每天做梦都盼着“白盔白甲”的美国海军陆战队早一天杀过来，在中国建立民主。因为只要美国的“民主”一到，赵七爷家的钱财、吴妈、秀才老婆乃至未庄的所有女人就都是我的了！哼！而鲁迅却偏偏要我做个被世人嘲讽了数十年的冤死鬼，我岂能容你？！
假洋鬼子们复活了。这回干脆入了外籍，成了真洋鬼子。并且人模狗样儿地一窝锋地钻进“爱国大片”的剧组，演起了凛然正气、忧国忧民的仁人志士，让人好生不舒服。此种一边哽咽着颂扬祖国母亲，一边往向征中华文明的青铜大鼎里撒尿的举动，岂不是鲁迅杂文中的绝好素材？！
祥林嫂、华老栓、润土们复活了。他们依然逆来顺受，情绪稳定。因为“这人肉的筵宴现在还排着，有许多人还想一直排下去”，这样，必须要备足了餐料。而那些准备做餐料的人，本来可以闷在铁屋子里，一边听着小沈阳的笑话，一边麻木地死去，岂容鲁迅把他们唤醒，再一次经历烈火焚身的苦痛？！
那些“体格茁壮的看客们”复活了。他们兴致勃勃地围观那些“拳打弱女”、“棒杀老翁”、“少年溺水”、“飞身坠楼”的精彩瞬间，依旧“颈项都伸得很长，仿佛许多鸭，被无形的手捏住了的，向上提着”。哈哈，仅看客一类，被你伤害的人就太多了，因为中国人几乎都愿做看客！
鲁迅之所以滚蛋，是因为当今的社会不需要“投枪和匕首”，而需要赞歌、脂粉、麻药。正如陈丹青先生讲的“假如鲁迅精神指的是怀疑、批评和抗争，那么，这种精神不但丝毫没有被继承，而且被空前成功地铲除了。我不主张继承这种精神，因为谁也继承不了、继承不起，除非你有两条以上性命，或者，除非你是鲁迅同时代的人。最稳妥的办法是取鲁迅精神的反面：沉默、归顺、奴化，以至奴化得珠圆玉润”。
如果鲁迅赶上这个时代，对于“开胸验肺”、“以身试药”、“周公拍虎”、“黑窑奴工”、“处女卖淫”、“官员嫖幼”等一系列奇闻，又会写出多少辛辣犀利、锥骨入髓、令人拍案叫绝的杂文来，想想，真是让人后怕，所幸这个尖酸刻薄的小人已不在人世了。
让我们彻底赶走鲁迅，欢迎“小沈阳”，让人们在开心笑声中忘却现实的不公和苦痛，在笑声中渐渐地麻木、渐渐地变傻、、、、、

为什么幸运的人总幸运,倒霉的人老倒霉

admin — Sun, 05 Jul 2009 15:33:53 +0000

刚刚看了斯宾塞·约翰逊写的《为什么幸运的人总幸运倒霉的人老倒霉》，一本书只讲了一件事，如何选择，更准确的说是如何做出更有利的选择。认清真正的需求，扩展可能的选择面，做出最好的选择，幸运就这么简单。

再帖一个别人写的书评,来自: 铂程斋@喷嚏网 (dapenti.com) ：

一直走运

我们先来看一个典型的案例。这个案例会帮助我们理解：如何找到一直走运的方法。

在IT圈内，有个著名的问题：在35岁后，做程序员是否合适？

关于这个问题，包含着很大的担忧和不安。其潜台词也极为丰富，夹杂着更多的疑问：

【1】程序员吃的都是青春饭，35岁是否太老了？

【2】35岁还在做技术活，是否是一种人生的失败呢？

【3】35岁后，是否能靠一种手艺赚钱，并过上一种体面的生活？

【4】我刚入行不久，如果情况不妙，我是否该另寻出路？或改门换道？

大家也有很多不同的回答：

【1】在35岁后，可以一直做技术，不要抱怨环境，是你自己的技术还不够深入。

【2】在35岁后，已经有不少经验了，可以做管理了，不用再编码了。

【3】IT没什么搞头，钱少事儿多，做点生意吧！

总而言之，每个人的选择不同。但是显然，一些人的答案，并不适合另外一些人。

看起来这是一道问答题，其实，这是一道生活的选择题。每个人的抉择，每一步的选择，会把你带向忧虑，或一片坦途。

或许，成功的人就越成功，倒霉的人就越倒霉。除了运气，跟自己有很大的关系。

明白自己的真正需要

很多时候，我们的最大不幸，来自于迷恋自己的优势，我们自认为的优势。

尤其是这些优势，在我们的头脑里，还未有现实的成功的经验的时候。

技术是非常精致的东西，需要技巧的学习，掌握或应用后有一种征服的快感或迷恋。但越尖锐的东西，也最脆弱。思维越严密，其限制就越多，假设就越多。

人很多时候，都是靠假设在向前走，看不到自己真正需要的东西。

如果我们扪心自问：我们是为技术而技术，还是希望通过技术手段，给我们带来好运，美好的生活？

这是一个关键问题，这个问题，或许，也是致命的。

要么一条路走到黑，不管什么结果，你，都可以承受吗？

当你对生活的重复感到一丝疲倦的时候，你尝试一下回答这个问题!不要找理由回避！

你问自己：我做技术，难道不是为了今后的美好生活吗？我要给老婆一个温馨的家，给孩子很好的教育，最好，我能持续地做事，并持续地显示出自己的优势。至于技术的成就，那是否只是事业的事情？事业和生活，不是非此即彼的两件事，而是并行不悖的两件事？

如果我自己做不到怎么办呢？如果拿掉自己的优势，我还能做什么呢？我是否还能保持做技术时的喜悦呢？

如果有一天，35岁来临，你所服务的公司因为经营不善，而把你裁掉，如果到那个时候，你才发现自己竟然任人处置，毫无办法，这又是多么大的不幸啊！

其实，这完全可以避免。

很多时候，我们的问题就是：在做事情前，过于理想化，进入的太快，在做的过程中，很多琐碎的事情缠身，忘记了自己真正想要的东西，别人说什么就是什么，从来没有给自己更多的选择和准备，到头来却发现南辕北辙。希望越大，失望也越大。

如果不明白自己真正的需要，抱怨和失落的感觉，就会越来越强，人要么变得偏执，要么变得颓废。很多时候，我们都会抱怨自己身不逢时，而放弃了反省自己的能力。

追求自己真正想要的东西，而不是不靠谱的承诺，或是别人提供的“标准”答案。

埋头干活，也要抬头看路

没有人，能站在人生的高处俯视自己的一生。人的生活，就如同寻找登山的路，每到一处，都是一种选择。

如果你的目标是登顶，那么在很多条路的时候，可以给自己更多的有益的选择。

回到原点：你想要什么，你的短期目标是什么，长期目标是什么？如何为长期的目标给一些新的准备？

我们既要埋头干活，也要抬头看路。

在一个圈子里呆的太久，所有的人想法，都大致相同了，这能帮助你很快地找到入围的感觉，但也能妨碍你继续前进。

圈子里的人，会用很多的专业词汇，来讨论很多专业的问题。但是，往往容易失去用简单规则去判断事物大局的能力。

有太多的事情能证明这一点，很多在行业内成功的人，开始的时候，都是局外人。

对任何的话语，都要安装自己的过滤器，要自己内心的感觉来分清楚，哪些是友好有价值的声音，哪些是忽悠的声音，又有哪些完全是噪音。

我们不仅要了解技术，更要了解人性。专业只能决定你是否胜任某项工作，而对人性的理解，能帮助你一生都可以避免无谓的伤害。

坚持所选择的，但也要适当调整

谁都不能保证自己永远不犯错误，关键是你是否回头看见过自己走的路，看见了哪些是成功的，哪些是失败的。

一个人，能清醒认识到自己的失误，就会避免反复地落入同样的陷阱中。

人，有时候，需要有一些摆脱困境的简单方法，但这些方法，不是不去想，很多时候，不是场景的问题，而是自己的感觉不好。找不到感觉，就随便去做，或是不去想后果，往往就会得到最坏的结果。

对什么忠诚啊，信仰啊，价值观、诚信啊，人肯定要信任并期望，但最好也要自己掂量。有很多人拿这些来说事儿，但这些跟自己的内心感觉，很可能完全不是一码事情：遥远的天空挂的是月亮，还是大饼，谁信谁知道！

不要因为坚持，而放弃调整。想想自己的目标是什么，就不会太委屈和苛求自己。每个人的生活，都有一个简单的抉择：想改变，就改变自己好了。

说到斯宾塞的书，大家耳熟能详：《谁动了我的奶酪》、《礼物》等等。他的书，简单通透，连故事的结构都非常风格化，总让你从简单的故事中明了深刻的道理，几乎适合所有人阅读。

我在读《为什么幸运的人总幸运，倒霉的人总倒霉》，就想起IT界那个著名的问题。其实，在我看来，这个问题就是一个选择。这个问题，不会仅仅发生在某个行业中，它可能发生在生活、学习、工作、婚姻、家庭的任何一个角落里。我们的确需要一种智慧的简单的法则，来指引我们抉择的方向：

任何时候，我们都要相信自己，学会观察大局，用心去倾听我们内心的声音。然后努力去做，勇敢调整，那么，幸运就会伴随着我们，一直到永远！

毕业了，感叹真多

admin — Sat, 27 Jun 2009 04:04:56 +0000

在CSDN上看到有人写的十年总结，写的真好，刚好我也毕业了，不知道将来的十年会给我带来什么样的变化。

另外，转个他写的另外一篇文章，再看看自己，肯定是属于1级的了。。。

“职场“潜”规则：买火车票精神与主观能动性”

“潜”规则是那些书本上讲不清的事情，是需要用心体会的。

最近在论坛回复贴子的时候，我又提起了“买火车票精神”这个词，

这是我2007年团队内部会议上创造的一个词汇，我觉得这是对“主观能动性”的最佳诠释。

经历过春运的各位，想必对此精神心领神会，

将买票的劲头与工作劲头做一个类比，我觉得是件很有意思的事情：

0级：

根本不去买票，拿到票的机会：0％（老子今年不回家）

对应工作中消极怠工的人，这样的人在软件企业似乎少见，也不是没有（也许是不想干了，爱咋咋地）

1级：

按照车站的放票时间去排队买票，据统计，拿到票的概率10%左右。

类比工作中的人，你需要给他安排很细致的任务，需要随时关注他的进度，帮他解决遇到的困难

2级：

充分动用网络、电话、雇人排队等各种手段，甚至去找票贩子，想尽办法拿到车票，据统计拿票概率：80％以上。

类比工作中的人，你安排下去的工作，他都会积极推进，自主解决问题，尽快完成任务并及时汇报。

3级：

除动用各种手段买票外，一旦有拿票机会，还会多买几张倒腾一下，把自己的路费赚出来，实在买不到票，买张站台票蹭上车也要回到家。

类比工作中的人，这真是罕见的极品，是最佳的合作排挡，你只需要告诉他一个目标，它会自己做方案、出计划，
执行过程中，他会真正理解每一项任务，并选择最佳的工作方式。

前一段时间，有另外一组的两个同事找我，说他们领导希望我配合他们测一项功能，

我随口问到：你们的计划呢？

两个人面面相觑，没有。

我又问：那需要我做什么？

回答竟然是不知道。

这是两个毕业半年多一点的学生，他们只是领命来做一件事儿，他们也很积极，

却没有思考具体做什么，怎么做，他们以为别人会帮他们安排好。

主观能动性，并不仅仅是努力去做事儿这么简单，

就像春运期间买票一样，买票不是目的，回家才是目的。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/jinxfei/archive/2009/05/31/4227882.aspx

第五讲：统一建模语言UML轻松入门之综合实例

admin — Sat, 20 Jun 2009 07:09:12 +0000

“例，比也”（《说文》），本次连载将给出一个利用UML进行建模的完整实例，综合应用前面学到的知识，达到”举此以例其余”（元刘壎《隐居通议·欧阳公》）的目的。

在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。我们在日常生活中也经常和ATM打交道。本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。

5.1用例图

参与者”银行储户”和ATM机。简化后的ATM机仅有取款、存款及其余功能。其余功能不做详细说明。

————————————————————————————————————

图5.1 自动取款机（ATM）系统用例图

银行储户在ATM机上完成取款、存款及其他业务。

5.2类图

图5.2所示的银行系统类图和图3.5是类似的，只是将工作人员换成了ATM。整个银行系统包括了帐户库、银行储户库及ATM系统。

许多单个的帐户组成了帐户库。帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、 getBalance，除caculateBalance为protected其余均为public。

setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。

getType获取帐户类型，返回类型为char，无参数。

setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。

getAccountNumbe获取帐户号，返回类型为int，无参数。

caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。

getBalance获取帐户余额，返回类型为double，无参数。

许多银行储户组成了储户库。ATM系统包含了许多ATM机。银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。更多的属性及操作都可以一一加上，使这个类图更详细更完整，从而使参与项目的每个成员都能无歧义的明了整个设计的类的结构。同样对于一个真正的银行系统，这个类图过于简单。比如帐户类型我们可以先定义一个abstract class，它包含一个帐户最基本的属性及操作。而有些操作先定义为abstract，如余额的计算。然后再继承这个abstract class，我们可以有saving account 和checking account等等。不同的帐户有不同的余额计算方法，我们可以加上具体的算法。对于不同的帐户可能还有一些它特有的操作，我们也可以加上，比如 saving account在存款达到多少时可以享受机票打折的优惠。通过类图不仅可以使设计者明确的表达自己的设计意图，也能帮组自己整理思路，充实及优化自己的设计。

图5.2 银行系统类图

5.3顺序图

图5.3描述了顾客在ATM机上取款时信息的流动情况。以时间为顺序。因为仅是示例，所以整个过程是没有出现任何故障时的流程，并且只画到了取款结束。通过这个图，我们可以看出消息是如何在系统中不同对象之间进行交互。

通过流程图我们可以很清楚地看到系统是如何工作的，系统各部分之间的信息及控制是如何发送的，整个流程是否合理。流程图对我们的设计起到了很好的帮助作用。注意在本图没有一个生命线终端有一个”X”，这是因为这个流程中还未遇到有对象生命结束。当有对象生命结束时需在对应的生命线终端画”X”，表明这个对象在这时被销毁。

首先银行储户将ATM卡插入读卡机，读卡机将信息传给客户管理，客户管理提出查询密码，显示部分将输入密码请求显示出来…..因为这个顺序图较长，且很清晰，即便是初学者也很容易读懂，在此就不对本图做过多的解释。

图5.3 ATM取款顺序图

5.4状态图

图5.4描述了顾客在ATM机上进行操作会经历的几种状态，及各种状态之间转换的条件。因为是简化了的例子，所以除了等待顾客插入磁卡的起始状态和结束服务的终止状态，顾客会处于输入密码、选择服务类型、存款及取款四种状态。

图5.4 ATM状态图

插入磁卡后进入输密码状态，当密码输入正确时进入选择服务类型状态，当输入密码不正确时，停留在原状态，但如果三次不正确，服务结束。进入选择服务类型后根据选择的不同，顾客可进入存款和取款状态。存、取款结束后，顾客既可以选择结束服务到最终状态，也可以选择继续服务回到选择服务类型状态。

通过状态图我们可以无歧义的了解各个活动角色是如何在不同状况下转换的，转换的条件是什么，是否会出现死锁现象，是否有条件没考虑周全，是否有状态无法达到。状态图可以帮助我们发现问题，并及时改正。

5.5活动图

图5.5参考了Randy Miller的《A Hands-On Introduction for Developers》一文，5.3图中的客户管理和事物管理对应于5.5图中的Bank，图5.3中的读卡机、显示、输入设备及点钞机对应于5.5图中的ATM Machina，银行储户就是Customer。初看活动图和顺序图表达的意义很接近。但我们可以注意到顺序图着重时间的顺序，而活动图侧重于各部分之间的相互制约，对于一些并行的活动能够有效的表示出来。例如5.5图中fork和join处，我们可以很清楚的看到一些并行活动的存在。

这个活动图以顾客插入卡为开始，以顾客取卡结束。我们可以看到活动图的重点虽然不在时间顺序，但我们同样可以得到时间的信息。

图5.5 ATM银行系统活动图

5.6协作图

在第四章中我们知道协作图和顺序图是可以无信息损失的相互转换，只是它们的侧重点是不一样的。顺序图着重于对象间消息传递的时间顺序，协作图着重于表达对象之间的静态连接关系。图5.6将5.3图转换为协作图。

1．插入ATM卡

2．接受ATM卡

3．查询密码

4．显示输入密码请求

5．输入密码

6．密码传递

7．请求确认密码合法性

8．确认密码合法性

9．询问服务类别

10．显示输入服务服务类别请求

11．输入取款请求

12．取款请求

13．询问取款数额

14．显示输入数额请求

15．输入取款数额

16．传递取款数额

17．询问取款数额确认

18．显示确认数额请求

19．输入确认

20．传递确认信息

21．数额合法性确认请求

22．确认数额和法性

23．出钞请求

24．计算帐户余额

25．出钞

26．取钞

27．传递余额并询问是否还需要其他服务

28．显示帐户余额并提示选择下面的服务

图5.6 ATM系统协作图

从图上我们可以看出协作图的角色和顺序图的对象是一一对应的，而协作图上的各对象上的协作关系和顺序图上的消息传递是一一对应的。

第四讲：统一建模语言UML轻松入门之动态建模

admin — Sat, 20 Jun 2009 07:01:15 +0000

静可描形，动可描行。动和静是辩证的两面，在UML中，静态建模可以描述系统的组织和结构，而动态建模则可描述系统的行为和动作。

　　前一节中介绍的类图和对象图主要用于静态建模，本节我们将描述UML中的动态建模机制。在动态建模机制中，以消息来完成对象之间的交互，用状态图、顺序图、协作图和活动图来描述系统的行为。

　　4.1消息

　　在面向对象领域，两个对象的交互是通过消息的发送和接收来完成的。消息分为简单消息、同步消息和异步消息：

　　（1）简单消息：只是表示控制如何从一个对象发给另一个对象，并不包含控制的细节；

　　（2）同步消息：同步意味着阻塞和等待，如果对象A给对象B发送一个消息，对象A会等待对象B执行完这个消息，接着才进行自身的工作；

　　（3）异步消息：异步意味着非阻塞，如果对象A给对象B发送一个消息，对象A不必等待对象B执行完这个消息，就可以接着进行自身的工作。

　　4.2顺序图

　　顺序图（也称序列图）是一种交互图（Interaction Diagram，用于描述执行系统功能的各个角色之间相互传递消息的顺序关系，显示跨越多个对象的系统控制流程），强调的是时间和消息的次序，用来说明系统的动态情况，顺序图由参与者、对象、对象生命线和消息组成。一个顺序图显示了一系列的对象（通常是类的实例，也可以代表其他事物的实例，例如协作、组件和节点）和在这些对象之间发送和接收的消息。

图4.1 图书入库顺序图

　　图书管理系统中图书入库的顺序图如图4.1所示，对于顺序图，往往在文字表述上会出现”当…时…”、”首先”、”然后”、”接着”、”…发出…消息”，”…响应…消息”等词汇。例如图4.1的顺序图可用文字表达为：

　　当管理人员把新书入库时，首先要求登录（输入用户名和口令），经系统的”注册表单”验证，若正确无误，则可继续下一步交互，否则拒绝该管理人员进入系统。若登录正确，管理人员可发出查询请求消息，系统的”图书入库表单”对象响应请求。若管理人员发出增加或删除库存图书请求，”库存图书”对象将响应该消息，找出数据库中的相关数据并执行相应的操作。此后，管理人员应按下提交键确认请求，”图书入库表单”接口对象应该响应该请求，并发出存储消息，才由”库存图书”对象响应存储消息，进行数据库存储操作。如果管理人员结束图书入库，发出退出系统的请求，则系统的”注册表单”接口对象响应请求，关闭系统。

图4.2 购买商品顺序图

　　而图4.2则给出了电子购物系统中购买商品的顺序图，通过观察顺序图，我们可以很清晰地看出顾客购买商品的流程。
4.3状态图

　　状态图是UML中的状态机视图。状态机由对象的各个状态和连接这些状态的转换组成。每个状态对一个对象在其生命期中满足某种条件的一个时间段建模，当一个事件发生时，它会触发状态间的转换，导致对象从一种状态转化到另一新的状态。与转换相关的活动执行时，转换也同时发生。

　　状态图用于描述对象可以拥有的状态以及引起状态相互转移的事件和条件，它揭示了对象的生命周期，是针对类的一种建模工具。状态是对象前一次操作的结果，事件是引起状态向另一状态转化的活动。所有对象都有状态，但通常只对具有复杂行为的类建立状态图。状态图强调的是事件驱动的对象的动作，这在对反应式系统的建模是相当重要的。

　　两个类的状态图之间可以相互发送消息，一个状态还可以有嵌套的子状态，各子状态之间的关系可以为与/或关系。

　　在如图4.3所示的车载GPS终端系统中，车载GPS终端一方面与GPS卫星通信，另一方面将从GPS卫星获得的位置信息（经度、维度等）通过GSM短消息与车辆监控调度中心进行交互。

图4.3 车载GPS终端系统

　　在这样的系统中，鉴于通信过程中GPS终端可能处于不同的状态，我们可用状态图来对其进行描述，这样很直观和明确。图4.4给出了GPS终端的状态（待命、有问题、通话中、短消息通讯中）及其状态之间的变迁关系。

图4.4 GPS终端的状态图

　　4.4 活动图

　　活动图用于描述系统、用例、程序模块中的逻辑流程的先后执行次序、并行次序，是对人类组织的现实世界中的工作流程的建模，有助于理解系统高层活动的执行行为。

　　活动图中的主要概念是”活动”，而”活动”的具体含义又取决于作图目的和抽象层次：

　　（1）当活动图用于描述系统行为时，主要侧重于系统多个用例活动之间相互制约的执行顺序，同时，识别出系统中存在的可以并行进行的用例，此时，活动表示系统要完成的任务；

　　（2）当活动图用于描述用例时，用于描述用例中的操作执行次序和操作完成的结果，显示多个对象的操作是如何相互结合起来共同完成用例的一个脚本，揭示出操作之间的并行性，为编码实现提供开发并行程序的便利，此时，活动表示类中的方法，即操作。允许将某个组织或执行者要完成的若干操作聚集在泳道中，以明确责任。

　　活动图用于低层次程序模块的作用类似于流程图，但活动图还可以描述并行操作，而流程图则只能描述串行操作。例如，图4.5给出了生产管理系统中的定单处理用例的活动图，它明显地带有流程图的特色，但是，它还表示了处理过程中的并行过程。图4.5中的付款认可活动属于财务管理用部门的职责，其它活动属于销售部门的职责，这两个部门在并行运作。

图4.5 定单处理的活动图

　　图4.6则给出了药品管理系统中药品采购入库过程的活动图。

图4.6 药品入库的活动图

4.5协作图

　　与顺序图一样，协作图也是一种交互图，用于描述对象之间的协作关系，其模型元素与序列图的基本相同，但它侧重于描述对象之间是如何相互连接的，强调的是发送和接收消息的对象之间的组织结构。顺序图着重体现对象间消息传递的时间顺序，协作图着重于哪些对象间有消息传递，表达了对象之间的静态连接关系。顺序图和协作图是同构的，它们相互之间可以转化而不损失信息，依靠工具协作图和顺序图可互相转换。

图4.7 注册新课程的协作图

　　图4.7给出了注册新课程的协作图，图中描述了注册者、课程表单、管理员和课程对象之间的协作关系，对象之间的连接关系上给出了发送和接收的消息。

　　4.6 UML图之间的关系

　　连载2-4给出了多种类型的图，这些图之间存在着或直接或间接的关系（如图4.8），这体现了UML中的辩证法。

图4.8 UML图的关系

　　用例图主要用来描述系统的外部行为；类图和对象图用来定义类和对象以及它们的属性和操作；状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件；顺序图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互；合作图强调对象间的动态合作关系；活动图描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动。

　　除此之外，我们还没有详细讲解的包图用于描述系统的分层结构，构件图描述代码部件的物理结构及各部件之间的依赖关系，配置图定义系统中软硬件的物理体系结构。

第三讲：统一建模语言UML轻松入门之静态建模：类和对象

admin — Sat, 20 Jun 2009 07:00:01 +0000

同类相从，同声相应，固天之理也。–《庄子·渔父》

　　类是一种对本质相同事物的抽象，人类软件开发技术的发展历史，就是还事物以本源的历史，开发技术、名词越来越接近世界的真实，”面向对象”、”类”就是这样的产物。

　　3.1类图

　　在UML中，类图显示了一组类、接口、协作以及它们之间的关系。在UML的静态机制中类图是一个重点，它不但为设计人员所关心，更为实现人员所关注，建模工具也主要依据类图来产生代码（正向）工程。因此，类图在UML的各种图中占据了相当重要的地位。

　　类

在类图中类用矩形框来表示，它的属性和操作分别列在分格中，若不需要表达详细信息时，分格可以省略。一个类可能出现在好几个图中。同一个类的属性和操作只在一种图中列出，在其他图中可省略。图3.1给出Student类和MFC中的CObject类。

图3.1类的表示

　　类间关系

　　在类图中，除了需要描述单独的类的名称、属性和操作外，我们还需要描述类之间的联系，因为没有类是单独存在的，它们通常需要和别的类协作，创造比单独工作更大的语义。在UML类图中，关系用类框之间的连线来表示，连线上和连线端头处的不同修饰符表示不同的关系。类之间的关系有继承（泛化）、关联、聚合和组合。

　　（1）继承：指的是一个类（称为子类）继承另外的一个类（称为基类）的功能，并增加它自己的新功能的能力，继承是类与类之间最常见的关系。类图中继承的表示方法是从子类拉出一条闭合的、单键头（或三角形）的实线指向基类。例如，图3.2给出了MFC中CObject类和菜单类CMenu的继承关系。

图3.2 类的继承

　　类的继承在C++中呈现为：

　　class B { }
　　class A : public B{ }

　　（2）关联：指的是模型元素之间的一种语义联系，是类之间的一种很弱的联系。关联可以有方向，可以是单向关联，也可以是双向关联。可以给关联加上关联名来描述关联的作用。关联两端的类也可以以某种角色参与关联，角色可以具有多重性，表示可以有多少个对象参与关联。可以通过关联类进一步描述关联的属性、操作以及其他信息。关联类通过一条虚线与关联连接。对于关联可以加上一些约束，以加强关联的含义。
　
　　关联在C++中呈现为：

　　class A{…}
　　class B{ …}
　　A::Function1(B &b) //或A::Function1(B b) //或A::Function1(B *b)

　　即一个类作为另一个类方法的参数。

　　（3）聚合：指的是整体与部分的关系。通常在定义一个整体类后，再去分析这个整体类的组成结构。从而找出一些组成类，该整体类和组成类之间就形成了聚合关系。例如一个航母编队包括海空母舰、驱护舰艇、舰载飞机及核动力攻击潜艇等。需求描述中”包含”、”组成”、”分为…部分”等词常意味着聚合关系。

图3.3 类的聚合

（4）组合：也表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在，部分对象也将不存在。部分对象与整体对象之间具有共生死的关系。

　　聚合和组合的区别在于：聚合关系是”has-a”关系，组合关系是”contains-a”关系；聚合关系表示整体与部分的关系比较弱，而组合比较强；聚合关系中代表部分事物的对象与代表聚合事物的对象的生存期无关，一旦删除了聚合对象不一定就删除了代表部分事物的对象。组合中一旦删除了组合对象，同时也就删除了代表部分事物的对象。

　　我们用浅显的例子来说明聚合和组合的区别。”国破家亡”，国灭了，家自然也没有了，”国”和”家”显然也是组合关系。而相反的，计算机和它的外设之间就是聚合关系，因为它们之间的关系相对松散，计算机没了，外设还可以独立存在，还可以接在别的计算机上。在聚合关系中，部分可以独立于聚合而存在，部分的所有权也可以由几个聚合来共享，比如打印机就可以在办公室内被广大同事共用。

　　在C++语言中，从实现的角度讲，聚合可以表示为：

　　class A {…}
　　class B { A* a; …..}

　　即类B包含类A的指针；

　　而组合可表示为：

　　class A{…}
　　class B{ A a; …}

　　即类B包含类A的对象。

　　准确的UML类图中用空心和实心菱形对聚合和组合进行了区分。

图3.4 聚合和组合

图3.5 银行管理系统类图

　　图3.5给出了一个典型的银行管理系统的类图，基本上一看就懂：

　　银行类聚合了账号库（AccountSet）、客户库（EmployeeSet）和员工库（EmployeeSet）；

　　账号库中包含了n个账号（Account）、客户库中包含了n个客户（Employee），员工库包含了n个员工（Employee）；

　　员工类和客户类都继承自人(Person)类，而员工类中又有一种特殊的员工，即员工管理者类（EmployeeAdmin）；

　　账号类和客户类之间体现出一种关联关系；

　　单独的元素PersonSex定义了枚举类，其中包括Male和Female两种性别。

　　我们再给出一个类图实例（图3.6），它来源于软件无线电SCA（软件通讯架构）标准。软件无线电技术是目前电信产品、军用电台中研究的大热门，在其定义的SCA体系中，核心框架即以类图的形式呈现，它定义了应用程序基本框架和标准控制服务接口。

　　实际上，软件无线电核心框架即由类以及类之间的继承、关联和聚合关系组成。

图3.6 软件无线电核心框架

　　接下来，我们给出建立类图的步骤：

　　（1）研究分析问题领域确定系统需求；

　　类的识别是一个需要大量技巧的工作，寻找类的一些技巧包括：名词识别法；根据用例描述确定类；使用CRC分析法；根据边界类、控制类、实体类的划分来帮助分析系统中的类；参考设计模式确定类；对领域进行分析或利用已有领域分析结果得到类；利用RUP中如何在分析和设计中寻找类的步骤。

　　（2）确定类，明确类的含义和职责、确定属性和操作；

　　（3）确定类之间的关系。

　　3.2对象图

　　对象图显示某时刻对象和对象之间的关系，是类图的变化，一个对象图可看成一个类图的示例(example)，对象图表示的是类的对象实例而不是真实的类。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。

　　对象图中并无新的表示法（除了对象名下要加下划线以外），与类图中的表示法一样，可以认为，只有对象而无类的类图就是一个”对象图”。

图3.7 对象图

　　在对象图中，对象名可以有三种表示形式：

　　（1）对象名：类名

　　（2）：类名

　　（3）对象名

　　图3.7中的是第1种，即”对象名：类名”格式。

　　实质上，对象图几乎很少被用到（它包含的信息量太小，仅仅用于呈现某一时刻对象的值，对软件的设计几乎没有太大的帮助），使用远没有类图广泛。我们可以这样类比类图和对象图之间的关系：

　　”动词+名词”构成”动名词”，例如动词”爱”+名词”国”构成动名词”爱国”。

　　我们可以看到，”动名词”的信息量很大，很抽象，而作为动名词的例子的”爱国”信息量很小，具体程度很高。

　　动名词　―――――> 类图

　　爱国　　―――――>　对象图

　　把”动名词”看作类图，把”爱国”看作对象图，很明显，对象图就是类图的一个example而已。

第二讲：统一建模语言UML轻松入门之静态建模：用例

admin — Sat, 20 Jun 2009 06:59:07 +0000

目前，在的内地版《神雕侠侣》中，杨过和小龙女有一份不为人知的默契与浪漫，那就是他们所绘制的并肩小人图。这样的小人图，是UML用例图的一部分，被称为参与者。

　　2.1 用例与用例图

　　用例是需求分析中最重要的概念，需求表征了一个系统的设计特性、特征和行为，描述一个系统的需求意味着描述了建立在该系统外部的事物与系统之间的契约，契约上声明了期望系统做什么。

　　需求获取(Requirement Elicitation) 是需求工程的主体，其主要工作是建立待开发系统的模型，而用例就是用于建立这种模型的良好方法。用例最初由Ivar Jackboson博士提出，后被综合到UML规范之中，成为需求表述的标准化体系。前文已经提到，整个RUP流程都是”用例驱动”的，各种类型的开发活动包括项目管理、分析、设计、测试、实现等以用例为主要输入工件，用例模型奠定了整个系统软件开发的基础，用例被认作第二代面向对象技术的标志，可见其重要性非同一般。

　　我们先来给出一个具体而简单的用例图，即”图书管理系统”用例图，如图2.1。在用例图中主要涉及到参与者（又称角色、执行者）、用例以及二者之间的通讯关联。

图2.1 图书管理系统用例图

　　参与者

　　参与者是与系统、子系统或类发生交互的外部用户、进程或其他系统。参与者可以是人、另一个计算机系统或一些可运行的进程。在图2.1中，”读者”和”管理员”即为参与者。

　　参与者之间可以存在泛化关系，例如，在图2.1所示图书馆管理系统用例图中，可以认为”读者”是”学生读者”和”教师读者”的泛化，而”学生读者”还可以具体化为”本科生读者”和”研究生读者”；同样，”图书管理人员”也是”采购员”、”编目员”及”借阅人员”的泛化。图2.2表示出了参与者之间的泛化关系。

图2.2 参与者泛化关系

　　用例

　　用例是外部可见的一个系统功能，这些功能由系统所提供，并通过与参与者之间消息的交换来表达。用例的用途是在不揭示系统内部构造的情况下定义行为序列，它把系统当作一个黑箱，表达整个系统对外部用户可见的行为。

　　鉴于用例的特点，用例一般被命名为一个能够说明目标的动名词组。如图2.1中的”借书”、”还书”和”管理图书”皆为动名词组。

　　用例之间也可以存在包含、扩展和泛化等关系：

　　（1）包含关系：用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分，这被称作包含关系。

　　（2）扩展关系：扩展关系是从扩展用例到基本用例的关系，它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。它是以隐含形式插入的，也就是说，扩展用例并不在基本用例中显示。在以下几种情况下，可使用扩展用例：

　　a.表明用例的某一部分是可选的系统行为（这样，您就可以将模型中的可选行为和必选行为分开）；

　　b.表明只在特定条件（如例外条件）下才执行的分支流；

　　c.表明可能有一组行为段，其中的一个或多个段可以在基本用例中的扩展点处插入。所插入的行为段和插入的顺序取决于在执行基本用例时与主角进行的交互。

　　图2.3给出了一个扩展关系的例子，在还书的过程中，只有在例外条件（读者遗失书籍）的情况下，才会执行赔偿遗失书籍的分支流。

图2.3用例扩展关系

　　（3）泛化关系：用例可以被特别列举为一个或多个子用例，这被称做用例泛化。当父用例能够被使用时，任何子用例也可以被使用。如在图2.4中，订票是电话订票和网上订票的抽象。

图2.4用例泛化关系

通讯关联

　　通讯关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些用例（或者说系统所提供的用例被哪些参与者使用）。

　　通讯关联以箭头或实线表示。若使用箭头，箭头所指方将是对话的被动接受者；如果不强调对话中的主动与被动关系，则可以使用不带箭头的关联实线。

　　2.2建立用例模型

　　知道了用例与用例图的概念，我们还需要懂得怎样建立用例模型，即怎样找出参与者、用例以及定义用例的过程。一般来说，建立用例模型的步骤为：

　　（1）确定谁会直接使用该系统，即参与者（Actor），为了发现参与者，我们可以尝试问如下问题：

　　a. 谁/什么使用系统？

　　b. 谁/什么从系统获得信息？

　　c. 谁/什么向系统提供信息？

　　d. 谁/什么支持、维护系统？

　　e. 哪些其它系统使用此系统？

　　f. 公司的哪个部门使用系统？

　　…

　　（2）选取其中一个参与者；

　　（3）定义该参与者希望系统做什么，参与者希望系统做的每件事成为一个用例，为了发现用例，我们可以尝试问如下问题：

　　a. 为什么该参与者想要使用此系统？

　　b. 该参与者是否要创建、保存、更改、移动或读取系统的数据？如果是，为什么？

　　c. 该参与者是否要通知系统外部事件或变化？

　　d. 该参与者是否需要知道系统内部的特定事件？

　　…

　　（4）对每件事来说，何时参与者会使用系统，通常会发生什么，这就是用例的基本过程；

　　（5）描述该用例的基本过程；

　　（6）考虑一些可变情况，把他们创建为扩展用例；

　　（7）复审不同用例的描述，找出其中的相同点，抽出相同点作为共同的用例；

　　（8）重复步骤2-7找出每一个用例。

　　参与者检查的参考标准如下：

　　（1）是否您已找到所有的参与者？也就是说，是否您已经对系统环境中的所有参与者都进行了说明和建模？

　　（2）每个参与者是否至少涉及到一个用例？

　　（3）您能否列出至少两名可以作为特定参与者的人员？

　　（4）是否有参与者担任与系统相关的相似参与者？如果有，您应该将他们合并到一个参与者中。

　　用例检查的参考标准如下：

　　（1）用例模型的简介部分简明清晰地概述此系统的目的和功能；

　　（2）所有的用例已确定，这些用例共同说明所有的必要行为；

　　（3）所有的功能性需求都至少映射到一个用例；

　　（4）该用例模型不包含多余的行为，所有的用例都可回溯到某个功能性需求来证明其合理性。

　　用例图从总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有一个总体的认识，仅此还是不够的，我们还需要描述每一个用例的详细信息，即用例规约。用例模型正是由用例图和每一个用例的详细描述――用例规约所组成的。RUP中提供了用例规约的模板，包含以下内容：

　　（1）简要说明 (Brief Description)：简要介绍该用例的作用和目的；

　　（2）事件流 (Flow of Event)：包括基本流和备选流，事件流应该表示出所有的场景；

　　（3）用例场景 (Use-Case Scenario) ：包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的；

　　（4）特殊需求 (Special Requirement)：描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）；

　　（5）前置条件 (Pre-Condition)：执行用例之前系统必须所处的状态；

　　（6）后置条件 (Post-Condition)：用例执行完毕后系统可能处于的一组状态。

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

Technorati : uml

第一讲：统一建模语言UML轻松入门之基本慨念

admin — Sat, 20 Jun 2009 06:57:23 +0000

(本文转自”天极软件”，作者: 宋宝华，出处: http://dev.yesky.com/356/2438356_1.shtml)
20 世纪80 年代，随着面向对象技术成为研究的热点，先后出现了几十种面向对象的软件开发方法。其中，Booch、OMT 和OOSE等方法得到了广泛的认可。然而，采用不同方法进行建模不利于开发者之间的交流。而UML则统一了Booch、OMT 和OOSE 的表示方法，而且对其作了进一步的发展。1997 年，UML 被国际对象组织OMG采纳为面向对象的建模语言的国际标准，它溶入了软件工程领域的新思想、新方法和新技术。UML不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。数年来，UML凭借其简洁明晰的表达方式、超凡脱俗的表达能力，一路杀将出来，为业界所广泛认同！目前，在多数大型企业的正规化开发流程中，开发人员普遍使用UML进行模型的建立。作为一名软件开发人员，我们必须学会UML。因为UML就是那个统一的”文字”，统一的”度”、”量”、”衡”，不理解UML，作为软件设计统一王国的国民，将是艰难而痛苦的。

　　作曲家会将其脑袋中的旋律谱成乐曲，建筑师会将其设计的建筑物画成蓝图，这些乐曲、蓝图就是模型(Model)，而建构这些模型的过程就称为建模 (Modeling)。软件开发如同音乐谱曲及建筑设计，其过程中也必须将需求、分析、设计、实现、布署等各项工作流程的构想与结果予以呈现，这就是软件系统的建模。

　　那么为什么要建模呢？经典答案是：建立大厦和建立狗窝的区别是建设狗窝不需要设计，要生产合格的软件就要有一套关于体系结构、过程和工具的规范。

　　OMG官方发布的UML的当前最高版本为2.0，可以从http://www.uml.org/上下载。

　　UML由图和元模型组成，图是语法，元模型是语义。UML主要包括三个基本构造块：事物（Things）、关系（Relationships）和图（Diagrams）。本次连载我们将对UML的这些基本组成部分及UML工具和应用进行介绍，使读者对UML形成初步的整体印象。在其后的几次连载里，再以数个实例对这些内容逐步展开。

　　1.1 UML的基本构造块

　　1.1.1事物

　　事物是是实体抽象化的最终结果，是模型中的基本成员，UML中包含结构事物、行为事物、分组事物和注释事物。

　　（1）结构事物（Structural things）

　　结构事物是模型中的静态部分，用以呈现概念或实体的表现元素，是软件建模中最常见的元素，共有以下七种：

　　类（Class）：类是指具有相同属性、方法、关系和语义的对象的集合；

　　接口（Interface）：接口是指类或组件所提供的服务（操作），描述了类或组件对外可见的动作；

　　协作（Collaboration）：协作描述合作完成某个特定任务的一组类及其关联的集合，用于对使用情形的实现建模；

　　用例（Use Case）：用例定义了执行者（在系统外部和系统交互的人）和被考虑的系统之间的交互来实现的一个业务目标；

　　活动类（Active Class）：活动类的对象有一个或多个进程或线程。活动类和类很相象，只是它的对象代表的元素的行为和其他的元素是同时存在的；

　　组件（Component）：组件是物理的、可替换的部分，包含接口的集合，例如COM+ 、JAVA BEANS等；

　　结点（Node）：结点是系统在运行时存在的物理元素，代表一个可计算的资源，通常占用一些内存和具有处理能力。

　　（2）行为事物（Behavioral things）

　　行为事物指的是UML模型中的动态部分，代表语句里的”动词”，表示模型里随着时空不断变化的部分，包含两类：

　　交互（ineraction）：交互是由一组对象之间在特定上下文中，为达到特定的目的而进行的一系列消息交换而组成的动作；

　　状态机（state machine）：状态机由一系列对象的状态组成。

　　（3）分组事物（Grouping things）

　　可以把分组事物看成是一个”盒子”，模型可以在其中被分解。目前只有一种分组事物，即包（package）。结构事物、动作事物甚至分组事物都有可能放在一个包中。包纯粹是概念上的，只存在于开发阶段，而组件在运行时存在。

　　（4）注释事物（Annotational things）

　　注释事物是UML模型的解释部分。

　　1.1.2关系

　　关系是将事物联系在一起的方式，UML中定义了四种关系：

　　（1）依赖（Dependencies）：两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义；

　　（2）关联（Association）：一种描述一组对象之间连接的结构关系，如聚合关系（描述了整体和部分间的结构关系）；

　　（3）泛化（Generalization）：一种一般化-特殊化的关系；

　　（4）实现(Realization) ：类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。

　　1.1.3图

　　图是事物集合的分类，UML中包含多种图：

　　（1）类图(Class Diagram)：类图描述系统所包含的类、类的内部结构及类之间的关系；

　　（2）对象图(Object Diagram)：对象图是类图的一个具体实例；

　　（3）包图（Package Diagram）：包图表明包及其之间的依赖类图；

　　（4）组件图(Compoment Diagram，也称构件图)：组件图描述代码部件的物理结构以及各部件之间的依赖关系；

　　（5）部署图(Deployment Diagram)：部署图定义系统中软硬件的物理体系结构；

　　（6）用例图(Usecase Diagram)：用例图从用户的角度出发描述系统的功能、需求，展示系统外部的各类角色与系统内部的各种用例之间的关系；

　　（7）顺序图(Sequence Diagram)：顺序图表示对象之间动态合作的关系；

　　（8）协作图(Collaboration Diagram)：合作图描述对象之间的协作关系；

　　（9）状态图(Statechart Diagram)：状态图描述一类对象的所有可能的状态以及事件发生时状态的转移条件；

　　（10）活动图(Activity Diagram)：活动图描述系统中各种活动的执行顺序。

　　上述十种图可归纳为五类，如表1.1。

　　表1.1 UML图分类

类型	包含
静态图	类图、对象图、包图
行为图	状态图、活动图
用例图	用例图
交互图	顺序图、协作图
实现图	组件图、部署图

1.2 UML工具与应用

　　”工欲善其事，必先利于器”，为了有效的利用UML，我们需要首先获得一个UML工具软件。

　　当前，业界使用最广泛的UML建模工具为Rational Rose。Rational Rose中可实现正向（为模型产生相应的代码）、逆向（从用户原来的软件系统导出该系统的模型）和双向工程（实现模型和代码之间的循环工程），从而保证模型与代码的高度一致。Rational Rose支持C++、Visual C++、Java、Smalltalk、Ada、Visual Basic、PowerBuilder等语言和开发工具，并能为CORBA 应用生成接口定义语言（IDL），为数据库应用生成数据库描述语言（DDL）等。另外，Rational Rose为团队开发和规范的开发过程管理提供了良好的支持。
对于小规模应用，我们可以使用微软公司Office套件中的Visio，其中提供了对UML各种图的绘制支持。

　　从应用的角度上来讲，面向对象的系统设计一般需要完成如下工作：

　　（1）描述需求；

　　（2）根据需求建立系统的静态模型；

　　（3）描述系统的行为。

　　（1）和（2）中所建立的模型是静态的（采用用例图、类图、对象图、组件图和部署图等），是标准建模语言UML中的静态建模机制；而（3）中所建立的模型则表示执行时的序列、状态或交互关系（以状态图、活动图、顺序图和协作图描述），是标准建模语言UML中的动态建模机制。

　　由此可以看出，标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。

　　此外，需要说明的是，UML只是一种建模语言，它独立于具体的建模过程。因此，利于它建模时，可遵循任何类型的建模过程。尽管如此，UML的作者们为我们推荐了RUP（Rational Unified Process）。RUP由Rational软件公司首创，其最重要的特点有三：

　　（1）软件开发是由用例驱动的；

　　（2）软件开发是以体系结构设计（Architectural Design）为中心；

　　（3）软件开发是个迭代过程。

　　RUP包括四个阶段，每个阶段又分为若干次迭代，每次迭代都有一个核心工作流，如图1.1所示。

图1.1 RUP的流程

Technorati : uml