厌倦了code，但是时间不能白白逝去
没有思考，那就漂泊吧
我在网络上泊啊泊啊，终于开始了思考
思考如果在本领域中，做什么才能更有竞争力
想啊想啊，想到了点什么
然后分析啊分析，看了很多文章
这个心里啊，严重受到了创伤
才发现，自己就像一只没有翅膀的小鸟，来到了一个全是彪悍飞行者的行列
我挣啊挣啊，努力把翅膀长出来
却发现只是个小肉疙瘩
继续泊 继续挣
好玩 有点刺激
兴奋
再出色的女人，如果身边空空，就使人觉得凄凉。比如张爱玲，她的感情生活就像李碧华所说，是一口古井，任由后人来淘出的都是一地清冷月光。
夫唱妇随，才能交相辉映，。
同样再出色的人（这次不分男女了哈），如果孤军奋战的话，也会使人觉得凄凉。不过我们就不一样了，我们是一个小家庭，不论是感情生活还是技术
生活都是一片汪洋，随你怎么淘，淘出的都是金色的阳光。
呵呵，漂起来了。。。。。。
提交作品了，心里的石头也放下了一块，回头看看这一个多月的时间，真的是成长了许多，无论是技术上的，还是团队合作和管理上的。技术上，
虽然写的文章总被人批评，不过至少有人对我的文章有兴趣，也算是另一种安慰啦。团队合作上，平时不觉得，真到了在一起做项目的时候，才发现每个人都和以前
不太一样啊。也是通过这次大赛，让我发现了每个人的另一面。团队管理上，呵呵，说来惭愧啊，没为大家做什么事，而且虽然只有3个人，不过这个队伍也不好带啊。虽然有争执，虽然有困难，可是我们还是坚持下来了，不是吗？
怎么说呢，在这段日子里，虽然有一些事让我生气，但是，也有很多事情令我感动。是大家的坚持，我们才会走到今天，才会完成作品。
所以，无论我是要哭泣着，还是微笑着与你道别
人生本就是一场难分悲喜的演出，
而当灯光照过来，
我就要必须唱出那最最艰难的一幕，
曲终人散后，
无论我是要哭泣着，
还是微笑着与你们道别，
我都会庆幸曾与你们同台。
昨天我和蓝凝花了一下午时间把所有文档再过了一遍，晚上再就把文档全部转换成pdf格式，打包压缩，最后再一次检查。看着作品被发出去，轻松了好多...终于忙完了，可以好好休息一下了。
对IBM的SOA大赛的了解是一次非常偶然的机会，四月中旬IBM在北航有一个SOA的技术讲座，当时还并不知道有SOA这样一个大赛，只是觉得讲座内容跟自己的研究方向有很多相关之处，去听一听应该会有不少收获。讲座开始之前，我首先拿到了SOA大赛的宣传单，当时便给蓝凝和crazycy发短信，把他俩也召唤了过来，讲座完后我们三人决定组队参加SOA比赛。然而，团队的成立，却没有我们想的那么快，之后，我被派去外地出差，接着，实验室技术汇报，项目阶段评审等等一系列的事情接踵而来，一直到5月中旬，大家才开始闲下来。2006年5月16日，这是一个特殊的日子，这一天，我们的SOA团队正式成立。我和crazycy一致推举蓝凝为我们的组长，她是团队里的唯一女生，也是我和crazycy平时经常所称的“老大”。组长蓝凝为团队取名吉祥三宝，这是一个非常幸福的名字，希望能给我们带来好运。在后面将近一个半月的日子，我们一起交流，共同探讨。对SOA所涉及技术的广博，都暗暗赞叹，对参加这样一个大赛，欣喜不已。
现在，我们只有静静的等待评审结果，同时好好整理前面学习的东西，SOA虽然只是一种思想，但其所牵涉到的技术是非常多的，只有善于总结，才能走得更远。
搞笑啊，因为每次都是默认的用户名，结果，前几天把用户名给忘了，怎么也上不来了，把我急的啊~~~
看着那么多批评我文章的话，我有话没地方说，更急~~~~
结果牙也肿了，眼睛还长东西，~~~~~~
现在好啦，事基本都忙得差不多啦，晚上提交附件，而且也把用户名给想起来啦，上来喊两声，嘿嘿，兄弟们，我又回来啦
共同工作：
查找相关资料
分析题目
讨论需求
业务流程分析
技术学习
个人分工
姓名 工作 备注
dubb CRM相关资料及接口分析
1.
crazycy
liuli 1.ERP
1.2.2 整体分工：
姓名 工作 备注
dubb 协调工作
会议的组织
进度的安排
相关技术的学习 会议的纪要由每个人轮流整理
每次会议有一个主要的发言人
crazycy 相关团队消息的跟踪
相关网站的跟踪
相关技术的学习 相关技术的学习，liuli相对来说多一些
liuli 相关工具的掌握
相关会议的跟踪
相关技术的学习
1.2.3 文档设计阶段
时间 任务 负责人 备注
2006.6.10至2006.6.18 业务模型的分析设计 liuli 这是个迭代的过程，与服务建模交互
2006.6.13至2006.6.20 服务模型分析设计 dubb ,liuli帮助修改了文档
2006.6.18至2006.6.23 系统架构设计 liuli，crazycy 用例模型分析和数据模型分析由liuli完成
2006.6.23至2006.6.27 组件设计 crazycy 以上过程均是迭代的过程
2006.6.23 项目综述 dubb
2006.6.25 设计实施计划 dubb
2006.6.27至
2006.6.28 整体文档的检查 全体成员 每个文档都是经过了数次迭代与修改，在所有文档完成后，大家由一起将所有的文档进行了检查，包括：
格式，内容，标点符号，图形等。
嘿嘿，happy即将，高兴一个。
没有参加6月6号的“IBM WebSphere Live 2006”，现在看来着实是这次竞赛中的一大败笔；
当时一些私人事情，在团队理解支持的情况下，暂放下团队备战长达10余天，也没参加这个讲座。
现在文档全部完成，回头再读 蓝凝 写的“IBM会议纪要（二）”，结合在完成分析的过程中所产生的疑惑，以及思考、解决的过程，实际上完全可以得益于那次讲座。
留一个懊悔的脚印，以杜绝日后同类事件的再次发生。
这几天光顾着在下面忙，好久没来发帖了，上来汇报一下工作进度：在大家的通力合作，埋头苦干之下，系统架构设计文档、业务模型分析设计文档、服务模型分析设计文档、系统架构设计文档、组件设计文档已经大体确定下来，部分已经完成初稿。不过革命尚未成功，同志仍需努力，等忙完大家好好happy一下...
刚刚看了一下，有17个团队提交了最后作品，还好，不是很多啊，窃喜:) 估计很多团队都跟我们一样，在紧张地准备最后作品呢。这两天突然发现，大赛初期看的很多文章现在回头看看，颇有感觉啊，呵呵，温故而知新，可以为师矣，这段时间还是学到了不少东西的。等有时间了，一定要把这一个半月学的东西好好整理一下，继续工作了，相信我们能做的更好。
摘要: 组建过工作室，也参加过一些小团队。今又参与
PPT
演讲组，后来转型为
SOA
竞赛小组。对团队，哦，确切的说，类似上述列举的小团队，列出几点体会：
首先一个团队，要长久、良性的运转，团队成员应该具有相似的价值取向，至少是认可不反对，这一点是一个良性团队之底基。
... 阅读全文
摘要: 本系列文章目录结构
... 阅读全文
摘要: 本系列文章目录结构
①
... 阅读全文
摘要: 本系列文章目录结构
① 我对 SOA 的认识（一）（结合平时累积的笔记，不排除有引用） ( 修改版 )
② 我对 SOA 的认识（二）（结合平时累积的笔记，不排除有引用）
③ &n... 阅读全文
终于收到IBM大赛的ERP和CRM资料了，看了一下邮戳，17号寄出来的，现在才收到...稍微抱怨一下，为什么外省参赛团队的软件和资料总是比我们收到的要早，郁闷:( 不过还好，ERP的资料我们早就通过其他方式得到了，CRM的资料也就一个文档，对后期工作影响不大，继续工作中...
SOA相关资料查找分析
TurboCRM分析完毕
用友ERP分析完毕
题目要求的业务流程分析完毕
需求分析完毕
业务流程图分析讨论完毕
需要工具安装完毕
业务建模完毕
听说周六有IBM的技术讲座，哪能错过，赶紧注册。。。。
周六早上起了个大早，和liuli一起到体育馆门口等IBM的车，到了体育馆才发现，已经有n多xdjm在等了。看来同志们对soa还是很感兴趣的啊。不过，让人ft的是等了好久都不见车来，已经9点钟了，人群开始散去，这时候，我和liuli立刻做出了一个决定，不能再等了，自己做车去。于是我们俩跑到了知春路去做公交车。
好不容易到了，会议已经开始40多分钟了，门口的IBM工作人员问了我们班车的情况，我们宣泄了一下不满，因为有好多人因为车没来就放弃参加了，如果不是之前IBM发信说有班车来接的话，然后早上等了一个多小时车没来，他们肯定会来的。
听了一天，就IBM的产品来说总体感觉就是比较人性化，我指的是提供了图形界面的工具已经自动的代码生成工具。因为，在下午有个环节是拿微软和IBM比较，比较的内容是将已有的功能包装成服务并发布，两位博士一个负责用IBM的产品，另一个用的是微软的产品，同时进行。在大屏幕上可以清晰的看见IBM的执行过程全部是图形界面，其间并没有涉及到具体的代码；而微软的产品并没有图形界面，所有的操作看来就是一个程序员在写程序一样，结果可想而之，速度当然比不上IBM而且其复杂程度也对程序员有很高的要求，即必须知道底层代码及所有的环节才行。
不过，我在想，如果微软也把同一套流程做成了图形界面，同时添加了代码自动生成的功能，那么那时候，两者再比较，结果会是什么样呢？
ps：liuli在用WBI的时候，发现了不少的bug。
经过以前的数次讨论，方案终于定了下来，在接下来的日子里，每个人负责不同的部分，开始进入各种文档的实现阶段。
我负责写总体的需求文档，虽然以前写过类似的什么需求分析啊，概要设计啊，相信设计等等，但是，这次的需求文档还是花了我很多的心思。
在写之前特别又看了一遍《需求分析黄金法则》那20条，写了一个晚上，一气呵成，不过不知道是因为文笔退步还是别的原因，写出的文档，大家不是很满意，
咳，严重郁闷中。
·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。
·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。
·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。
·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。
这几项都有包括啊，回头问问差在哪里了。
虽然大赛并没有要求提供需求分析文档，但是需求在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用，所以，就像软件工程的流程一样，一切从需求开始，一切文档化。
接着修改。。。。。。。
WBI Modeler是IBM WebSphere Business Integration Modeler简写，主要用于对业务流程建模，其用户角色是业务分析人员，对使用者不要求有编程经验。说白了，只要是对业务熟悉的人都可以使用这个软件。这样，使得业务分析人员可以把重点放在业务的优化和流程本身上，而不用考虑后期的IT设计和实现。
WBI Modeler是基于Eclipse开发的建模工具，其界面也和Eclipse有很多相似之处，用过Eclipse的人上手应该更快，基于Eclipse开发使其可轻松地与其他一些架构集成。此外，WBI Modeler还提供了对visio的支持，可以很容易地将visio画的流程图转换成WBI Modeler中的流程图，前提是必须建立visio中的部件和WBI Modeler中部件的一一对应。总的来说，WBI Modeler功能很强大。WBI Modeler提供的建模方式能大大加快业务建模的速度，并且将各种业务流程以非常美观的方式展现给用户和后期设计以及开发人员。
关于WBI Modeler的好处不多说了，IBM做的宣传已经够多了，下面说一说WBI Modeler的不足之处：首先是快捷键，快捷键大部分集中在过程编辑器中，而其他一些地方却没有，我感觉在项目树视图中加入快捷键是很有必要的，使用频率很高，如果今后能提供将大大提高开发效率；其次是目前没有批量处理功能，比如说过程或者任务的导出导入，只能一个一个的导出或者导入，这样效率太低了，浪费不必要的重复劳动时间；再次，有些细节感觉没有考率到，比如在过程编辑器中缺少全部选择的功能，此外，WBI Modeler提供的帮助太简单了，这是个小问题，相信以后会增加的。最后，WBI Modeler存在一个比较严重的bug，当建立某个业务过程时出现错误时，如果你将这个过程直接删除，可能会遇到删完之后过程还存在的情况，这时整个项目都不能用了。我已经遇到过两次这样的情况了，解决办法是重新建立一个项目，再把原来有用的东西导出再导入新项目。
时间弗多,战线告急,我等需快马加鞭,提高效率,减少拖沓,驱除墨迹,好好干一把.
按照事情之"紧急重要、紧急不重要、不紧急重要、不紧急不重要"的划分，我等当前之备战严重属于最紧急最重要一环；于今１８严重预警，望各位严阵以待，全力出击．
严格保证６.１４预计的进度．
摘要: 注意：这周六有技术讲座：创新业务,拓展商机 - 为您打下坚实的SOA基础
通过现场演示和技术讨论，您将了解到 IBM WebSphere优于其他供应厂商的解决方案,以及如何更好地实现面向服务的架构。您还将了解到如何提高您当前的业务流程的速度、准确性和成本效益。同时,您将了解 IBM WebSphere 信息管理解决方案是如何支持提供准确的、一致的、及时而连贯的业务信息。在讲座中，我们还将讨论... 阅读全文
花了一上午时间寻找WBI并安装成功，正准备学习怎么使用，下午IBM的软件终于也到了，意味着我上午的工作基本白费，郁闷。IBM的软件来得有点晚，今天已经15号了，距离最后提交正式结果还有两周时间，时间紧迫。
两周时间虽然很紧，但如果充分利用也是足够的，前一段时间刚好给了我们充足的时间分析业务，大家对SOA的思想和相关技术也了解的差不多了，抓紧时间，加油干吧。