2.选择(ChooseProperAttribute)删掉不正确的或不必要的属性。(1)误把对象当作属性例如，在邮政目录中，“城市”是一个属性，而在人口普查中却应该把“城市”当作对象。（2）误把关联类的属性当作一般对象的属性如果某个性质依赖于某个关联链的存在，则该性质是关联类的属性，在分析阶段不应该把它作为一般对象的属性。（3）把限定误当成属性在ATM系统的例子中，“分行代码”、“账号”、“雇员号”、“站号”等都是限定词。(4)误把内部状态当成了属性如果某个性质是对象的非公开的内部状态，则应该从对象模型中删掉这个属性。(5)过于细化在分析阶段应该忽略那些对大多数操作都没有影响的属性。(6)存在不一致的属性类应该是简单而且一致的。如果得出一些看起来与其他属性毫不相关的属性，则应该考虑把该类分解成两个不同的类。10.3.5识别继承关系(RecognisingInheritance)用两种方式建立继承(即泛化)关系：利用继承机制共享公共性质，并对系统中众多的类加以组织。(1)自底向上：抽象出现有类的共同性质泛化出父类，这个过程实质上模拟了人类归纳思维过程。例如，在ATM系统中，“远程事务”和“柜员事务”是类似的，可以泛化出父类“事务”；类似地，可以从“ATM”和“柜员终端”泛化出父类“输入站”。(2)自顶向下：把现有类细化成更具体的子类，这模拟了人类的演绎思维过程。利用多重继承可以提高共享程度，但是同时也增加了概念上以及实现时的复杂程度。使用多重继承机制时，通常应该指定一个主要父类，从它继承大部分属性和行为；次要父类只补充一些属性和行为。图10.5增加了继承关系之后的ATM对象模型。10.3.6反复修改(RepetitiousModification)1.分解“现金兑换卡”类把“现金兑换卡”类分解为“卡权限”和“现金兑换卡”两个类，将使每个类的功能更单一：前一个类标志储户访问账户的权限，后一个类是含有分行代码和卡号的数据载体。多张现金兑换卡可能对应着相同的访问权限。2.“事务”由“更新”组成通常，一个事务包含对账户的若干次更新，这里所说的更新，指的是对账户所做的一个动作(取款、存款或查询)。“更新”虽然代表一个动作，但是它有自己的属性(类型、金额等)，应该独立存在，因此应该把它作为类。3.把“分行”与“分行计算机”合并区分“分行”与“分行计算机”，对于分析这个系统来说，并没有多大意义，为简单起见，应该把它们合并。类似地，应该合并“总行”和“中央计算机”。10.4建立动态模型(DynamicModeling)第一步是编写典型交互行为的脚本。第二步，从脚本中提取出事件，确定触发每个事件的动作对象以及接受事件的目标对象。第三步，排列事件发生的次序，确定每个对象可能有的状态及状态间的转换关系，并用状态图描绘它们。最后，比较各个对象的状态图，检查它们之间的一致性，确保事件之间的匹配。本节结合ATM系统的实例，进一步讲述建立动态模型的方法。在建立动态模型的过程中，脚本是指系统在某一执行期间内出现的一系列事件。脚本描述用户(或其他外部设备)与目标系统之间的一个或多个典型的交互过程，以便对目标系统的行为有更具体的认识。编写脚本的目的，是保证不遗漏重要的交互步骤，它有助于确保整个交互过程的正确性的和清晰性。ATM系统的正常情况脚本和异常情况脚本（240页）。大多数交互行为都可以分为应用逻辑和用户界面两部分。采用不同界面(例如，命令行或图形用户界面)，可以实现同样的程序逻辑。应用逻辑是内在的、本质的内容，用户界面是外在的表现形式。动态模型着重表示应用系统的控制逻辑。图10.7ATM的界面格式完整、正确的脚本为建立动态模型奠定了必要的基础。但是，用自然语言书写的脚本往往不够简明，而且有时在阅读时会有二义性。为了有助于建立动态模型，通常在画状态图之前先画出事件跟踪图。为此首先需要进一步明确事件及事件与对象的关系。1.确定事件(Identifyingevents)应该仔细分析每个脚本，以便从中提取出所有外部事件。2.画出事件跟踪图(DrawingEventsTrackDiagram)从脚本中提取出各类事件并确定了每类事件的发送对象和接受对象之后，就可以用事件跟踪图把事件序列以及事件与对象的关系，形象、清晰地表示出来。事件跟踪图是简化的UML顺序图。在事件跟踪图中，一条竖线代表一个对象，每个事件用一条水平的箭头线表示，箭头方向从事件的发送对象指向接受对象。时间从上向下递增。图中仅用箭头线在垂直方向上的相对位置表示事件发生的先后。状态图描绘事件与对象状态的关系。当对象接受了一个事件以后，引起的状态改变称为“转换”。用一张状态图描绘一类对象的行为，它确定了由事