第7章 分析问题.pptVIP

第7章 分析问题 学习目标： 理解分析的含义 建立静态分析模型 理解动态分析如何帮助验证静态模型 7.1 引言 分析是需求和设计之间的桥梁，可以把系统必须提供的服务的清晰陈述转化为对要处理的对象的正确理解。 分析是找出系统要处理什么的过程，而不是确定如何处理过程。 分析模型的分类 分析模型有静态部分和动态部分 静态分析：使用类图描述，显示对象及其对象之间的关系 动态分析：使用通信图（协作图）证明静态模型是可行的 分析的来源 业务需求模型：描述业务上下文的手工和自动工作流，它使用参与者的面向对象（业务）版本、用例、对象、术语表，有时还有通信图和活动图来描述 系统需求模型：包含系统的外部视图，描述为参与者的面向系统版本、用例和用例图、用户界面草案、增强的术语表和非功能需求 分析阶段内容 分析的来源必须转化为由系统处理的对象模型，以及对象的属性和关系 这些对象存在于系统或系统边界上，可以通过一个或多个接口来访问 该阶段的大多数对象都对应于真实世界中的物理对象或概念（低级的、面向解决方案的对象要在设计阶段才出现） 贯彻“用例驱动” 补充：处理过程 7.2 为什么要进行分析 分析可防止在彻底理解问题之前设计解决方案 不可能仅根据业务需求模型就完全理解问题，只有转化为软件，才有可能引入新的实践 分析的作用 完成静态分析，客户就能确认我们对业务对象的理解是否正确，之后让对象影响我们的设计 完成动态分析，就可以确信分析对象能够支持需要的系统功能 7.3 分析过程概述 使用系统需求模型查找候选的类，以描述与系统相关的对象，并在类图上建立它们 确定类之间的关系(关联、聚合、复合和继承) 确定类的属性（对象的、已指定的简单特性） 分析过程概述 检查系统用例，确定已有的对象支持它们。在检查过程中微调类、属性和关系，这个用例的实现过程将生成一些操作，来补充属性 需要时更新术语表和非功能需求——用例本身不需要更新，但可能需要某些更正 需要给客户展示的... 类图和属性 便于客户的理解，有这样纠正错误的分析 不要客户展示的... 对象操作或通信图 难以被客户理解 肤浅的设计，系统用例已演示了动态行为 其中隐含编码，暴露秘密 在设计之前是要删除的 7.4 静态分析 静态分析确定系统的逻辑或物理部分，以及如何把它们连接在一起，即描述如何构建和初始化系统 7.4.1 确定类 为了检查业务需求建模和系统需求建模，以系统用例的形式抽取出候选类 候选类常常在用例中用名词表示 确定类 不适合作为候选类的名词： 系统本身 参与者（例外：需要在内部存储参与者的信息） 边界 小类型（字符串或数字） 7.4.2 标识类的关系 依赖 泛化（继承） 关联 聚集 复合（组合） 实现 1. 依赖 定义：对于两个相对独立的对象，当一个对象负责构造另一个对象的实例，或者依赖另一个对象的服务时，这两个对象之间主要体现为依赖关系。 表现：依赖关系表现在局部变量，方法的参数，以及对静态方法的调用 依赖 实例：比如说拧螺丝，要借助(也就是依赖)螺丝刀(Screwdriver)来帮助你完成拧螺丝(screw)的工作 代码： public?class?Person{ ?? ????/**?拧螺丝?*/?? ????public?void?screw(Screwdriver?screwdriver){ ?? ????????screwdriver.screw(); ?? ????} ?? }?? 2.泛化（继承）关系 定义：表示类与类之间的继承关系，接口与接口之间的继承关系，或类对接口的实现关系。一般化的关系是从子类指向父类的，与继承或实现的方法相反。 表现： 父类 父类实例＝new 子类() 泛化代码 class?Animal{} ?? class?Tiger?extends?Animal{} ?? public?class?Test ?? { ?? ????public?void?test() ?? ????{ ?? ????????Animal?a=new?Tiger(); ?? ????} ?? }?? 3. 关联关系 定义：对于两个相对独立的对象，当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时，这两个对象之间为关联关系 表现：关联关系是使用实例变量来实现 关联 实例：比如客户和订单，每个订单对应特定的客户，每个客户对应一些特定的订单；再例如公司和员工，每个公司对应一些特定的员工，每个员工对应一特定的公司 关联代码 public?class?Company{ ?? ????private?Employee?employee; ?? ????public?Employee?getEmployee(){ ?? ?