《UML和模式应用》读书笔记

《UML和模式应用》读书 笔记 哲学笔记pdf明清笔记pdf政法笔记下载课堂笔记下载生物化学笔记PDF 第一部分 绪论 1、在OO开发中，至关重要的能力是熟练地为软件对象分配职责; 个人认为将对象进行抽象的能力也相当重要。 2、 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 (analysis)强调的是对问题和需求的调查研究，而不是解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 ;设计(design)强调的是满足需求的概念上的解决方案(在软件方面和硬件方面)，而不是其实现。 有益的分析和设计可以概括为:做正确的事(分析)和正确地做事(设计)。 3、需求分析可能包括人们如何使用应用的情节或场景，这些情节或场景可以被编写成用例(use case)。 4、面向对象分析关注从对象的角度创建领域描述，面向对象分析需要鉴别重要的概念、属性和关联。面向对象分析的结果可以表示为领域模型，在领域模型中展示重要的领域概念或对象。 5、面向对象设计关注软件对象的定义-它们的职责和协作。 6、与领域模型表示的是真实世界的类，设计类图表示的是软件类。 7、敏捷建模(agile modeling)强调了UML作为草图的方式，这也是适用UML的普通方式，而且通常对时间投入具有高回报(一般费时较短)。 8、迭代开发(iterative development)是UP和大多数其他现代方法中的关键实践。在这种生命周期方法中，开发被组织成一系列固定的短期(如三个星期)小项目，称为迭代(iteration)，每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试活动。 9、迭代开发的优点包括: 减少项目失败可能性，提高生产率，降低缺陷率。 在早期缓解高风险(技术、需求、目标、可用性等等)。 早期可见的进展。 早期反馈、用户参与和调整，会产生更接近涉众真实需求的精化系统。 可控复杂性;团队不会被“分析瘫痪”或长期且复杂的步骤所淹没。 一次迭代中的经验可以被系统地用于改进开发过程本身，并如此反复进行下去。 10、在复杂、变更系统中(如大多数软件项目)，反馈和调整是成功的关键要素。 11、如何进行迭代和进化式分析和设计: 1)在第1次迭代之前，召开第一个时间定量的需求工作会议，例如确切地定义为两天时间，业务和开发人员(包括首席架构师)需要出席。 在第一天上午，进行高阶需求分析，例如仅仅确定用例和特性的名称，以及关键的非功能性需求。这种 分析不可能是完美的。 通过咨询首席架构师和业务人员，从高阶列表中选择10%列表项，这些项 目具备以下三种性质:1，具 有重要的架构意义;2，具有高业务价值;3，具有高风险。 在剩下的一天半在结束前的一周，检查是否能够完成初始的迭代目标;如果不能，则缩小迭代的范围，将次要目标置 回任务列表中。 在最后一周的星期二，冻结代码。必须检入、集成和测试所有代码，以建立迭代的基线。 在星期三的上午，向外部涉众演示此局部系统，展示早期可视进展，同时要求反馈。 4)在第1次迭代即将结束时(如最后一周的星期三和星期四)，召开第二次需求工作会，对上一次会议的所有 材料 关于××同志的政审材料调查表环保先进个人材料国家普通话测试材料农民专业合作社注销四查四问剖析材料 进行复查和精化，然后选择具有重要架构意义和高业务价值的另外10%到15%的用例，用一到两天对其进行详细分析。 5)于周五上午，举行下一迭代的迭代 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 会议。 6)以相同步骤进行第2次迭代。 7)反复进行四次迭代和五次需求工作会，这样在第4次迭代结束时，可能已经详细记录了大约80%-90%的需求。 8)我们大概推进了整个项目过程的20%。此时，可以估计这些精化的、高质量的需求所需工作量和时间。因为具有依据现实得出的调查、反馈结论并进行了早期编程和测试，因此估计能够做什么和需要多长时间的结果会更为可靠。 9)此后，一般不需要再召开需求工作会;需求已经稳定了(尽管需求永远不会被冻结)。接下来是一系列为期三周的迭代，在最后一个周五召开的迭代计划会上选择适宜的下一步工作，每次迭代都要反复询问:“就我们现在所知，下一个三周应该完成的、最关键的技术和业务特性是什么,” 利用这种方式，经过早期探索式开发的几次迭代之后，团队将能够更准确地回答“什么、多少、何时”。 12、建模(构建UML草图……)的目的主要是为理解，而非文档。 第二部分 初始阶段 1、用一句话来概括初始阶段:预见项目的范围、设想和业务案例。用一句话来概括初始阶段要解决的主要问题:涉众是否就项目设想基本达成一致，项目是否值得继续进行认真研究。 2、需求分析的最大挑战是寻找、沟通和记住(通常是指记录)什么是真正需要的，并能够清楚地讲解给客户和开发团队的成员。 3、在统一过程中，需求按照“FURPS+”模型进行分类，这是一种有效的记忆方法，其含义如下: 功能性(Funcational):特性、功能、安全性。 可用性(Usability):人性化因素、帮助、文档。 可靠性(Reliability):故障频率、可恢复性、可预测性。 性能(Performance):响应时间、吞吐量、准确性、有效性、资源利用率。 可支持性(Supportability):适用性、可维护性、国际化、可配制性。 ”FURPS+“中的”+“是指一些辅助性的和次要的因素，比如: 实现(Implementation):资源闲置、语言和工具、硬件等。 接口(Interface):强加于外部系统接口之上的约束。 操作(Operation):对其操作设置的系统管理。 包装(Packaging):例如无力的包装盒。 授权(Legal):许可证或其他方式。 若想从生活中得到什么，必不可少的第一步就是:决定想要什么。 -本。斯坦(Ben Stein) 4、用例是文本形式的情节描述，广泛应用于需求的发现和记录工作中。 5、用例是一种优秀的方法，使领域专家或需求提供者自己编写(或参与编写)用例成为可能，并使这项工作难度降低。 第三部分 细化迭代1 基础 1、细化(elaboration)是一般项目中最初的一系列迭代，其中包括: 对核心、有风险的软件架构进行编程和测试。 发现并稳定需求的主体部分。 规避主要风险。 细化阶段是最初的一系列迭代，在这一阶段，小组进行细致的调查、实现(编程和测试)核心架构、澄清大多数需求和应对高风险问题。 2、在细化阶段可能出现的一些关键思想和最佳实践包括: 实行短时间定量、风险驱动的迭代。 及早开始编程。 对架构的核心和风险部分进行适应性的设计、实现和测试。 尽早、频繁、实际地测试。 基于来自测试、用户、开发者的反馈进行调整。 通过一系列讨论会，详细编写大部分用例和其他需求，每个细化迭代举行一次。 3、通过关联而不是属性来表示概念类之间的关系。 4、没有所谓唯一正确的领域模型。所有模型都是对我们试图要理解的领域的近似。领域模型主要是在特定群体中用于理解和沟通的工具。 5、在同一层B记录A。 B直接使用A。 B具有A的初始化数据，并且在创建A时会将这些数据传递给A。因此对于A的创建而言，B是 专家。 是对象A的创建者。 注意:对象的创建常常具有相当的复杂性，这时 最好的方法是把创建职责委派给称为具体工厂(Concrete Factory)或抽象工厂(Abstract Factory)的辅助类，而不是使用创建者模式所建议的类。 信息专家(Information Expert) 把职责分配给信息专家，它具有实现这个职责所必需的信息。分配职责应当从清晰地描述职责开始。 注意:由于耦合与内聚问题导致某些情况下，专家模式建议的方案并不合适。 低耦合(Low Coupling) 分配职责，使耦合性尽可能低。利用这一原则来评估可选方案。 控制器(Controller) 控制器是UI层之上的第一个对象，它负责接收和处理系统操作消息。 高内聚(High Cohesion) 内聚(或更为专业地说，是功能内聚)是对元素职责的相关性和集中度的度量。 多态性(Polymorphism) 纯虚构(Pure Fabrication) 间接性(Indirection) 防止变异(Protected Variations) 第四部分 细化迭代2 更多模式 1、在熟练使用UP的项目中，为早期迭代所选择的需求,是根据风险和高业务价值组织的,这样就能够尽早识别并解决高风险问题。 2、最后四个GRASP模式: 多态(Polymorphism) 当相关选择或行为随类型(类)有所不同时，使用多态操作为变化的行为类型分配职责。不要测试对象的类型，也不要使用条件逻辑来执行基于类型的不同选择。 除非在超类中具有默认的行为，否则将超类中的多态方法声明为{abstract}。 多态意味着在大部分OO语言中要使用抽象超类或接口。何时应该考虑使用接口呢,普遍的答案是，当你想要支持多态但是又不想约束于特定的类层次结构时，可以使用接口。如果使用了抽象超类AC而不是接口，那么任何新的多态方案都必须是AC的子类，这对于诸如Java和C#的单根继承语言来说将十分局限。经验的做法是:如果有一个具有抽象超类C1的类层次结构，可以考虑对应于C1中的公共方法特征标记来定义接口I1，然后声明C1来实现接口I1。 间接性(Indirection) 将职责分配给中介对象，使其作为其他构件或服务之间的媒介，以避免它们之间的直接耦合。中介实现了其他构件之间的间接性(indirection)。 “计算机科学中的大多数问题都可以通过增加一层间接性来解决”，这一格言特别适用于面向对象设计。 纯虚构(Pure Fabrication) 对人为制造的类分配一组高内聚的职责，该类并不代表问题领域的概念-虚构的事物，用以支持高内聚、低耦合和复用。注:通常作为辅助类/帮助类使用。 防止变异(Protected Variation) 识别预计变化或不稳定之处，分配职责用以在这些变化之外创建稳定接口。 幸运将会出现在规划之后。 -布兰奇.瑞基(Branch Rickey) 第五部分 细化迭代3 中级主题 1、一个UML活动图表示一个过程中的多个顺序活动和并行活动。这些活动图有助于对业务过程、工作流、数据流和复杂算法进行建模。 基本的UML活动图表示法包括: 动作(action)- 它完成某些事物。在其完成时存在一个自动转换。 分区(partition)- 表示参加过程的不同参与者。 分叉点(fork)- 一个输入转换，以及多个输出的并行转换或对象流。 连接点(join)- 多个输入转换或对象流，一个输出变换，其输出直到所有输入都到达时才发生。 对象节点(object node)- 由动作产生或使用的对象，这允许我们对数据流或对象流进行建模。 决策(decision)- 互斥发生的任何分支。 合并(merge)- 任何输入的延续。 2、在活动图建模方面，有下面一些准则: 活动图通常对于涉及众多参与者的非常复杂的业务过程建模具有价值。对于简单的业务过程，用例文本就够用了。 在进行业务过程建模时，可以利用耙子(rake)符号和子活动图。 与上一条相关的是，尽量保持同一张图中所有动作节点的抽象水平一致。 3、同活动图一样，UML状态图是动态视图。UML包含了可用来描述事物(事务、用例和人等)的事件和状态的表示法。UML状态机图(state machine diagram)描述了某个对象的状态和感兴趣的事件以及对象响应该事件的行为。转换(transition)用标记有事件的箭头表示。状态(state)用圆角的矩形表示。通常的做法是会包含一个初始伪状态，当实例创建时，自动从初始伪状态转换到另外一个状态。 4、状态图显示了对象的生命周期:对象经历的事件、对象的转换和对象在这些事件之间的状态。状态图不必描述所有可能的事件;如果所发生的事件未在图中表示，则说明其不影响该状态机图所关注的内容。 5、用例彼此之间可能具有联系: 包含关系 - 多个用例中存在部分相同的行为，与其重复文本描述，不如将这部分交互行为分离为单 独的子功能用例，并适用包含关系加以指示。Fowler给出了何时使用包含关系的简单且实用的准则:当在两个或多个独立用例中存在重复，而你想避免这种冗余时，可以使用包含关系。 扩展关系 - 创建扩展或附加用例，并且在其中描述:在何处和何种条件下该用例扩展某基础用例的 行为。 6、架构分析的本质是要识别影响架构的因素，理解这些因素的可变性和优先级，并且解决这些问题。其难点是要知道应该问什么样的问题，权衡利弊和了解处理一个重要架构因素的各种办法。 7、架构分析(architectural analysis)是在功能性需求的语境中，识别和处理系统非功能性需求的活动。 注:详细阅读第36、37章中的示例，肯定会有很大收获。 书中示例:NextGen POS 1、需求之一是，当远程服务访问失败时(例如当产品数据库(暂时)无法访问时)，得到某种程度的恢复。 使用适配器和工厂模式能够间接地实现这一特性: 总是返回本地产品信息服务的适配器。 本地产品“适配器”并不会真正地适配其他构件，它将自己负责实现本地服务。 使用实际的远程产品服务适配器的引用来初始化本地服务。 如果本地服务在缓存中找到数据，就将数据返回;否则，将请求转发给外部服务。 对于产品信息服务的初始化: 2、通过代理(GoF)使用本地服务进行容错 通过在外部服务的前端添加本地服务，实现了产品信息的本地服务容错;使用中总是优先尝试本地服务。但是，此设计方案并不是对所有的服务都适用。有时需要先尝试外部服务，然后才是本地服务。例如，在帐务服务中记录销售。在业务上希望这一过程越快越好，以便能够实时地追踪商店和终端的活动。 在此情形下，GoF的代理(Proxy)模式可以解决这个问题。NextGen案例中使用的代理是重定向代理(Redirection Proxy)变体，该代理也称为冗错代理(Failover Proxy)。 代理只不过是与被代理对象实现相同接口的对象，它保存指向被代理对象的引用，并且用于控制对被代理对象的访问。 第六部分 其他主题 1、有很多种方法可以计划一次迭代，下面是较典型的方法: 第一步应确定迭代的时间长度;常见的时间长度为2~6周。一般来说，短一些较好。延长迭代周期的 因素包括在早期工作中有较多发现和变化、较大的开发团队以及分布式开发。迭代的结束时间一旦确定，就不应改变-这是时间定量的实践。但是，可以通过 第二步是召集迭代计划会议。减少本次迭代的工作范围来满足该结束时间。 这通常在上一次迭代完成(例如星期五)而下一次迭代(例如星期一) 尚未开始时进行。在理想情况下，主要涉众都应该参加:顾客(营销人员、最终用户)、开发者、首席架构师和项目经理等。 列出本次迭代的潜在目标(新特性或者用例、缺陷等)，并标记优先级。目标列表通常由客户(业务 目标)和首席架构师(技术目标)共同确定。 团队的每个成员应为本次迭代编制个人自愿预算(以消失或天为单位)，所有的资源预算应当被汇总 起来。 对于某一目标(例如一个用例)，在计划中对其进行较为详细的描述，并分解其对应的问题。接着， 参加会议的人(特别是开发人员)对与目标相关的一组更详细的任务进行头脑风暴式的讨论，并形成粗略估计。 反复进行第五步直到确定了足够多的工作:迭代阶段的总任务应该与总的 资源预算相匹配。在指定的 资源预算和时间定量最终期限的限制之下，如果工作量基本匹配，则可以结束会议。 2、迭代开发的重要思想之一就是根据反馈不断改进，而不是试图详细预测和计划整个项目。