(软件工程)第9章面向对象方分析（第一堂课面向对象分析的基本过程）.ppt

* * * * * 通常，在需求陈述中不会一个不漏地写出问题域中所有有关的类与对象，因此，分析员应该根据领域知识或常识进一步把隐含的类与对象提取出来。例如，在ATM系统的需求陈述中虽然没写“通信链路”和“事务日志”，但是，根据领域知识和常识可以知道，在ATM系统中应该包含这两个实体。 * * * * * * * * * * * * * * * * * 银行，自动取款机(ATM)，系统，中央计算机，分行计算机，柜员终端，网络，总行，分行，软件，成本，市，街道，营业厅，储蓄所，柜员，储户，现金，支票，账户，事务，现金兑换卡，余额，磁卡，分行代码，卡号，用户，副本，信息，密码，类型，取款额，账单，访问。 “通信链路”和“事务日志” (d) 属性 在需求陈述中有些名词实际上描述的是其他对象的属性，应该把这些名词从候选类与对象中去掉。当然，如果某个性质具有很强的独立性，则应把它作为类而不是作为属性。 “现金”、“支票”、“取款额”、“账单”、“余额”、“分行代码”、“卡号”、“密码”、“类型”等，实际上都应该作为属性对待。 (e) 操作 在需求陈述中有时可能使用一些既可作为名词，又可作为动词的词，应该慎重考虑它们的含义，以便正确地决定把它们作为类还是作为类中定义的操作。 例如，谈到电话时通常把“拨号”当作动词，当构造电话模型时确实应该把它作为一个操作，而不是一个类。 但是，在开发电话的自动记账系统时，“拨号”需要有自己的属性(例如日期、时间、受话地点等)，因此应该把它作为一个类。 总之，本身具有属性需独立存在的操作，应该作为类与对象。 银行，自动取款机(ATM)，系统，中央计算机，分行计算机，柜员终端，网络，总行，分行，软件，成本，市，街道，营业厅，储蓄所，柜员，储户，现金，支票，账户，事务，现金兑换卡，余额，磁卡，分行代码，卡号，用户，副本，信息，密码，类型，取款额，账单，访问。 “通信链路”和“事务日志” (f) 实现 在分析阶段不应该过早地考虑怎样实现目标系统。因此，应该去掉仅和实现有关的候选的类与对象。 “事务日志”无非是对一系列事务的记录，它的确切表示方式是面向对象设计的议题；“通信链路”在逻辑上是一种联系，在系统实现时它是关联类的物理实现。 银行，自动取款机(ATM)，系统，中央计算机，分行计算机，柜员终端，网络，总行，分行，软件，成本，市，街道，营业厅，储蓄所，柜员，储户，现金，支票，账户，事务，现金兑换卡，余额，磁卡，分行代码，卡号，用户，副本，信息，密码，类型，取款额，账单，访问。 “通信链路”和“事务日志” 已删去类的关联 如果在分析确定类与对象的过程中已经删掉了某个候选类，则与这个类有关的关联也应该删去，或用其他类重新表达这个关联。 ATM、中央计算机、分行计算机、柜员终端、总行、分行、柜员、储户、账户、事务、现金兑换卡。 (b)与问题无关或应在实现阶段考虑的关联 系统处理并发的访问。 (c)瞬时事件 关联应该描述问题域的静态结构，而不应该是一个瞬时事件。 ATM读现金兑换卡 ATM与用户交互 如果用动作表示的需求隐含了问题域的某种基本结构，则应该用适当的动词词组重新表达这个关联。 “中央计算机确定事务与分行的对应关系”隐含了结构上“中央计算机与分行通信”的关系。 中央计算机与分行通信 (d)三元关联 三个或三个以上对象之间的关联，大多可以分解为二元关联或用词组描述成限定的关联。 “柜员输入针对账户的事务”可以分解成“柜员输入事务”和“事务修改账户”这样两个二元关联。而“分行计算机处理针对账户的事务”也可以做类似的分解。“ATM与中央计算机交换关于事务的信息”这个候选的关联，实际上隐含了“ATM与中央计算机通信”和“在ATM上输入事务”这两个二元关联。 中央计算机与分行通信 柜员输入事务 事务修改账户 分行计算机处理事务 事务修改账户 ATM与中央计算机通信 ATM上输入事务 (e)派生关联 删除可以用其他关联定义的冗余关联 “总行拥有多台ATM”实质上是“总行拥有中央计算机”和“ATM与中央计算机通信”这两个关联组合的结果。 而“分行计算机维护账户”的实际含义是“分行保管账户”和“事务修改账户”。 中央计算机与分行通信 柜员输入事务 事务修改账户 分行计算机处理事务 事务修改账户 ATM与中央计算机通信 ATM上输入事务 * 不论采用哪种方法开发软件，分析的过程都是提取系统需求的过程。分析工作主要包括3项内容，这就是理解、表达和验证。首先，系统分析员通过与用户及领域专家的充分交流，力求完全理解用户需求和该应用领域中的关键性的背景知识，并用某种无二义性的方式把这种理解表达成文档资料。分析过程得出的最重要的文档资料是软件需求规格说明(在面向对象分析中，主要由对象模型、动态模型和功能模型组成)。 理解和验证的过程