第六讲信息系统分析.pptVIP

* 还书的顺序图 * 协作图(Collaboration Diagram) 协作图的元素和表示方法与顺序图基本相似，但不表达生命线和消息物理位置，而增加对象消息连接。 消息连接显示为两个对象之间的一条实线，其上附带消息、消息流向和消息的顺序号。 协作图显示对象之间的关系，它更有利于理解对给定对象的所有影响，也更适合过程设计。 UML2.0中改为通信图，但语义没有改变。 * 协作图/通信图 协作图一般可由建模工具自动从顺序图生成，与顺序图是等价的。 * * * * * * * * * * * 每一个用例都是表达一个用户目标，用例图表达用户目标的集合，用例图中不表达业务的顺序和流程的关系。 * * 通用关联分类表 分 类 举 例 A在物理上是B的一部分 零件——产品 A在逻辑上是B的一部分 订单项——订单 A在物理上包含在B中/依赖于B 产品——仓库 A在逻辑上包含于B中 图书品种——图书 A是对B的描述 产品规格——产品 A是事务B或报告B的一个记录项 购物——购物项 A为B所知/为B所记录/录入到B中 借书记录——读者 A是B的一个成员 职工——部门 A是B的一个组织单元 分公司——集团 A使用或管理B 医生——病案；医生——挂号单 A与B相互通信 图书管理员——读者 A与一个事务B有关联 图书——借书记录 A是一个事务，B也是一个事务，二者有关联 借书记录——逾期记录 * 6、关联原则 找出问题域中的对象远远比找出关联更为重要 注意力集中在那些需要将对象之间的关系信息记忆一段持续时间的关联 关联太多不仅不能有效展示概念模型，反而会使概念模型变得混乱 要避免关联之间的信息冗余以及减少派生关联 关联使用关联名称、角色、多重性和导向性来说明 * 图书馆系统的第3张类图 * POS系统的对象关联 收款机 Register 销售项 Sale 支付 Payment 商店 Store 1 拥有 1..* 记录 1 1..* 被支付 1 1 销售项条目 SalesLineItem 包含 1 1..* * * 2.5.4 类的泛化 泛化（Generalization）是在多个概念之间识别共性，定义超类（一般概念）和子类（特定概念）关系的活动。 如在图书馆系统中，发现图书馆目前还收藏了其它资源，比如影碟（VCD/DVD）、音乐CD、电子书等品种。它们和图书一样可以被任何读者借出，每个对象都有条码和状态。但它们也有自己的特性，比如属性项、借阅期限、逾期惩罚不同，必须区别对待。 * 1、一般-特殊结构(Generalization-Specialization) 如果类A具有类B的全部属性和行为，而且具有自己特有的某些属性或服务，则A叫做B的特殊类，B叫做A的一般类。这种关系也称为一般-特殊关系、泛化-特化关系、继承关系。 特点： 可以简化模型，有效地反映问题空间的分类层次。 必须确认子类一定是父类的一个特殊类型，即可以用“is-a-kind-of”进行验证 注意控制泛化的粒度，额外的泛化增加复杂性 * 图书馆系统的泛化关系 * 2、什么时候需要划分一般-特殊结构 类的属性或行为不适合该类的全部对象 如果定义“学生”类有“导师”属性，有“教学实践”行为的话，则该类的对象对于本科生不适合，只适合于研究生对象，采用一般-特殊结构重新分类，建立“学生”和“研究生”之间的一般-特殊结构，研究生可以继承所有学生的特性。 属性和行为相似的类 将这些类的共性抽象出来作为超类，各自特性仍旧保留而作为超类的子类。 不要将一个对象的状态变化设计为多个子类，除非对象的多数行为是由状态来决定 * 病态的继承 泛化是提高软件重用性的一种机制，但不能为了重用而滥用泛化。 不符合”is a kind of” 采用组装结构，将复用对象作为组成元素 * 3、抽象类 如果一般类A的每个实例还必须是它的一个特殊类的成员，那么类A就被称为一个抽象类。 比如“学生”、“研究生”中，“学生”不是一个抽象类 比如“支付”、“现金支付”、“信用卡支付”中，“支付”就是一个抽象类 但面向对象的设计原则强调设计抽象类，比如学生，设计一个抽象学生类，然后派生出本科生和研究生 抽象类意味着不能创建该类的实例 * 4、多继承 继承有单继承和多继承。 多继承是指一个子类继承了两个父类的属性和行为。 * 多继承的问题 如果某个类从若干个类中进行继承，就必须检查祖先中操作和属性的命名（同名处理）。 一般不建议使用多继承，解决方法是采用组装结构来描述： * 2.5.5 分析模型 静态模型： 类图 对象图 动态模型： 状态图 粗略的对象交互图 * 1、类图 类 会员 会员代号 姓名 地址 电话 租借记录 增加租借 取全部租借 类名 属性 服务/操作 类的一般-特殊关系(三