下载文档原格式
UML包图的模块交互与依赖关系分析UML（Unified Modeling Language）是一种用于软件开发的标准建模语言，它提供了一套图形化工具，帮助开发人员更好地理解和设计软件系统。
其中，UML包图是一种常用的图示工具，用于展示软件系统的模块结构和模块之间的关系。
在本文中，我们将探讨UML包图中的模块交互与依赖关系分析。
首先，让我们了解一下UML包图的基本概念。
在UML包图中，每个模块被表示为一个包（Package），它可以包含其他的包或类。
模块之间的关系可以用依赖关系（Dependency）、关联关系（Association）、聚合关系（Aggregation）等来表示。
这些关系反映了模块之间的交互和依赖。
在进行模块交互与依赖关系分析时，我们首先需要理清模块之间的交互关系。
通过观察UML包图中的关联关系和依赖关系，我们可以了解到哪些模块之间存在着数据或控制的交互。
例如，一个订单管理系统中的订单模块和客户模块之间可能存在着关联关系，表示订单模块需要获取客户信息来完成订单的创建和处理。
另外，订单模块可能还依赖于库存模块来检查商品的库存情况。
通过分析这些交互关系，我们可以更好地理解系统的功能和流程。
除了交互关系，模块之间的依赖关系也是一个重要的分析点。
在UML包图中，依赖关系表示一个模块对另一个模块的依赖。
这种依赖可以是静态的，也可以是动态的。
静态依赖表示一个模块在编译时依赖于另一个模块的接口或类，而动态依赖则表示一个模块在运行时依赖于另一个模块的实例或对象。
通过分析依赖关系，我们可以了解到哪些模块对其他模块有着较强的依赖，从而帮助我们进行模块的划分和设计。
在进行模块交互与依赖关系分析时，我们还可以考虑一些其他因素。
例如，模块之间的耦合度和内聚度。
耦合度表示模块之间的依赖程度，高耦合度意味着一个模块的改动会对其他模块产生较大的影响，而低耦合度则表示模块之间的独立性较高。
内聚度表示模块内部元素之间的关联程度，高内聚度意味着模块内部的元素紧密相关，功能清晰。
基于UML的图书管理系统的设计作者：张日如来源：《电脑知识与技术》2019年第10期摘要：统一建模语言（UML）是一种标准的建模语言，它具有很强大的功能性。
该文以图书管理为研究背景，运用UML设计出一套完整的图书管理系统，从而详细地介绍UML的基本模型。
较为详细地研究了UML的技术，并对其相关知识作了充分的阐述。
通过使用UML建立模型，很大程度上解决了客户与软件设计人员之间的交流障碍，使得开发过程进一步加快，开发质量得到进一步提高。
關键词：UML；静态建模；动态建模；面向对象中图分类号：TP311 文献标识码：A文章编号：1009-3044（2019）10-0081-03开放科学（资源服务）标识码（OSID）：图书馆是为人们提供阅读的地方，图书馆会不断搜集图书，通过整理后将这些文献展示给人们，因此图书馆日常管理工作的数量非常大。
实在科技高度发展的今天，传统到图书馆所提供的服务要远低于人们的需求。
因此建立一款依托于互联网技术，能够让读者更快捷、更便利地对图书进行搜索、借阅和归还，并且能够根据读者的不同需求提供对应服务，因此必须尽快建立一套实现图书信息资源的共享的图书管理系统。
从根本上看，图书馆里系统的最终目的就是为了减少成本的投入，同时大大地提高了工作效率，还要兼具系统在运行过程中可靠性很高、安全性稳定、存储容量大等特点。
此外还要保证系统能够简单上手、灵活操作、实用性强。
传统的基于过程的系统分析和设计技术采用将过程和数据分离的方法，效率低、可重用性低。
利用UML建立模型来描述面向对象的分析和设计思想具有较高的稳定性和可重用性，使得产品易于维护。
本篇论文以图书信息管理系统开发为例，较为详细地介绍了UML的关键技术以及UML建模所使用到的一些图，这些用例图、活动图等具有很好的代表性，同样适用于其他系统的建模操作。
1 UML建模的机制UML主要面向的是广大使用者，通过不同的图形符号来表示系统在实际操作中的类及对象等，具有更好的可视化效果啊。
东北大学软件工程与UML建模A卷(答案) XXX软件工程与UML建模试卷（作业考核线上1）A 卷研究中心：]院校学号：姓名（共4页）总分题号得分一二三四五六七八九十一、单选题（30分，共15题，每题2分）1．D是在系统之外，透过系统边界与系统进行有意义交互的任何事物A).相关系统B).Use CaseC).ClassD).Actor2.软件工程是以D为核心A).过程B).面向对象C).软件开发D).质量3.“系统开发过程和可交付文档将遵照ZCo-SP0STAN-95中相关规定”，这属于BA).功能性需求B).客观需求C).主观需求D).非功能性需求4.“系统每天晚上自动生成进货报表”，Actor是：CA).系统B).其它系统C).时间D).报表审阅者5.数据流程图是一个分层的概念模型，分三个层次：C，分别描述系统的不同特征A).总体图、二级图、三级图B).总体图、二级图、细节图C).总体图、零级图、细节图D).总体图、次级图、细节图6.以下用例命名中，最合理的是BA).进行宠物搜索B).查询宠物C).宠物查询D).进行宠物查询7.某系统中有两个用例：一个用例的参与者是用户，用例是“注册”；另一个用例的参与者是系统管理员，用例是“审核用户注册”。
这两个用例之间是什么关系？BA).包含关系B).没有关系C).扩展关系D).泛化关系8.在软件的层次结构中，“一个模块被其他模块直接调用的调用者的数量”是指B1课程名称:软件工程与UML建模A).深度B).扇入C).扇出D).耦合9.设C(X)定义问题X的复杂性函数，E(X)定义解决问题X所需要工作量的函数，对于两个问题p1和p2，一般情况下如果C(p1)<C(p2)则DA).E(p1)>E(p2)B).C(p1+p2)=C(p1)+C(p2)C).E(p1+p2)>E(p1 )+E(p2)D).E(p1+p2)<E(p1)+E(p2)10.以下各种图不是UML使用的图是CA).用例图B).类图C).数据流程图D).顺序图11.模块尺寸太大时，应AA).分解以进步内聚B).分解以进步耦合C).合并以提高内聚D).分解以降低内聚12.以下类的命名中，最合理的是AA). BusVehicleB). RoutesC). passengerD). Stop13.在软件过程中，下列活动属于辅助活动的是DA).设计B).集成C).退役D).风险管理14.下面用例模型体现了用例间的A关系A).泛化、包含和扩展B).包含和扩展C).分解、包括和扩充D).分解、包含和扩展15.下图体现了面向对象中类的CA).复杂性B).可传递性C).自反关联D).继承关系2课程名称:软件工程与UML建模二、简答题（40分，共4题，每题10分）1.请解释软件工程的含义。
基于UML的图书管理系统分析模型摘要：UML是一种面向对象系统进行可视化、详述描述、构造和文档化的标准建模语言，具有与人的思维方式一致、稳定性好、可重用性好、课维护性好等优点。
本文运用UML建模工具rose，根据用况和业务领域的模型，对图书管理系统中的借阅子系统进行了分析建模，并详细阐述了分析阶段具体的建模理论和实际的运用方法，完成了静态建模（类图、包图）和动态建模（协作图），从而进一步确定了系统内部结构的需求描述，得到一个易于维护的可视化分析模型。
关键词： UML 图书借阅系统分析模型0 引言本文研究工作的背景和研究目的传统的基于过程或者数据的系统分析和设计技术将过程和数据分离，生产效率低，软件重用度低，维护困难。
UML作为面向对象的建模语言，具有与人的思维方式一直、稳定性好、可重用性好、课维护性好等优点。
另外，通过使用UML 建模工具rose，能大大提高系统的开发得效率和质量。
图书管理系统是一个提供读者进行读书查询和借还书的信息平台。
在前期的需求分析（用况模型）的基础上，本文展开了系统的分析阶段,运用UML建模工具rose，结合统一过程的特点，整个项目实施可以分成需求、分析、设计、实现、测试五个阶段进行。
分析阶段的任务是，在需求阶段的工作成果（用况模型）基础上，更精确地理解系统需求，得到一个易于维护且有助于确定系统内部结构的需求描述——分析模型。
它既全面展示了分析阶段得到的分析类和类之间的关系，又定义了用况实现。
图书管理系统主要用况有：图书借阅、图书归还、图书信息管理、读者信息管理、图书检索。
本文以“借阅管理”用况为例，通过详细分析，展示该用况对应的分析模型的建立过程。
1分析相关理论介绍1.1分析理论概述分析是使用开发人员的语言更精确地描述系统需求和深入理解问题的过程，即从内部描述如何设计实现系统功能。
分析的目标是开发一个易于维护且有助于确定系统内部结构的可视化模型，而不依赖具体的实施技术。
第一章绪论1.1 软件工程概念的提出与发展1.2 软件开发的本质1.3 本章小结第二章软件需求与软件需求规约2.1 需求与需求获取2.1.1需求定义2.1.2 需求分类2.1.3 需求发现技术2.2 需求规约2.2.1 需求规约定义2.2.2 需求规约（草案）格式2.2.3 需求规约（规格说明书）的表达2.2.4 需求规约的作用2.3 本章小结第三章结构化方法3.1 结构化需求分析3.1.1 基本术语1.数据流2.数据存储3.数据源和数据谭3.1.2 系统功能模型表示数据流图（Dataflow Diagram）3.1.3 建模过程1.建立系统环境图, 确定系统语境2.自顶向下, 逐步求精, 建立系统的层次数据流图3.定义数据字典数据流条目给出所有数据流的结构定义数据存储条目给出所有数据存储的结构定义数据项条目给出所有数据项的类型定义4.描述加工（1）结构化自然语言（2）判定表（3）判定树3.1.4 应用中注意的问题（1）模型平衡问题（2）信息复杂性控制问题3.1.5 需求验证3.2 结构化设计3.2.1 总体设计1.总体设计的目标及其表示（1）Yourdon提出的模块结构图（2）层次图（3）HIPO图2.总体设计步骤（1）变换型数据流图——变换设计（2）事物型数据流图——事物设计3.模块化及启发式规则（1）模块化1）耦合①内容耦合②公共耦合③控制耦合④标记耦合⑤数据耦合2）内聚①偶然内聚②逻辑内聚③时间内聚④过程内聚⑤通信内聚⑥顺序内聚⑦功能内聚（2）启发式规则1）改进软件结构, 提高模块独立性2）力求模块规模适中3）力求深度、宽度、扇出和扇入适中4）尽力使模块的作用域在其控制域之内5）尽力降低模块接口的复杂度6）力求模块功能可以预测3.2.2 详细设计1.结构化程序设计2.详细设计工具（1）程序流程图（2）盒图（N-S图）（3）PAD图（Problem Analysis Diagram）（4）类程序设计语言IPO图、判定树和判定表等也可以作为详细设计工具3.3 本章小结第四章面向对象方法——UML 4.1 UML术语表4.1.1 表达客观事物的术语1.类与对象1）类的属性（Attribute）2）类的操作3）关于类语义的进一步表达①详细叙述类的职责（Responsibility）②通过类的注解和/或操作的注解, 以结构化文本的形式和/编程语言, 详述注释整个类的语义和/或各个方法③通过类的注解或操作的注解, 以结构化文本形式, 详述注释各个操作的前置条件和后置条件, 甚至注释整个类的不变式④详述类的状态机⑤详述类的内部结构⑥类与其他类的协作4）类在建模中的主要用途①模型化问题域中的概念（词汇）②建立系统的职责分布模型③模型化建模中使用的基本类型2.接口（Interface）（1）采用具有分栏和关键字《interface》的矩形符号来表示（2）采用小圆圈和半圆圈来表示3.协作（Collaboration）4.用况（Use Case）5.主动类（Action Class）6.构件（Component）7.制品（Artifact）8.节点（Node）4.1.2 表达关系的术语1.关联（Association）（1）关联名（Name）（2）导航（3）角色（Role）（4）可见性（5）多重性（Multiplicity）（6）限定符（Qualifier）（7）聚合（Aggregation）（8）组合（Composition）（9）关联类（10）约束①有序（ordered）②无重复对象（set）③有重复对象（bag）④列表（list）或序列（sequence）⑤只读（readonly）2.泛化（Generalization）①完整（Complete）②不完整（Incomplete）③互斥（Disjoint）④重叠（Overlapping）3.细化（Realization）4.依赖①绑定（Bind）②导出（Derive）③允许（Permit）④实例（InstanceOf）⑤实例化（Instantiate）⑥幂类型（Powertype）⑦精化（Refine）⑧使用（Use）可模型化以下各种关系（1）结构关系1）以数据驱动2）以行为驱动（2）继承关系（3）精化关系（4）依赖关系4.1.3 表达组合信息的术语——包1）访问（Access）2）引入（Import）4.2 UML模型表达格式1.类图（Class Diagram）（1）模型化待建系统的概念（词汇）, 形成类图的基本元素（2）模型化待建系统的各种关系, 形成该系统的初始类图（3）模型化系统中的协作, 给出该系统的最终类图（4）模型化逻辑数据库模式2.用况图（Use Case Diagram）所包含的内容（1）主题（Subject）（2）用况（Use Case）（3）参与者（Actor）（4）关联、泛化与依赖模型化工作1）关于系统/业务语境的模型化①系统边界的确定②参与者与用况的交互③参与者的语义表达④参与者的结构化处理2）关于系统/业务需求的模型化①确定系统/业务的基本用况②用况的结构化处理③用况的语义表达3.状态图（1）状态1）名字2）进入/退出效应（Effect）①entry②exit③状态内部转移3）do动作或活动4）被延迟的事件（2）事件1）信号（Signal）事件2）调用（Call）事件3）时间事件4）变化事件（3）状态转移①源状态②转移触发器③监护（guard）条件④效应（effect）⑤目标状态实际应用中, 使用状态图的作用①创建一个系统的动态模型②创建一个场景的模型4.顺序图（1）术语解析1）消息2）对象生命线3）聚焦控制（the Focus of Control）（2）控制操作子1）选择执行操作子（Operator for Optional Execution）2）条件执行操作子（Operator for Conditional Execution）3）并发执行操作子（Operator for Parallel Execution）4）迭代执行操作子（Operator for Iterative Execution）4.3 本章小结第五章面向对象方法——RUP5.1 RUP特点1.以用况为驱动2.以体系结构为中心3.迭代增量式开发5.2 核心工作流5.2.1 需求获取1.列出候选需求2.理解系统语境（1）业务用况模型（2）业务对象模型3.捕获系统功能需求（1）活动1: 发现并描述参与者（2）活动2: 发现并描述用况（3）活动3: 确定用况的优先级（Priority）（4）活动4: 精化用况（5）活动5: 构造用户界面原型1）用户界面的逻辑设计2）物理用户界面的设计3）开发用户界面原型并演示为了执行该用况, 用户怎样使用该系统（6）活动6: 用况模型的结构化5.2.2 需求分析1.基本术语（1）分析类（Analysis Class）1）边界类（Boundary Classes）2）实体类（Entity Classes）3）控制类（Control Classes）（2）用况细化（Use Case Realization）（3）分析包（Analysis Package）2.分析模型的表达3.分析的主要活动（1）活动1: 体系结构分析（Architectural Analysis）1）任务1: 标识分析包2）任务2: 处理分析包之间的共性3）任务3: 标识服务包4）任务4: 定义分析包的依赖5）任务5: 标识重要的实体类6）任务6: 标识分析包和重要实体类的公共特性需求（2）活动2: 用况分析1）任务1: 标识分析类①标识实体类②标识边界类③标识控制类2）任务2: 描述分析（类）对象之间的交互（3）活动3: 类的分析1）任务1: 标识责任2）任务2: 标识属性①关于实体类属性的标识②关于边界类属性的标识③关于控制类属性的标识3）任务3: 标识关联和聚合①关于关联的标识②关于聚合的标识③关于泛化的标识（4）活动4: 包的分析4.小结（1）关于分析模型1）分析包2）分析类3）用况细化（2）关于分析模型视角下的体系结构描述（3）用况模型和分析模型比较（4）分析模型对以后工作的影响1）对设计中子系统的影响2）对设计类的影响3）对用况细化[设计]的影响5.2.3 设计1.设计层的术语（1）设计类（Design Class）（2）用况细化[设计]（3）设计子系统（4）接口（Interface）2.设计模型、部署模型以及相关视角下的体系结构描述（1）设计模型及其视角下的体系结构描述1）子系统结构2）对体系结构有意义的设计类3）对体系结构有意义的用况细化[设计]（2）部署模型及该模型视角下的体系结构描述3设计的主要活动（1）活动1: 体系结构的设计1）任务1: 标识节点和它们的网络配置2）任务2: 标识子系统和它们的接口①标识应用子系统②标识中间件和系统软件子系统③定义子系统依赖④标识子系统接口3）任务3: 标识在体系结构方面有意义的设计类和它们的接口4）任务4: 标识一般性的设计机制①标识处理透明对象分布的设计机制②标识事务管理的设计机制（2）活动2: 用况的设计1）标识参与用况细化的设计类2）标识参与用况细化的子系统和接口（3）活动3: 类的设计1）任务1: 概括描述设计类2）任务2: 标识操作3）任务3: 标识属性4）任务4: 标识关联和聚合5）任务5: 标识泛化6）任务6: 描述方法7）任务7: 描述状态（4）活动4: 子系统的设计1）任务1: 维护子系统依赖2）任务2: 维护子系统所提供的接口3）任务3: 维护子系统内容4.RUP设计小结1）RUP设计的突出特点2）关于RUP的设计方法①给出用于表达设计模型中基本成分的4个术语, 包括子系统, 设计类, 接口, 用况细化[设计]②规约了设计模型的语法, 指导模型的表达③给出了创建设计模型的过程以及相应的指导3）RUP的设计模型①设计子系统和服务子系统②设计类（其中包括一些主动类）, 以及他们具有的操作、属性、关系及其实现需求。
选择题1、文档是软件产品的一部分，没有文档的软件就不称其为软件。
（ ）2、在需求分析过程中，分析员要从用户那里解决的最重要的问题是给该软件提供哪些信息。
（ ）3、需求规格说明书在软件开发中具有重要的作用，它也可以作为软件可行性分析的依据。
（ ）4、建立用例模型的步骤包括确定角色、确定用例和绘制用例图。
（ ）5、数据流图建立系统的功能模型，它由数据流、加工和数据存贮组成。
（ ）6、软件配置管理是一组标识、组织和控制修改源程序的活动。
（ ）7、UML是一种直观化、明确化、构建和文档化软件产物的通用语言。
8、好的测试是用少量的测试用例运行程序，发现被测程序尽可能多的错误。
（ ）9、边界值分析方法是取输入/输出等价类的边界值作为测试用例。
（ ）10、面向对象的分析是面向计算机系统建立软件系统的对象模型。
（ ）11、在软件开发的过程中，若能推迟暴露其中的错误，则为修复和改正错误所花费的代价就会降低。
（ ）12、在需求分析中，分析员要从用户那里解决的最重要的问题是明确软件做什么。
（ ）13、软件需求规格说明书在软件开发中具有重要的作用，是软件可行性分析的依据。
（ ）14、模型是对现实的简化，建模是为了更好地理解所开发的系统。
（ ）15、UML语言支持面向对象的主要概念，并与具体的开发过程相关。
（ ）16、用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现。
（ ）17、好的测试用例应能证明软件是正确的。
（ ）18、白盒测试仅与程序的内部结构有关，完全可以不考虑程序的功能要求。
（ ）19、当软件开发项目的进度有可能拖延时，增加开发人员并不能加快进度。
（ ）20、软件技术复审是由用户和测试人员实施的一种质量保证活动。
（ ）21、在项目计划发生延迟的情况下，增加更多的程序员一定会加快进度。
（ ）22、软件错误可能出现在开发过程的早期，越早修改越好。
（ ）23、不完善的系统定义往往是导致软件项目失败的主要原因。
>>uml在软件开发各个阶段的应用：
采用面向对象技术设计软件系统时，使用用例图来描述用户需求；使
用类图、对象图、包图、构件图和部署图描述系统的静态结构；使用
顺序图、合作图、活动图和状态图描述动态行为。
抽象得到类、属性、方法；关系来描述；组织成类图。
部署图：将来在现场如何实现的设备等。
状态图：状态转换过程（状态机）。
>>specific diagrams for each phase:
--需求：用例图描述需求（角色、功能、外部交互）
--分析：明确解决问题的细节
类图来描述静态结构；
顺序图、合作图、活动图、状态图来描述动态结构；
--设计：给出解决方案
类图、包，对类的接口进行设计
--实现：将类用某面向对象语言实现
--集成与交付：
构件图、包、部署图
--测试
·单元测试使用类图和类的规格说明书
·集成测试使用类图、包、构件图和合作图
·系统测试使用用例图来测试系统功能
>>内聚类型
内聚强度类型[从低到高]：
（1）偶然内聚
如果一个模块的各成分之间毫无关系，则称为偶然内聚，也就是说模块完成一组任务，这些任务之间的关系松散，实际上没有什么联系。
（2）逻辑内聚
几个逻辑上相关的功能被放在同一模块中，则称为逻辑内聚。
如
一个模块读取各种不同类型外设的输入。
尽管逻辑内聚比偶然内聚合
理一些，但逻辑内聚的模块各成分在功能上并无关系，即使局部功能
的修改有时也会影响全局，因此这类模块的修改也比较困难。
（3）时间内聚
如果一个模块完成的功能必须在同一时间内执行（如系统初始化
），但这些功能只是因为时间因素关联在一起，则称为时间内聚。
（4）通信内聚
如果一个模块的所有成分都操作同一数据集或生成同一数据集，
则称为通信内聚。
（5）顺序内聚
如果一个模块的各个成分和同一个功能密切相关，而且一个成分
的输出作为另一个成分的输入，则称为顺序内聚。
（6）功能内聚
模块的所有成分对于完成单一的功能都是必须的，则称为功能内
聚。
（7）信息内聚
模块完成多个功能，各个功能都在同一数据结构上操作，每一项
功能有一个唯一的入口点。
这个模块将根据不同的要求，确定该模块
执行哪一个功能。
由于这个模块的所有功能都是基于同一个数据结构
（符号表），因此，它是一个信息内聚的模块。
>>耦合类型
一般模块之间可能的连接方式有七种，构成耦合性的七种类型。
它们之间的关系为（由弱到强）
非直接耦合(Nondirect Coupling)
如果两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的，这就是非直接耦合。
这种耦合的模块独立性最强。
数据耦合(Data Coupling)
如果一个模块访问另一个模块时，彼此之间是通过数据参数(不是控制参数、公共数据结构或外部变量)来交换输入、输出信息的，则称这种耦合为数据耦合。
由于限制了只通过参数表传递数据，按数据耦合开发的程序界面简单、安全可靠。
因此，数据耦合是松散的耦合，模块之间的独立性比较强。
在软件程序结构中至少必须有这类耦合。
印记耦合(Stamp Coupling)
如果一组模块通过参数表传递记录信息，就是标记耦合。
事实上，这组模块共享了这个记录，它是某一数据结构的子结构，而不是简单变量。
这要求这些模块都必须清楚该记录的结构，并按结构要求对此记录进行操作。
在设计中应尽量避免这种耦合，它使在数据结构上的操作复杂化了。
如果采取“信息隐蔽”的方法，把在数据结构上的操作全部集中在一个模块中，就可以消除这种耦合。
控制耦合(control Coupling)
如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。
耦合的实质是在单一接口上选择多功能模块中的某项功能。
因此，对所控制模块的任何修改，都会影响控制模块。
另外，控制耦合也意味着控制模块必须知道所控制模块内部的一些逻辑关系，这些都会降低模块的独立性。
外部耦合(External Coupling)
一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。
例如C语言程序中各个模块都访问被说明为extern 类型的外部变量。
外部耦合引起的问题类似于公共耦合，区别在于在外部耦合中不存在依赖于一个数据结构内部各项的物理安排。
公共耦合(Common Coupling)
若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。
公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
这种耦合会引起下列问题：
1)所有公共耦合模块都与某一个公共数据环境内部各项的物理安排有关，若修改某个数据的大小，将会影响到所有的模块。
2)无法控制各个模块对公共数据的存取，严重影响软件模块的可靠性和适应性。
3)公共数据名的使用，明显降低了程序的可读性。
[Page]
公共耦合的复杂程度随耦合模块的个数增加而显著增加。
如图4．14所示，若只是两个模块之间有公共数据环境，则公共耦合有两种情况。
若一个模块只是往公共数据环境里传送数据，而另一个模块只是从公共数据环境中取数据，则这种公共耦合叫做松散公共耦合。
若两个模块都从公共数据环境中取数据，又都向公共数据环境里送数据，则这种公共耦合叫做紧密公共耦合。
只有在模块之间共享的数据很多，且通过参数表传递不方便时，才使用公共耦合。
否则，还是使用模块独立性比较高的数据耦合好些。
内容耦合(Content Coupling)
又称病态耦合。
如果发生下列情形，两个模块之间就发生了内容耦合。
1)一个模块直接访问另一个模块的内部数据；
2)一个模块不通过正常入口转到另一模块内部；
3)两个模块有一部分程序代码重叠(只可能出现在汇编语言中)；
4)一个模块有多个入口。
在内容耦合的情形，所访问模块的任何变更，或者用不同的编译器对它再编译，都会造成程序出错。
好在大多数高级程序设计语言已经设计成不允许出现内容耦合。
它一般出现在汇编语言程序中。
这种耦合是模块独立性最弱的耦合。
以上由Myers给出的七种耦合类型，只是从耦合的机制上所做的分类，按耦合的松紧程度的排列只是相对的关系。
但它给设计人员在设计程序结构时提供了一个决策准则。
实际上，开始时两个模块之间的耦合不只是一种类型，而是多种类型的混合。
这就要求设计人员按照Myers提出的方法进行分析，比较和分析，逐步加以改进，以提高模块的独立性。
