实验二建立类模型和状态模型..docVIP

实验二 建立类模型 一、建立类模型 首先标识类和关联，因为它们影响到整体结构和解决问题的方法；其次是增加属性，进一步描述类和关联的基本框架，使用继承合并和组织类；最后将操作增加到类中去作为构造状态模型和交互模型的参考。 确定类 构造类模型的第一步是标识来自问题域的相关类，类包括物理实体和概念。所有类在应用中都必须有意义，在问题陈述中，并非所有类都是明显给出的，有些是隐含在问题域或一般知识中的。 检查问题陈述中的所有名词，产生如下的暂时类： 软件 银行网络 出纳员 自动出纳机 分行 分理处 分理处计算机 帐户 事务 出纳站 事务数据 分行计算机 现金卡 用户 现金 收据 系统 顾客 费用 帐户数据 访问 安全措施 记录保管 根据下列标准去掉不必要的类和不正确的类： 冗于类：若两个类表述了同一个信息，保留最富有描述能力的类，如“用户”和“顾客”就是重复的描述，因为“顾客”最富描述性，因此保留它。 不相干的类：除掉与问题没有多少关系或根本没关系的类。例如，摊派“费用”超出了银行网络系统的范围。 :模糊类：类必须是确定的，有些临时类边界定义不对或范围过大，如“记录保管”为模糊类，它是“事务”中的一部分。在银行网络系统中，模糊类有“系统”、“安全措施”、“记录保管”及“银行网络”等，应删除。 属性：如果某一个性质的独立性很重要，就应该把它归属到类，而不是属性。而有些候选类是属性，如“帐户数据”、“收据”、“现金”及“事务数据”，属于属性，应删除。 操作：如果所描述的操作并不适用于对象并且被其自身所操纵，那么这一定不是类，具有自身性质的操作应该描述成类。如构造电话模型，“拨号”就是状态模型一部分而不是类，但是在电话系统中，“拨号”却是一个重要的类，它有日期、时间、通话时长等属性。 确定关联 关联常用描述性动词或动词词组来表示，其中有物理位置的表示、传导的动作、通信、所有者关系及条件的满足等。从问题陈述中抽取所有可能的关联表述，把它们记下来，但不要过早去细化这些表述。 下面是银行网络系统中所有可能的关联，大多数是直接抽取问题中的动词词组而成。在陈述中，有些动词词组表达的关联是不明显的。还有一些关联与客观世界或人的假设有关，必须同用户一起核实这种关联，因为这种关联在问题陈述中找不到。 银行网络系统问题陈述中的关联如下所示： 银行网络包括出纳站和自动出纳机 分行共享自动出纳机 分理处提供分理处计算机 分理处计算机保存帐户 分理处计算机处理帐户支付事务 分理处拥有出纳站 出纳站与分行计算机通信 出纳员为帐户录入事务 自动出纳机接受现金卡 自动出纳机与用户接口 自动出纳机发放现金 自动出纳机打印收据 系统处理并发访问 分理处提供软件 费用分摊给分理处 隐含的动词词组 分行由分理处组成 分理处拥有帐户 分行拥有分行计算机 系统提供记录保管 系统提供安全 顾客有现金卡 基于问题领域的知识 分理处雇用出纳员 现金卡访问帐户 去掉不必要和不正确的关联 使用以下标准去掉不必要和不正确的关联： 若某个类已被删除，那么与它有关的关联也必须删除或者用其他类来重新表述。如删除了“银行网络”，相关的关联也要删除。 不相干的关联或实现阶段的关联。删除所有问题域之外的关联或涉及实现结构中的关联，如“系统处理并发访问”就是一种实现的概念。 动作。关联应描述应用域的结构性质而不是瞬时事件，因此应删除“自动出纳机接受现金卡”，“自动出纳机与用户接口”等。 派生关联。省略那些可以用其他关联来定义的关联。 银行网络系统的初步类图 3．确定属性 属性是个体对象的性质，属性通常用修饰性的名词词组来表示。形容词常表示具体的可枚举的属性值，属性不可能在问题陈述中完全表述出来，必须借助于应用域的知识及客观世界的知识才可以找出它们。 只考虑与具体应用直接相关的属性。按下列标准删除不必要的和不正确的属性。 类：若实体的独立存在性比它的值更重要，那么这个实体不是属性而是类。如在邮政目录中，“城市”是一个属性，然而在人口普查中，“城市”则被看作是类。 限定词：若属性值固定下来后，能减少关联的重数，则可考虑把该属性重新表述为一个限定词。如银行码、站代码及雇员号等限定词不作为属性。 内部值：若属性描述了类的非公开的内部状态，则应从类模型中删除该属性。 细化：在分析阶段应忽略那些不可能对大多数操作有影响的属性。 4．使用继承来细化类 使用继承来共享公共结构，以次来重新组织类，可以用下面两种方式来进行： 自底向上通过把现有类的共同性质一般化成父类，寻找具有相似的属性、关联或操作的类来发现继承。例如，“远程事务”和“出纳事务”是类似的，可以一般化为“事务”。 自顶向下将现有类细化为更具体的子类。当同一关联名出现多次且意义也