“那只青蛙”的《软件方法》读后感

那只青蛙

在读《软件方法》之前,我对UML的认识还停留在画图表达自己的逻辑与同事交流的阶段。当然《软件方法》也不是一本纯粹的UML书籍,潘加宇用工作流建模方式讲述了实践愿景、业务建模和系统用例在创建系统的使用。作者在这本书中犀利的表达了自己对软件和建模的理解,每个章节都有思维引导和误区提示,给了我很多启发和提示,全书只有241页,生动有趣,图文并茂,阅读起来相对轻松。

潘加宇在传统的软件过程:需求->设计->开发->测试前面增加了业务建模环节。业务建模通过UML的业务用例图和业务序列图,让开发人员抛弃技术思维,审视付钱的组织需要什么样的系统,我开发的系统应该摆放的位置。技术的思维固然重要,前提是当我们在实现系统的时候;用技术思维去分析系统需求会做出一个正确而无用的系统,这样的系统会让销售无奈。所以业务建模的目的就是分析组织,找到组织需要改进的业务逻辑,找到自己系统的定位,让系统有价值起来。

思维导图

nazhiqingwa.jpg

结合思维导图,表达一些对作者观点的理解:

核心工作流:业务建模、需求、分析和设计。

思考边界:每个工作流都有自己的核心内容,而工作流之间又有很多相似内容,区分出思考边界,关注工作流的核心内容。整本书中都在帮助读者确认和明确工作流的思考边界,帮助读者建立更明确的模型。

愿景定义业务建模是对愿意购买软件的组织的研究,这个组织可以是一个单位,也可能是一群志趣相投的人。愿景定义为组织勾勒一份蓝图,业务建模通过对组织业务流程的表达和分析推导出系统。这样的系统是一个有价值的系统,因为它的价值体现在它参与了组织业务流程。它替代组织内一部分人的工作,而且系统可以快速而准确的做完这份工作并且任劳任怨。

在得到一个有价值的系统之后,系统用例用例规约的目的为系统生成有价值的需求,把系统看做黑盒子,用例执行者(Actor)是系统与外界交互的输入和输出,这样系统为Actor提供的价值就是系统用例。用例规约是对用例的细致描述,通过涉众排位,可以确认出需求优先级的高低。

涉众(stakeholder)也是作者多次提到的概念。作者把传统的用户拆分成了“用例执行者”和“涉众”两部分,这个让我认识业务建模的思路开阔了很多。例如把研究铁路售票处这个组织,如果先入为主的认为售票员是用户,把售票员作为一个重点研究对象的话,会严重束缚系统的业务建模。铁路售票处有多个涉众:旅客,铁路总公司以及政府(中国特色)。旅客关心能不能别让我排一天队买票,能不能买到票;铁总和政府希望旅客能有秩序的买票,不要闹事,不要被电视台曝光等等;虽然涉众不直接操作系统,但是在在组织中的地位明显高于售票员。于是乎12306出现了,网上售票售票员在这个系统中已经消失了,去找售票员问需求是不是走错了路!

阿布思考法分为两步骤:

1、假设有充足的资源去解决问题,得到一个完美的方案;

2、用手上现有的资源区山寨这个完美的方案;

这种隐喻方式把系统改进方法描述的淋漓尽致,让开发者充分发挥想象力,制定一个完美的目标,当然完美的目标结合现实创造出的产品已经足以惊艳全世界了。乔布斯和他的苹果就是这样征服世界的。

这不仅仅是一本技术书架,书中穿插讲述的思维方式会让开发人员受益匪浅,期待作者的后续作品。


weixinpanjiayu2.jpg