软件方法(上):业务建模和需求(第2版) - (EPUB全文下载)

文件大小:0.51 mb。
文件格式:epub 格式。
书籍内容:

软件方法(上):业务建模和需求(第2版)
第1章 建模和UML
第2章 业务建模之愿景
第3章 业务建模之业务用例图
第4章 业务建模之业务序列图
第5章 需求之系统用例图
第6章 需求之系统用例规约
第7章 需求启发
书评
第1章 建模和UML
牵着你走进傍晚的风里,看见万家灯火下面平凡的秘密。
《情歌唱晚》;词:黄群,曲:黄群,唱:曹崴;1994
1.1 粗放经营的时代已经远去
改革开放初期,中国出现了许多农民企业家,他们不用讲管理,也不用讲方法,只要胆子大一点,就能获得成功,因为当时的市场几乎空白,竞争非常少。农民企业家的思路很简单:人人都要吃饭,所以开饭馆能够赚钱。现在这样的思路已经行不通了。市场竞争已经足够激烈,十家新开张的饭馆恐怕只有一家能撑下来,所以农民企业家已经很少见(连农民都越来越少了)。软件业也一样,最开始的时候,会编程就了不得,思路也很简单:每个公司都要做财务,所以开发财务软件能赚钱。现在呢?我们想到一个“点子”,可能有上千人同时想到了;我们要做一个系统,可能发现市场上已经有许多类似的系统。你卖高价,他就卖低价,你卖低价,他就干脆免费。机会驱动、粗放经营的时代已经远去,为了在激烈的竞争中获得优势,软件开发组织需要从细节上提升技能。
本书聚焦于两方面的技能:需求和设计。关于需求和设计,开发人员可能每天都在做,但是否理解背后的道理呢?我们来做一些题目:
本书不提供练习题答案,请扫码或访问http://www.umlchina.com/book/quiz1_1.htm完成在线测试,做到全对,自然就知道答案了。
1.软件开发中需求工作的目的是________。
A)让系统更加好卖
B)更好地指导设计
C)对系统做概要的描述
D)满足软件工程需求规范
2.软件开发中设计工作的目的是________。
A)对系统做详细的描述
B)更好地指导编码
C)降低开发维护成本
D)满足软件工程设计规范
1.2 利润=需求-设计
利润=收入-成本。不管出售什么,要获得利润,需要两个条件:
(1)要卖出好价钱;
(2)成本要低。
妙就妙在,价格和成本之间没有固定的计算公式,这正是创新的动力之源。放到软件业上,我也炮制了一个公式:
利润=需求-设计
在软件开发中,需求工作致力于解决“提升销售”的问题,设计工作致力于解决“降低成本”的问题,二者不能相互取代。能低成本生产某个系统,不一定能保证它好卖。系统好卖,如果生产成本太高,最终还是赚不了多少钱。
如果需求和设计不分,利润就会缩水。从需求直接映射设计,会得到大量重复代码;如果从设计出发来定义需求,会得到一堆假的“需求”。
拿自古以来就有的一个系统“人体”来举例。人体的功能(能做什么)是走路、跑步、跳跃、举重、投掷、游泳……但是设计人体的结构时,不能从需求直接映射到设计,得到“走路子系统”“跑步子系统”“跳跃子系统”……人体的“子系统”是“呼吸子系统”“消化子系统”“循环子系统”“神经子系统”……“子系统”不是从需求直接映射出来的,需要设计人员的想象力——本例子的设计人员就是造物主了。同样,也不能从设计推导出需求:因为人有心肝脾肺肾,所以人的用例是“心管理”“肝管理”(见图1-1)。
图1-1 人体的需求和设计
水店老板要雇一个民工送水(即租用一个人脑系统),他只要求这个民工能跑能扛就行,管他体内构造是心肝脾肺肾还是一块电路板;民工找工作也要从市场的需要来找,而不是从自己的内部器官出发来找——“老板,我有心脏管理功能,你请我吧!”
很多时候我们说“本系统分为八大子系统……”,其实说的是“本系统的功能需求分为八大需求包……”需求包是基于涉众视角对系统功能分包而得到的,子系统是基于内部视角根据系统部件的耦合和内聚情况切割而得到的。
需求和设计的区别简要列举如图1-2所示,在后面的章节中再慢慢阐述这些区别。
图1-2 需求和设计的区别
高焕堂在他的书《Use Case入门与实例》中说过:用例是收益面,对象是成本面。本书基于他的思想做了扩展。
1.3 建模工作流
要达到“低成本制造好卖的系统”的目标,并非喊喊口号就可以,需要静下心来学习和实践以下各个建模工作流中的技能。
1.业务建模——描述组织内部各系统(人脑系统、电脑系统……)如何协作,使得组织可以为其他组织提供有价值的服务。新系统只不过是组织为了对外提供更好的服务,对自己的内部重新设计而购买的一个零件。组织引进一个软件系统,和招聘一名新员工没有本质区别。如果通过业务建模推导新系统的需求,而不是拍脑袋得出,假的“需求变更”会大大减少。
2.需求——描述为了解决组织的问题,系统必须具有的表现——功能和性能。这项技能的意义在于强迫我们从“卖”的角度思考哪些是涉众(Stakeholder)在意的、不能改变的契约,哪些不是,严防“做”污染“卖”。需求工作流的结果——需求规约是“卖”和“做”的衔接点。
3.分析——提炼为了满足功能需求,系统需要封装的核心域机制。可运行的系统需要封装各个领域的知识,其中只有一个领域(核心域)的知识是系统能在市场上生存的理由。对核心域作研究,可以帮助我们达到基于核心域的复用。
4.设计——为了满足质量需求和设计约束,核心域机制如何映射到选定平台上实现。
软件开发人员如果缺乏软件工程方面的训练,对以上工作流没有概念,就会把这些工作产生的工件通通称为“设计”或者“文档”。例如问开发人员在做什么,回答“我在做设计”“我在写文档”,其实他的大脑可能正在思考组织的流程(业务建模),或者在思考系统有什么功能性能(需求),或者在思考系统要包含的领域概念之间的关系(分析),但他通通回答成“在做设计”“在写文档”。后来又有牛人说了:代码就是设计。本来“设计”在他脑子里就是“代码以外的东西”,这么一推导,不就变成了:代码就是一切?
很多大谈“编码的艺术”的书籍和文章,其实探讨的根本不是编码的技能,而是分析技能甚至是业务建模技能,只是作者的大脑里没有建立起这些概念而已。编码确实有编码的技能,就像医院里护士给患者输液也需要经 ............

以上为书籍内容预览,如需阅读全文内容请下载EPUB源文件,祝您阅读愉快。

版权声明:书云(openelib.org)是世界上最大的在线非盈利图书馆之一,致力于让每个人都能便捷地了解我们的文明。我们尊重著作者的知识产权,如您认为书云侵犯了您的合法权益,请参考版权保护声明,通过邮件openelib@outlook.com联系我们,我们将及时处理您的合理请求。 数研咨询 流芳阁 研报之家 AI应用导航 研报之家
书云 Open E-Library » 软件方法(上):业务建模和需求(第2版) - (EPUB全文下载)