确定属性的过程包括分析和选择两个步骤分析Adjective.pptVIP

10.3.4 确定属性(Identifying attribute) 确定属性的过程包括分析和选择两个步骤。 1. 分析(Adjective and Noun phrase for Attribute Candidate) 　　在需求陈述中用名词词组表示属性。 例如，“汽车的颜色”或“光标的位置”。往往用形容词表示可枚举的具体属性，例如，“红色的”、“打开的”。但是，不可能在需求陈述中找到所有属性，分析员还必须藉助于领域知识和常识才能分析得出需要的属性。 2. 选择(Choose Proper Attribute) 删掉不正确的或不必要的属性。 (1) 误把对象当作属性 　　例如，在邮政目录中，“城市”是一个属性，而在人口普查中却应该把“城市”当作对象。 （2） 误把关联类的属性当作一般对象的属性 　　如果某个性质依赖于某个关联链的存在，则该性质是关联类的属性，在分析阶段不应该把它作为一般对象的属性。 （3） 把限定误当成属性 　　在ATM系统的例子中，“分行代码”、“账号”、“雇员号”、“站号”等都是限定词。 (4) 误把内部状态当成了属性 如果某个性质是对象的非公开的内部状态，则应该从对象模型中删掉这个属性。 (5) 过于细化 在分析阶段应该忽略那些对大多数操作都没有影响的属性。 (6) 存在不一致的属性 类应该是简单而且一致的。如果得出一些看起来与其他属性毫不相关的属性，则应该考虑把该类分解成两个不同的类。 10.3.5 识别继承关系(Recognising Inheritance) 　　用两种方式建立继承(即泛化)关系： 　　利用继承机制共享公共性质，并对系统中众多的类加以组织。 (1) 自底向上： 抽象出现有类的共同性质泛化出父类，这个过程实质上模拟了人类归纳思维过程。 例如，在ATM系统中，“远程事务”和“柜员事务”是类似的，可以泛化出父类“事务”；类似地，可以从“ATM”和“柜员终端”泛化出父类“输入站”。 (2) 自顶向下： 把现有类细化成更具体的子类，这模拟了人类的演绎思维过程。 　　利用多重继承可以提高共享程度，但是同时也增加了概念上以及实现时的复杂程度。使用多重继承机制时，通常应该指定一个主要父类，从它继承大部分属性和行为；次要父类只补充一些属性和行为。 　　图10.5增加了继承关系之后的ATM对象模型。 10.3.6 反复修改(Repetitious Modification) 　　 1. 分解“现金兑换卡”类 把“现金兑换卡”类分解为“卡权限”和“现金兑换卡”两个类，将使每个类的功能更单一：前一个类标志储户访问账户的权限，后一个类是含有分行代码和卡号的数据载体。多张现金兑换卡可能对应着相同的访问权限。 2. “事务”由“更新”组成 通常，一个事务包含对账户的若干次更新，这里所说的更新，指的是对账户所做的一个动作(取款、存款或查询)。“更新”虽然代表一个动作，但是它有自己的属性(类型、金额等)，应该独立存在，因此应该把它作为类。 3. 把“分行”与“分行计算机”合并 区分“分行”与“分行计算机”，对于分析这个系统来说，并没有多大意义，为简单起见，应该把它们合并。类似地，应该合并“总行”和“中央计算机”。 　　 10.4 建立动态模型(Dynamic Modeling) 　　第一步是编写典型交互行为的脚本。 　　第二步，从脚本中提取出事件，确定触发每个事件的动作对象以及接受事件的目标对象。 　　第三步，排列事件发生的次序，确定每个对象可能有的状态及状态间的转换关系，并用状态图描绘它们。 　　最后，比较各个对象的状态图，检查它们之间的一致性，确保事件之间的匹配。 　　本节结合ATM系统的实例，进一步讲述建立动态模型的方法。 10.4.1 编写脚本(Writing Script) 　　在建立动态模型的过程中，脚本是指系统在某一执行期间内出现的一系列事件。 　　脚本描述用户(或其他外部设备)与目标系统之间的一个或多个典型的交互过程，以便对目标系统的行为有更具体的认识。 　　编写脚本的目的，是保证不遗漏重要的交互步骤，它有助于确保整个交互过程的正确性的和清晰性。 　　ATM系统的正常情况脚本和异常情况脚本（240页）。 10.4.2 设想用户界面(User Interface Design) 　　大多数交互行为都可以分为应用逻辑和用户界面两部分。 　　采用不同界面(例如，命令行或图形用户界面)，可以实现同样的程序逻辑。应用逻辑是内在的、本质的内容，用户界面是外在的表现形式。 　　动态模型着重表示应用系统的控制逻辑。 图10.7 ATM的界面格式 10.4.3 画事件跟踪图(Drawing Events Track Diagram) 　　完整、正确的