面向对象方分析(完整ok)解析.ppt

* 大多数对象到对象的交互行为都对应着事件。 * 大多数对象到对象的交互行为都对应着事件。 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 不论采用哪种方法开发软件，分析的过程都是提取系统需求的过程。分析工作主要包括3项内容，这就是理解、表达和验证。首先，系统分析员通过与用户及领域专家的充分交流，力求完全理解用户需求和该应用领域中的关键性的背景知识，并用某种无二义性的方式把这种理解表达成文档资料。分析过程得出的最重要的文档资料是软件需求规格说明(在面向对象分析中，主要由对象模型、动态模型和功能模型组成)。 理解和验证的过程通常交替进行，反复迭代，而且往往需要利用原型系统作为辅助工具。 * * * 需求陈述通常是不完整、不准确的，而且往往是非正式的。通过分析，可以发现和改正原始陈述中的二义性和不一致性，补充遗漏的内容，从而使需求陈述更完整、更准确。因此，不应该认为需求陈述是一成不变的，而应该把它作为细化和完善实际需求的基础。在分析需求陈述的过程中，系统分析员需要反复多次地与用户协商、讨论、交流信息，还应该通过调研了解现有的类似系统。正如以前多次讲过的，快速建立起一个可在计算机上运行的原型系统，非常有助于分析员和用户之间的交流和理解，从而能更正确地提炼出用户的需求。 * 接下来，系统分析员应该深入理解用户需求，抽象出目标系统的本质属性，并用模型准确地表示出来。用自然语言书写的需求陈述通常是有二义性的，内容往往不完整、不一致。分析模型应该成为对问题的精确而又简洁的表示。后继的设计阶段将以分析模型为基础。更重要的是，通过建立分析模型能够纠正在开发早期对问题域的误解。 在面向对象建模的过程中，系统分析员必须认真向领域专家学习。尤其是建模过程中的分类工作往往有很大难度。继承关系的建立实质上是知识抽取过程，它必须反映出一定深度的领域知识，这不是系统分析员单方面努力所能做到的，必须有领域专家的密切配合才能完成。 在面向对象建模的过程中，还应该仔细研究以前针对相同的或类似的问题域进行面向对象分析所得到的结果。由于面向对象分析结果的稳定性和可重用性，这些结果在当前项目中往往有许多是可以重用的。 * * 解决的问题不同，这3个子模型的重要程度也不同： 动态模型和功能模型中都包含了对象模型中的操作(即服务或方法)。 * 解决的问题不同，这3个子模型的重要程度也不同： 动态模型和功能模型中都包含了对象模型中的操作(即服务或方法)。 类与对象（即UML的“类”）、结构（即类或对象之间的关系）、属性和服务的概念，现在再简要地介绍一下主题(或范畴)的概念。 * * 接下来将以ATM系统为例进行该过程的介绍，分析来源于需求，首先介绍下需求陈述 * * * * * * 也就是说，系统应该能够处理并发的访问。 * 也就是说，系统应该能够处理并发的访问。 * * * * * * 通常，在需求陈述中不会一个不漏地写出问题域中所有有关的类与对象，因此，分析员应该根据领域知识或常识进一步把隐含的类与对象提取出来。例如，在ATM系统的需求陈述中虽然没写“通信链路”和“事务日志”，但是，根据领域知识和常识可以知道，在ATM系统中应该包含这两个实体。 * * * * * * * * * 事件包括系统与用户(或外部设备)交互的所有信号、输入、输出、中断、动作等等。 从脚本中容易找出正常事件，但是，应该小心仔细，不要遗漏了异常事件和出错条件。 传递信息的对象的动作也是事件。例如，储户插入现金兑换卡、储户输入密码、ATM吐出现金等。 预约登记表和病人的属性 姓名 日期 姓名，日期 姓名 姓名，日期 病人 记录 病人数据 有效 日期 预 约 信 息 预约 信息 预约 信息 预约 信息 每天、每周 工作安排 本章结束 软件工程 已删去类的关联 如果在分析确定类与对象的过程中已经删掉了某个候选类，则与这个类有关的关联也应该删去，或用其他类重新表达这个关联。 ATM、中央计算机、分行计算机、柜员终端、总行、分行、柜员、储户、账户、事务、现金兑换卡。 (b)与问题无关或应在实现阶段考虑的关联 系统处理并发的访问。 (c)瞬时事件 关联应该描述问题域的静态结构，而不应该是一个瞬时事件。 ATM读现金兑换卡 ATM与用户交互 如果用动作表示的需求隐含了问题域的某种基本结构，则应该用适当的动词词组重新表达这个关联。 “中央计算机确定事务与分行的对应关系”隐含了结构上“中央计算机与分行通信”的关系。 中央计算机与分行通信 (d)三元关联 三个或三个以上对象之间的关联，大多可以分解为二元关联或用词组描述成限定的关联。 “柜员输入针对账户的事务”可以分解成“柜员输入事务”和“事务修改账户”这样两个二元