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

《UML和模式应用》读 书 关于书的成语关于读书的排比句社区图书漂流公约怎么写关于读书的小报汉书pdf 笔记（一） 《UML和模式应用》读书笔记(一) 第一部分 绪论 1、在OO开发中，至关重要的能力是熟练地为软件对象分配职责;个人认为将对象进行抽象的能力也相当重要。 2、分析(analysis)强调的是对问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 和需求的调查研究，而不是解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 ;设计(design)强调的是满足需求的概念上的解决方案(在软件方面和硬件方面)，而不是其实现。 有益的分析和设计可以概括为:做正确的事(分析)和正确地做事(设计)。 3、需求分析可能包括人们如何使用应用的情节或场景，这些情节或场景可以被编写成用例(use case)。 4、面向对象分析关注从对象的角度创建领域描述，面向对象分析需要鉴别重要的概念、属性和关联。面向对象分析的结果可以表示为领域模型，在领域模型中展示重要的领域概念或对象。 5、面向对象设计关注软件对象的定义-它们的职责和协作。 6、与领域模型表示的是真实世界的类，设计类图表示的是软件类。 7、敏捷建模(agile modeling)强调了UML作为草图的方式，这也是适用UML的普通方式，而且通常对时间投入具有高回报(一般费时较短)。 8、迭代开发(iterative development)是UP和大多数其他现代 方法 快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载 中的关键实践。在这种生命周期方法中，开发被组织成一系列固定的短期(如三个星期)小项目，称为迭代(iteration)，每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试活动。 9、迭代开发的优点包括: , 减少项目失败可能性，提高生产率，降低缺陷率。 , 在早期缓解高风险(技术、需求、目标、可用性等等)。 , 早期可见的进展。 , 早期反馈、用户参与和调整，会产生更接近涉众真实需求的精化系统。 , 可控复杂性;团队不会被“分析瘫痪”或长期且复杂的步骤所淹没。 , 一次迭代中的经验可以被系统地用于改进开发过程本身，并如此反复进 行下去。 10、在复杂、变更系统中(如大多数软件项目)，反馈和调整是成功的关键要素。 11、如何进行迭代和进化式分析和设计: 1)在第1次迭代之前，召开第一个时间定量的需求工作会议，例如确切地定义为两天时间，业务和开发人员(包括首席架构师)需要出席。 , 在第一天上午，进行高阶需求分析，例如仅仅确定用例和特性的名称， 以及关键的非功能性需求。这种分析不可能是完美的。 , 通过咨询首席架构师和业务人员，从高阶列表中选择10%列表项，这些 项目具备以下三种性质:1，具有重要的架构意义;2，具有高业务价值; 3，具有高风险。 , 在剩下的一天半内，对这三个用例的功能和非功能性需求进行详细的分 析。完成这一过程后，对10%进行了深入分析，90%进行了高阶分析。 2)在第1次迭代之前，召开迭代 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 会议，选择上述三种用例的子集，在特定时间内(例如，四周的时间定量迭代)进行设计、构造和测试。 3)在三到四周内完成第1次迭代(选择时间定量，并严格遵守时间): , 在开始的两天内，开发者和其他成员分组进行建模和设计工作，在首席 架构师的带领和指导下，于“公共作战室”的众多白板上，画出UML的 草图(及其他的模型)。 , 然后，开发者摘掉其“建模帽子”并戴上“编程帽子”，开始编程、测 试和集成工作并且剩余的时间均用于完成这项工作。 , 进行大量的测试，包括单元测试、验收测试、负载测试和可用性测试等。 , 在结束前的一周，检查是否能够完成初始的迭代目标;如果不能，则缩 小迭代的范围，将次要目标置回任务列表中。 , 在最后一周的星期二，冻结代码。必须检入、集成和测试所有代码，以 建立迭代的基线。 , 在星期三的上午，向外部涉众演示此局部系统，展示早期可视进展，同 时要求反馈。 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、在同一层内的对象在职责上应该具有紧密关联，不同层中对象的职责则不应该混淆。 6、需要哪些对象，它们如何通过消息和方法进行协作，通过动态对象建模(例如绘制顺序图)才能真正落实这些准确和详细的结论。 7、应该把时间花费在交互图(顺序图或通信图)，而不仅是类图上。 8、任何顺序图都可以使用sd图框围绕起来，并对其命名。当你想要引用相应名字的sd图框时，可以使用ref图框。 9、在类图中，使用依赖线描述对象之间的全局变量、参数变量、局部变量和静态方法(对其他类的静态方法加以调用)的依赖。 10、GRASP是通用职责分配软件模式(General Responsibility Assignment Software Patterns)的缩写。GRASP的9个模式如下所示: 创建者(Creator) 如果以下的条件之一(越多越好)为真时，将创建类A实例的职责分配给类B: , B“包含”或组成聚集A。 , B记录A。 , B直接使用A。 , B具有A的初始化数据，并且在创建A时会将这些数据传递给A。因此对 于A的创建而言，B是专家。 , B是对象A的创建者。 注意:对象的创建常常具有相当的复杂性，这时最好的方法是把创建职责委派给称为具体工厂(Concrete Factory)或抽象工厂(Abstract Factory)的辅助类，而不是使用创建者模式所建议的类。 信息专家(Information Expert) 把职责分配给信息专家，它具有实现这个职责所必需的信息。分配职责应当从清晰地描述职责开始。 注意:由于耦合与内聚问题导致某些情况下，专家模式建议的方案并不合适。 低耦合(Low Coupling) 分配职责，使耦合性尽可能低。利用这一原则来评估可选方案。 控制器(Controller) 控制器是UI层之上的第一个对象，它负责接收和处理系统操作消息。 高内聚(High Cohesion) 内聚(或更为专业地说，是功能内聚)是对元素职责的相关性和集中度的度量。 多态性(Polymorphism) 纯虚构(Pure Fabrication) 间接性(Indirection) 防止变异(Protected Variations)