面向对象分析.pptVIP

*编写脚本脚本是指系统在某一执行期间内出现的一系列事件。编写脚本的过程，实质上就是分析用户对系统交互行为的要求的过程。目的：保证不遗漏重要的交互步骤，它有助于确保整个交互过程的正确性和清晰性。范围：既可以包括系统中发生的全部事件，也可以只包括由某些特定对象触发的事件。脚本描写的范围主要由编写脚本的具体目的决定。*编写脚本步骤：编写正常情况的脚本。考虑特殊情况，例如输入或输出的数据为最大值（或最小值）。考虑出错情况，例如，输入的值为非法值或响应失败。如果可能，应该允许用户“异常中止”或“取消”一个操作。应该提供诸如“帮助”和状态查询之类的在基本交互行为之上的“通用”交互行为。*编写脚本脚本描述事件序列每当系统中的对象与用户（或其他外部设备）交换信息时，就发生一个事件。所交换的信息值就是该事件的参数（例如，“输入密码”事件的参数是所输入的密码）。也有许多事件是无参数的，这样的事件仅传递一个信息——该事件已经发生了。*编写脚本对于每个事件，都应该指明：触发该事件的动作对象（例如，系统、用户或其他外部事物）接受事件的目标对象事件的参数。*ATM系统的正常情况脚本ATM请储户插卡；储户插入一张现金兑换卡。ATM接受该卡并读它上面的分行代码和卡号。ATM要求储户输入密码；储户输入自己的密码“1234”等数字。ATM请求总行验证卡号和密码；总行要求“39”号分行核对储户密码，然后通知ATM说这张卡有效。*ATM系统的正常情况脚本ATM要求储户选择事务类型（取款、转账、查询等）；储户选择“取款”。ATM要求储户输入取款额；储户输入“880”。ATM确认取款额在预先规定的限额内，然后要求总行处理这个事务；总行把请求转给分行，该分行成功地处理完这项事务并返回该账户的新余额。*ATM系统的正常情况脚本ATM吐出现金并请储户拿走这些现金；储户拿走现金。ATM问储户是否继续这项事务；储户回答“不”。ATM打印账单，退出现金兑换卡，请储户拿走它们；储户取走账单和卡。ATM请储户插卡。*ATM系统的异常情况脚本ATM请储户插卡；储户插入一张现金兑换卡。ATM接受这张卡并读它上面的分行代码和卡号。ATM要求密码；储户误输入“8888”。ATM请求总行验证输入的数字和密码；总行在向有关分行咨询之后拒绝这张卡。*ATM系统的异常情况脚本ATM显示“密码错”，并请储户重新输入密码；储户输入“1234”；ATM请总行验证后知道这次输入的密码正确。ATM请储户选择事务类型；储户选择“取款”。ATM询问取款额；储户改变主意不想取款了，他敲“取消”键。ATM退出现金兑换卡，并请储户拿走它；储户拿走他的卡。ATM请储户插卡。*笼统把笼统的或模糊的类去掉。以ATM系统为例，“银行”实际指总行或分行，“访问”在这里实际指事务，“信息”的具体内容在需求陈述中随后就指明了。此外还有一些笼统含糊的名词。总之，在本例中应该去掉“银行”、“网络”、“系统”、“软件”、“信息”、“访问”等候选类。*笼统自动取款机(ATM)中央计算机分行计算机柜员终端总行分行柜员储户现金支票账户事务现金兑换卡余额分行代码卡号密码类型取款额账单。银行网络系统软件信息访问*属性有些名词实际上描述的是其他对象的属性，应该把这些名词从候选类--对象中去掉。当然，如果某个性质具有很强的独立性，则应把它作为类而不是作为属性。在ATM系统的例子中，“现金”、“支票”、“取款额”、“账单”、“余额”、“分行代码”、“卡号”、“密码”、“类型”等，实际上都应该作为属性对待。*属性自动取款机(ATM)中央计算机分行计算机柜员终端总行分行柜员储户账户事务现金兑换卡现金支票取款额账单余额分行代码卡号密码类型*操作一些既可作为名词，又可作为动词的词，应该慎重考虑它们在本问题中的含义，以便正确地决定把它们作为类还是作为类中定义的操作。但是，本身具有属性需独立存在的操作，应该作为类－－对象。*操作例如，谈到电话时通常把“拨号”当作动词，当构造电话模型时确实应该把它作为一个操作，而不是一个类。但是，在开发电话的自动记账系统时，“拨号”需要有自己的属性（如日期、时间、受话地点等），因此应该把它作为一个类。*实现应该去掉仅和实现有关的候选类--对象。在设计和实现阶段，这些类－－对象可能是重要的，但在分析阶段过早地考虑它们反而会分散我们的注意力。在ATM系统的例子中，“事务日志”无非是对一系列事务的记录，它的确切表示方式是面向对象设计的议题；“通信链路”在逻辑