首页 > 代码库 > 《软件方法》潘加宇 读书笔记

《软件方法》潘加宇 读书笔记

设计源于需求却高于需求。
 
《软件方法》上册(五章)所表述的逻辑:
愿景 ------ 业务建模 ------ 需求 ------ 分析 ------ 设计
 
1. 愿景: 明白软件的意义是什么,帮助或者提高了现有系统的那些方面,减少了那些成本。
                                                                利润 = 需求 - 设计
这个公式成立的前提是需求都已经实现,不同的设计会花费不同的成本。但看完上篇,我觉得应该改一改:  利润 = 业务 - 设计。  整个软件制作的过程中,真正的价值和输出是业务,对业务有什么帮助、提高或者减少业务成本。从业务的分析、愿景再到需求的分析之间有一定的距离和不同的理解方式,这一点也很重要。
 
2. 业务建模:研究 业务用例和业务对象。 业务建模主要是研究这个组织,描述现在的业务事实,划分业务的边界,分析出各个参与方的现象及状况。 反过来给组织一个购买系统的理由,给系统赋予实际的价值。
 
注:业务和需求分析是两个方面,业务注重对现实的描述,需求是针对于系统的分析。业务不一定和需求是一一对应的关系。业务是现实的描述,一般是不会变化的;但需求可以用不同的方式实现,并且从不同的角度出发看业务时,看到的需求也是不一样的。
 
3. 需求 : 研究系统系。统执行者,是指系统外与该系统发生功能性交互的其他系统。 系统用例,系统为执行者提供的、渉众可以接受的价值。 系统用例的粒度,从业务的角度出发去思考这个问题,用例就是为了给系统的执行者用。
 
技术分享 
 
 
  • 第一章 建模和UML

 
1. 该章主要讲软件方法的价值和思路,然后确定本书的观点:建模和软件开发完美的工作流【业务建模-需求-分析-设计】
 
技术分享 
2. 各个义务模块思考的焦点不一样,从上到下是有严格先后顺序的。
 
 
  • 第二章 愿景

 
1. 回答问题,“在老大看来,为什么要引进这样的系统?”
2. WHO的问题:分析清楚相关的涉方,涉及到的组织和系统,利益相关方。
3. WHY的问题:为什么要做这些,现在遇到的问题是什么,系统需要提高那一部分,或者减少那一部分的开销。
4. 设定可度量的目标,量化系统的指标和价值。
5. 分析利益相关方,从不同的涉方去看待系统,明确系统的定位。
 
 
  • 第三章 业务建模 之 业务用例图

 
1. 中心思想:软件是组织的零件。书中认为组织和人都可以当做是一个系统,而有没有软件组织都可以进行下去。所以软件就是组织的零件,在业务建模和描述业务的过程中找到组织的弱点,可以改进的地方和可以用系统来代替的地方。然后确定系统的作用,进而分析和设计系统。
2. 用例分析对象是现存的组织,分析流程:  选定要改进的组织--组织的业务用例图
3. 选定要改进的组织:
    a). 分析现有的业务组织,列出现有相关业务的参与方;
    b). 通过愿景的分析,将涉方画在一个圈里作为研究对象, 这里的涉方有可能是系统,也有可能是组织,也有可能是一个人; 
    c). 从客户的角度分析现有各个组织的功能,可以利用时序图和用例图分析,搞清楚面对客户和提供某一项服务时,各个系统之间的协作状况; 
    d). 寻找可以改进的地方和系统的价值所在,在时序图的分析完成之后可以观察时序图,找到系统所要实现的业务模块。
4. 组织业务用例:
    a). 业务的执行者:选定要改进的组织之后需要分析系统所承担的业务。第一就是要找到业务的执行者,业务的执行者可以是其他的组织,个人。【肯定是相关组织,业务的分析都是从组织层面的分析】
    b). 业务工人和业务实体。业务工人不是系统的执行者,不能和组织内的人混淆,是在组织中的人肉系统。业务执行者喝业务工人,一个在系统的外部一个在系统的内部。但这种的关系随着业务的边界有可能变化,如果包含在业务边界内部,就是业务工人,如果在业务系统的外部就有可能是业务的执行者。业务实体也是在业务边界以内充当着一定的职能,有可能是从业务工人中分离出来的机器,比如银行业务员和点钞机,银行业务员就是业务工人,点钞机就是业务实体,点钞机一定程度承担和业务工人的一部分责任,是从业务工人中分离出来的。
    c). 业务用例图: 通过业务时序图来抽象系统的用例,将业务的时序图简化为用系统零件代替。用新流程替代旧流程,明确业务执行者对相关的组织的期望是什么,是具体对哪个组织的期望。
5. 业务用例的分析目的:明确系统的价值和系统对外提供的功能,以及系统会不会达到第一点所提到的愿景。
 
 
 
  • 第四章  业务建模 之 业务序列图

 
1. 中心思想: 在业务用例分析清楚以后,开始描述业务用例的实现,系统所承担的业务流程是怎么样的,以便之后推导出有待开发的系统用例图是什么样的。
2. 业务流程描述的方法: a). 文本; b). 活动图,泳道图,分清楚各个业务组织之间的边界; c). 序列图,时序图:只涉及相关的组织和人,分析清楚交互的动作是什么,交互的内容是什么。
3. 业务序列图的要点: a). 序列图中的箭头消息代表责任而不是数据流,代表承担的功能业务是什么; b). 重点聚焦于系统之间的协作是什么,系统之间的交互是怎样的; c). 只需要关心核心模块的相关的分析; c). 可以把时间作为系统的特殊业务实体。
4. 业务建模的步骤: 
                                     现状业务序列图----改进业务序列图
    a). 现状业务序列图: 现状不是纯手工,现状不是规范,根据业务序列图要点画出现状业务序列图,了解认识现状,但不能以要分析的业务系统为中心拼凑。
    b). 改进业务序列图: 分析清楚现状之后寻找业务改进的地方。思考的点:信息化、模块划分、职责划分、流程简化、信息流改善、封装领域逻辑。【阿布思考法:假设有充足的资源解决问题,得到一个完美方案;用手上现有的资源得到一个完美的方案】
 
 
  • 第五章 需求 之 系统用例

 
1. 需求研究的对象是系统,业务研究的对象是组织。他们之间的研究对象不一样,分析的目的不同。
2. 系统执行者:在所研究的系统之外,能够与该系统发生功能性交互的其他系统。
    a). 特点是:系统外、交互、功能性交互、系统。系统外:通过业务用例和业务序列图的分析,明确系统的边界,系统边界之外的都是系统外。交互:系统的执行者除了是系统之外的还必须与系统发生交互,也通过业务用例分析的涉众来明确是否与系统发生交互。功能性交互:系统的执行者喝系统之间发生的交互是系统的功能性需求,从系统执行者来看是执行的利益点。系统:系统可以是一个人肉系统,也可以是一个非人智能系统,甚至是一个特别的外部系统(时间)。
    b). 如何识别系统的执行者:通过业务建模,识别系统的交互对象。从业务的序列图种映射系统的执行者。
    c). 用例的主执行者和辅助执行者:箭头的指向是主动的访问和消息。从用例指向的外部执行者就是辅助执行者。
3. 系统用例:系统能够为执行者提供的、涉众可以接受的价值。从执行者出发,是执行者的利益诉求点;从系统出发,是系统对相关组织的价值意义。用例思考的过程就是发现价值的过程,从两方面考虑,业务执行者的利益诉求点是什么,系统能够提供的功能是什么。
    a). 用例的粒度问题:把握住用例是面向系统,提供给执行者的用例,需要满足执行者的诉求点。
    b). 用例是执行者的动作,并不是面向数据库的CURD。用于和动词也必须是执行者能够理解的,在业务序列图种的交互动作。
    c). 如何识别系统用例:在业务序列图中,从外部指向系统的交互消息,可以映射为该系统的用例。需要明确系统的边界在哪里。
4. 需求分析中的系统用例可以直接由业务的分析而来,通过业务用例分析,到业务序列图,然后从业务序列图映射到系统的用例。
 
 
 
  • 总结

 
面向对象是一种方法论,怎么去认识真实的世界,是一种思想理论。 UML是用面向对象的思想,分析真实世界的工具和交流的语言,将真实世界翻译成与软件行业交互的语言。《软件方法》中讲述了怎么去按照面向对象的思想,用UML分析真实世界,指导帮助开发软件的方法。
 
 
 
 
 
 
 
 
 



null



《软件方法》潘加宇 读书笔记