【学习课件】第十一章物件资料结构塑模

第十一章物件资料结构塑模面向对象系统分析与设计·类图与对象图的核心建模方法Contents本章目录物件结构塑模的核心概念、方法与实战指南01导论：物件结构塑模概述02类别图与物件图核心概念03物件结构塑模方法与封装04建构类别图与物件图实战CHAPTER01导论：物件结构塑模概述理解物件结构塑模在面向对象系统开发中的定位与价值SystemArchitecture物件导向系统发展流程中的结构塑模物件结构塑模是面向对象系统开发中承上启下的关键环节：它在使用个案塑模完成后启动，将需求分析转化为系统的静态架构蓝图，为后续的行为塑模和系统实现奠定结构基础。软件工程团队架构讨论场景双轨并行：使用个案塑模完成后，系统进入架构阶段，需同步开展物件互动行为塑模与物件结构塑模两项核心活动静态骨架：物件结构塑模聚焦于系统内部的静态结构描述，定义物件类型、类型间关系及子类型层次，形成系统的"骨架"质量前提：结构塑模的成果直接影响后续行为塑模的质量——只有先明确"有哪些对象"，才能准确描述"对象如何协作"双重视角：完整的系统架构需要结构视图与行为视图双重支撑，物件结构塑模提供了不可或缺的静态视角UMLStructuralModeling类别图与物件图的定义与用途类别图与物件图是物件结构塑模的两大核心工具：类别图从"类型"层面描述系统的静态结构蓝图，物件图从"实例"层面捕捉系统在特定时间点的快照，两者互补构成完整的结构视图。ClassDiagram类别图(ClassDiagram)主要用于表达系统内部的静态结构，描述系统中物件的类型及类型间的静态关系涵盖类型与子类型之间的层次关系，是系统架构设计阶段最重要的建模工具属于"设计蓝图"层面，定义了一类对象的共性特征，不关注具体实例的状态ObjectDiagram物件图(ObjectDiagram)描述系统在某一特定时间点的静态结构，是类别图在具体运行时刻的实例化快照可用来表达系统的复杂资料结构，帮助开发者理解运行时的对象连接关系可藉由时间序列的系统影像来表达系统行为，展示对象状态随时间的变化白板手绘UML类图·类型与关系的静态蓝图运行时对象实例化快照·特定时间点的系统状态Object-OrientedModeling物件与类别的核心关系类别是物件的抽象模板，定义了属性与操作的规范；物件是类别的具体执行个体，承载了真实的数据值。理解'模板-实例'的关系是掌握物件结构塑模的认知基石。类别定义模板类别(Class)描述物件结构的模板，定义组成物件的属性(Attribute)与栏位，规定物件"应该有什么"属性规范物件承载数据物件(Object)是类别的执行个体，每个物件都拥有类别定义的属性，但各自持有不同的属性值执行个体一模具多零件同一类别可产生多个物件实例，如同一个模具可铸造多个零件——结构相同但数据各异一对多类型与实例层类别图中的关系描述"类型层面"的约束，物件图中的连接线描述"实例层面"的实际关联层级区分CHAPTER02类别图与物件图核心概念深入理解类别与物件的组成元件、类别种类及四种核心关系UML·COMPONENTS类别图与物件图的主要元件类别图由'类别'和'类别间关系'两大元件构成，物件图由'物件'和'连接线'两大元件构成。前者描述类型层面的设计蓝图，后者展示实例层面的运行快照，两者在元件层面形成精确对应。类别图·类型层面的设计蓝图物件图·实例层面的运行快照类别图的两大元件01类别(Class)：一群相关物件的定义、描述或模板，具有名称、属性与操作三个核心组成部分02类别间关系：描述不同类别之间的静态连接方式，包括相依、一般化、关联与实现化四种核心关系物件图的两大元件03物件(Object)：类别的具体执行个体，拥有类别定义的全部属性但各自持有不同的属性值04连接线(Link)：物件实例之间的实际关联，反映了系统运行时对象之间的通信与数据传递路径Object-OrientedAnalysis类别的三种实作类型（BCE模式）从实作观点，类别分为实体类别(Entity)、界面类别(Boundary)和控制类别(Control)三种，合称BCE模式。实体类别Entity以企业领域术语命名，如"客户""订单"，表示使用个案完成后仍需储存在数据库中的资料。通常为永存类别，但某些实体类别如搜寻结果属于暂存资料，用例执行结束后即消失。PersistentData界面类别Boundary包含表单、报表、硬件界面等与系统沟通的界面，是行为者与系统交谈的媒介。属性包含界面上的元件如栏位、超连结、按钮等；操作负责将用户输入传递给控制类别。UserInterface控制类别Control负责协调其他类别的工作，传送讯息并指派任务，同时选择执行流程和处理错误。一个使用个案至少需搭配一个控制类别，藉由其控制使用个案中各项事件的发生顺序。BusinessFlowObject-OrientedDesign类别的执行分类与属性可视性从执行观点，类别分为永存类别(Persist)与暂存类别(Transient)；而属性的可视性(Visibility)机制则控制着哪些对象能存取特定属性或操作，是实现封装原则的核心手段。永存类别用例执行完成后仍需储存在数据库中的资料，如客户、订单等核心业务实体Persist暂存类别程序执行过程中临时创建，执行完毕后即被删除，如界面类别和控制类别Transient可视性定义定义哪些物件能存取或使用类别的属性与操作，常见级别包括public、private和protectedVisibility封装机制通过限制外部访问保护内部数据完整性，降低系统耦合度，实现物件封装的关键机制EncapsulationUMLClassDiagram类别间四种核心关系总览物件导向塑模中类别间存在四种核心关系：相依(Dependency)、一般化(Generalization)、关联(Association)和实现化(Realization)。这四种关系按耦合强度从弱到强排列，各有独特的语义含义和图形符号，共同构成类图的关系表达体系。四种关系对比总览关系类型核心语义图形符号耦合强度相依关系Dependency一个类别"使用"另一个类别虚线箭头最弱关联关系Association类别间的静态结构连接实线（可带箭头）较弱实现化关系Realization类别"实现"接口定义虚线空心三角较强一般化关系Generalization子类别"继承"父类别特性实线空心三角最强四种关系按耦合强度递增排列，相依最弱、一般化最强，各有独特的图形符号UMLRELATIONSHIPS相依关系(Dependency)详解相依关系是类别间最弱的"使用"关系，表示一个类别依赖另一个类别的服务。被依赖方的变更可能波及依赖方，但反向不成立。其虚线箭头符号直观表达了这种单向的、松散的影响传递方向。代码开发中的依赖关系示意01使用关系的本质：相依关系是一种"使用"关系（UsingRelationship），表示一个类别在某个操作中会用到另一个类别的服务。02单向影响特征：被使用类别的改变可能会影响使用它的类别，但使用类别的改变不会反向影响被使用类别。03图形符号：虚线箭头，箭头方向由使用类别指向被使用类别，清晰表达单向影响传递。04实际案例：Window类别使用Event类别处理事件，Event的更改会影响Window的操作行为，箭头由Window指向Event。UMLRELATIONSHIPS一般化关系(Generalization)详解一般化关系即继承关系，子类别自动继承父类别的属性与操作并可扩展特有特征。继承机制父类别与子类别间的继承关系，子类别自动继承父类别的全部属性与操作，实现代码复用与功能扩展。属性继承方法复用继承特殊化从一般概念中细化出具有特定性质的子类型，是一般化的反向操作，体现由抽象到具体的设计过程。概念细化类型派生细化图形符号实线加空心三角形，箭头由子类别指向父类别，精确表达is-a语义关系，是UML标准表示法。空心三角实线连接is-a应用实例客户为父类别，个人客户与公司客户各自继承共有特征并扩展特有属性，形成清晰的层次结构。层次建模特征扩展客户UMLClassDiagram·Relationships关联关系(Association)详解关联关系是类别间最常见的静态结构连接，表达对象之间的"知道"与"引用"。通过多重性约束、角色名标注以及聚合/组合两种特殊形式，关联关系能精确描述复杂的业务对象连接网络。静态结构连接关联关系描述类别间的静态结构连接，意谓一类别之物件知道另一类别物件的存在并可相互引用。这种引用关系是对象协作的基础，决定了系统运行时对象间的消息传递路径与依赖范围。引用Reference多重性约束Multiplicity规定连接两端的对象数量约束，如"1对多"表示一个对象可关联多个对方对象。常见表达包括1、0..1、*、1..*等形式，精确界定业务规则中的数量关系与可选性要求。1:NMultiplicity聚合与组合聚合是"has-a"松耦合关联，部分可独立存在；组合是"owns-a"强耦合关联，整体销毁则部分随之销毁。两者通过空心与实心菱形符号区分，反映对象间生命周期的依赖强度差异。has-a/owns-a

◆图形符号标注实线连接可附加箭头表示导航方向、角色名标注参与角色、多重性数值约束连接规模。这些标注元素共同构成完整的关联语义，使类图能够准确传达设计意图与实现约束。Line+Arrow+LabelUMLRELATIONSHIPS实现化关系(Realization)详解实现化关系连接接口与实现类，接口定义操作规范而实现类提供具体代码。这种"规范-实现"的分离机制是面向对象多态性的基础，使系统能在不改变调用方代码的前提下灵活替换不同的实现策略。接口与实现类实现化关系用于接口与实现类之间，接口定义操作规范，实现类提供具体的操作代码。Interface图形符号识别图形符号为虚线加空心三角形，与一般化关系的实线空心三角形区分——前者强调"实现规范"，后者强调"继承特性"。---▷与一般化的区别一般化继承已有实现，实现化按接口规范自行提供全新的实现逻辑，两者在语义与代码层面截然不同。extendsvsimplements实际应用场景广泛应用于Java的implements、C#的接口实现，是实现多态性和策略模式的关键机制。PolymorphismUML·CASESTUDY四种关系综合案例：在线教育平台通过在线教育平台的建模案例，四种关系在同一系统中协同运作：一般化构建类型层次，关联描述对象连接，相依表达松散依赖，实现化分离接口规范与具体实现，共同构成完整的系统静态结构。一般化"在线课程"继承"课程"父类，获得共有属性并扩展URL和时长等特有特征，形成清晰的类型层次结构Inheritance关联"教师"与"课程"之间为多对多关联，描述教学资源的静态分配结构，支持灵活的教学安排Association相依"课程"类的操作方法中使用"日志服务"记录行为，日志变更可能影响课程操作，体现运行时依赖Dependency实现化"课程"类实现"可搜索"接口，按接口规范提供具体的搜索匹配逻辑，支持多态扩展RealizationDESIGN四种关系按耦合度递增选择：优先使用弱耦合的相依和关联，谨慎使用强耦合的一般化INTERFACE通过实现化关系引入接口抽象，可在不修改调用方代码的前提下灵活替换底层实现策略CHAPTER03物件结构塑模方法与封装掌握物件结构塑模的系统化方法论与类别封装的核心原则METHODOLOGY物件结构塑模的系统化方法论物件结构塑模遵循"提取概念→定义属性操作→识别关系→迭代优化"四步法，螺旋推进以提炼系统静态结构蓝图。团队协作·系统设计讨论01从使用个案描述中提取关键业务概念作为候选实体类别，如"客户""订单""商品"等领域术语概念02为每个类别定义属性（数据字段）和操作（方法函数），明确对象"有什么数据"和"能做什么事"定义03识别类别间的关系类型（相依、一般化、关联、实现化）并确定多重性约束关系04通过反复审查和团队讨论迭代优化类图，确保模型准确反映系统静态结构且无冗余或缺失迭代ENCAPSULATION类别封装的核心原则与实践封装将对象的内部数据和实现细节隐藏，仅通过公开接口与外界交互。这一原则保护了数据完整性、降低了系统耦合度，是构建可维护、可扩展软件系统的基石。封装的本质隐藏对象内部数据和实现细节，仅暴露必要的公开接口，外部代码必须通过预设方法访问对象InterfaceAccess数据完整性保护属性设为private，通过getter/setter方法控制访问，可在方法内加入数据验证和边界检查逻辑PrivateFields降低系统耦合度内部实现变更时只要公开接口不变，依赖方无需修改，实现"修改局部化"的设计目标Decoupling可视性级别运用public接口供外部调用，private方法作为内部辅助，protected用于继承体系内的共享VisibilityLevelsOOP·Encapsulation封装实践案例：银行账户类别设计以银行账户为例，将余额属性封装为private并通过deposit/withdraw方法控制访问，可在方法内嵌入金额验证和余额检查逻辑。反之若属性全部公开，外部代码可随意篡改数据，系统的可靠性和数据一致性将完全丧失保障。正确封装的设计balance属性设为private，外部只能通过deposit和withdraw方法修改余额，确保所有变更都经过验证deposit方法内置金额>0的检查，withdraw方法内置余额充足性验证，防止非法操作导致数据异常内部实现可随时调整（如增加交易日志记录），只要公开方法签名不变，调用方代码无需任何修改违反封装的后果若balance为public，外部可直接赋值为负数或超大金额，数据完整性完全依赖调用方的自律一旦内部数据结构变更（如将余额改为多币种存储），所有直接访问该属性的代码都需同步修改，耦合度极高缺乏访问控制的封装边界，使得调试困难、安全隐患累积，系统维护和扩展成本显著增加UMLOBJECTDIAGRAM物件图的典型应用场景物件图在四个关键场景中发挥不可替代的作用：表达复杂数据结构的实例化视图、验证类图设计的正确性、通过时间序列展示系统行为演变，以及辅助测试调试阶段的运行状态分析。表达复杂数据结构当类图关联关系复杂时，用具体实例的物件图可直观展示对象间的实际连接方式和数据值，帮助理解抽象类图的具体表现形式。实例化视图验证类图正确性若某个业务场景无法用物件图实例化表达，说明类图设计可能存在缺失或不合理之处，需要重新审视模型结构。业务场景时间序列行为展示在不同时间点分别绘制物件图，通过快照对比展示对象状态和连接关系的动态演变过程，呈现系统运行轨迹。动态演变测试与调试辅助在系统测试阶段，物件图帮助开发者理解特定时刻的运行状态，快速定位对象连接异常和数据传递问题。数据传递CHAPTER04建构类别图与物件图实战掌握从需求到完整类图的建构步骤、设计准则与常见错误防范ClassDiagramConstruction建构类别图的五步流程类别图建构遵循"需求收集→筛选分类→属性操作定义→关系识别→审查优化"的五步流程。每一步都有明确的目标和产出，整个流程是螺旋迭代的——后续步骤可能触发对前序步骤的修正和补充。01需求收集仔细阅读使用个案描述，标注所有名词短语作为候选类别，如"客户""订单""商品"等。从需求文档中提取关键业务概念，建立初步词汇表。候选名词02筛选分类去除重复、模糊和超出范围的概念，按BCE模式将类别分为实体、界面和控制三类。确保每个类别职责单一、边界清晰。BCE模式03属性操作定义为每个类别确定数据字段与方法函数，遵循封装原则设置合理的可视性。属性描述状态，操作定义行为，形成完整接口。封装原则04关系识别分析类别间的相依、一般化、关联和实现化关系，标注多重性约束和角色名称。明确导航方向与依赖强度。多重性约束05审查优化检查遗漏类别、错误关系和不合理多重性，通过团队评审迭代改进直至模型稳定。验证模型满足所有功能需求。螺旋迭代UML建模方法论建构物件图的实战步骤物件图建构以已完成的类别图为基础，选择特定业务场景后为每个类别创建具体实例并赋予真实数据值。物件图是验证类图正确性的'试金石'——如果某个场景无法实例化，说明类图设计存在缺陷。前置条件：确保类别图已基本完成，物件图是类别图的实例化表达，无类图则无法创建有效的对象图Prerequisite选择业务场景：确定要描述的具体时刻和用例路径，物件图必须有明确的场景边界和时间点定义Scope创建物件实例：为涉及的每个类别创建具体对象，赋予真实的属性值（如'张三，ID=001，北京市'）Instantiate绘制连接线：根据场景需要画出物件间的实际关联，标注关联数据，确保每条连接线对应类图中的关系Connect一致性验证：检查每个物件是否为某类别的合法实例、每条连接是否符合类图定义的关系和多重性约束ValidateDESIGNPRINCIPLES类别图设计准则与最佳实践高质量的类别图设计遵循五大准则：单一职责确保专注性，高内聚低耦合控制复杂度，合理使用继承避免滥用，接口隔离防止胖接口，统一命名规范提升可读性。结构设计准则单一职责原则每个类别只负责一个明确的功能领域，避免将不相关的属性和操作塞进同一个类SRP高内聚低耦合类内部属性和操作高度相关，类间依赖尽可能少，优先使用弱耦合关系COHESION合理使用继承继承必须满足is-a语义，不要为代码复用而滥用，组合有时更合适INHERITANCE规范与质量准则接口隔离原则定义小而专的接口，让实现类只需实现自己需要的操作，避免功能臃肿的胖接口ISP命名规范统一类别名用名词、操作名用动词、属性名用名词短语，保持全项目一致的命名风格NAMINGUMLBestPractices常见建模错误与防范策略类别图建模中五类常见错误严重影响系统质量：'上帝类'违反单一职责、过度继承导致脆弱基类、循环依赖阻碍编译、忽略多重性造成实现歧义、混淆聚合与组合导致生命周期管理混乱。识别并避免这些错误是建模能力成熟的标志。上帝类问题单个类承载过多职责导致难以维护，应拆分为多个职责明确的小类并通过关联关系协作SingleResponsibility过度继承陷阱继承层次超过三层时任何修改都会波及所有子类，应优先考虑组合替代深层继承≤3层循环依赖风险闭环依赖导致系统无法编译，应引入中间接口或重构依赖方向打破循环BreaktheCycle多重性遗漏关联关系不标注多重性会导致实现时无法确定用单一引用还是集合类型1..*聚合与组合混淆组合要求同生共死，聚合允许部分独立存在，需明确区分生命周期关系LifecycleUMLClassDiagram·CaseStudy实战案例：电商订单系统类图建构电商订单系统的类图建构完整演示了从需求提取到模型落地的全过程：五大实体类别构成业务骨架，界面类别和控制类别完成BCE模式配置，关联、继承、相依三种关系编织对象网络，封装策略保障数据安全和低耦合。领域模型提取实体类别："客户"、"订单"、"商品"、"支付"、"物流"五个核心业务概念从需求描述中直接提取。界面与控制类别："登录界面"、"订单表单"负责用户交互，"订单控制器"、"支付控制器"协调业务流程。5核心实体关系网络设计关联关系：客户与订单为1对多关联，订单与商品为多对多关联并引入"订单明细"中间类解析。继承与相依："在线支付"和"货到付款"继承"支付"父类；"订单控制器"使用"邮件服务"构成相依关系。3种关系封装与质量控制封装策略：所有实体类属性设为private，通过public的getter/setter方法控制外部访问并嵌入数据验证逻辑。解耦设计：控制类作为中间协调者隔离界面类与实体类的直接依赖，实现表现层与数据层的解耦。低耦合UML·ASSOCIATION关联关系多重性的常见模式多重性约束直接决定了对象间的数量关系和实现时的数据结构选择：1对1对应单一引用，1对多对应集合容器，多对多需引入中间类拆解。准确的多重性标注是类图到数据库设计和代码实现的桥梁。常见多重性模式对照多重性模式业务示例实现方式注意事项1对1员工↔工卡单一对象引用需确定哪一端持有引用1对多(1..*)部门↔员工'1'端持有集合容器需考虑集合类型(List/Set)多对多(*..*)学生↔课程引入中间类拆解为两个1对多中间类可携带关联属性0..1对1会员↔优惠券可选引用(nullable)需处理空值判断逻辑0..*对1评论↔商品'1'端持有可选集合允许空集合的情况五种常见多重性模式各有对应的实现方式和注意事项，准确标注是代码实现的基础DESIGNPATTERN抽象类与接口的设计策略抽象类提供共享模板但不能实例化，接口定义行为规范但不含实现。两者的选择取决于设计意图：需要复用部分实现用抽象类，需要定义纯粹的行为契约用接口。ABSTRACTCLASS核心定义不能直接实例化的类别，作为父类为子类别提供共享的属性与操作模板，名称以斜体或{abstract}标注模板复用继承机制ABSTRACTCLASS实现机制可同时包含抽象操作与具体操作，子类必须实现所有继承的抽象操作，为代码复用提供结构化基础混合实现强制约束INTERFACE核心定义纯粹的行为规范定义，只包含操作声明不含属性和实现代码，用圆圈或{interface}标注契约定义解耦设计INTERFACE扩展能力一个类可实现多个接口，弥补单一继承的限制，是定义系统扩展点和插件机制的关键工具多实现插件架构CODEMAPPING从类别图到代码实现的映射类图的每个元素都有对应的代码实现方式：类别映射为class定义，属性映射为字段并匹配访问修饰符，关联映射为对象引用或集合容器，一般化映射为extends继承，实现化映射为implements接口实现。掌握映射关系可确保建模成果直接指导编码。类图元素到代码的映射关系类图元素代码映射Java示例类别Classclass定义publicclassCustomer{...}属性Attribute字段+访问修饰符privateStringname;操作Operation方法定义publicvoidplaceOrder(){...}一般化extends继承classOnlineCourseextendsCourse实现化implements接口classCourseimplementsSearchable1对多关联集合字段privateList<Order>orders;相依关系方法参数/局部变量voidsend(LogServicelog){...}类图各元素均有明确的代码映射方式，建模时应同步考虑实现可行性UML·ABSTRACTION类图的三个抽象层次概念层对齐需求、规格层定义接口、实现层映射代码——不同阶段需要不同层次的类图，避免在概念讨论阶段陷入实现细节。概念层Conceptual描述业务领域的概念模型，关注"有哪些概念"和"概念间的关系"，不