下载文档原格式
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、不完善的系统定义往往是导致软件项目失败的主要原因。
2024年上半年《软件工程》全国自考考题一、单项选择题1、在建模过程中，可用以描述加工的工具是______。
A．数据流B．判定树C．数据字典D．数据存储2、在教师科研方案中规定对教授、副教授和讲师分别计算分数，做相应的处理，则根据黑盒测试中的等价类划分技术，下列划分正确的是______。
A．3个有效等价类，3个无效等价类B．3个有效等价类，1个无效等价类C．1个有效等价类，1个无效等价类D．1个有效等价类，3个无效等价类3、软件工程在20世纪60年代末到80年代初获得的主要成果有______。
A．CASE产品B．面向对象语言C．瀑布模型D．软件生存周期过程4、在常见的软件开发模型中，主要用于支持面向对象技术软件开发的是______。
A．喷泉模型B．螺旋模型C．增量模型D．瀑布模型5、软件生存周期是指______。
A．开发软件的全部时间B．使用软件的全部时间C．开发和使用软件的全部时间D．从形成概念开始到最后淘汰让位于新的软件产品的时间6、RUP的分析类包括边界类、实体类和______。
A．子类B．控制类C．父类D．活动类7、下列可用于概念模型和软件模型的动态结构的是______。
A．类图B．对象图C．部署图D．用况图8、集成化能力成熟度模型(CMMI)针对每个过程域设定了能力等级，其中最高级为______。
A．3级B．4级C．5级D．6级9、RUP的迭代、增量式开发过程中，需要估算成本、进度，并能够减少次要的错误风险，至少需要完成______。
A．初始阶段B．精化阶段C．构造阶段D．移交阶段10、结构精细化设计过程中，为了提高模块的独立性，应遵循的原则是______。
A．低内聚高耦合B．低内聚低耦合C．高内聚低耦合D．高内聚高耦合11、《ISO/IEC软件生存周期过程12207-1995》标准按过程主体把软件生存周期过程分为基本过程、组织过程和______。
A．供应过程B．开发过程C．测试过程D．支持过程12、“与所规约的系统执行之间的偏差”是指______。
一、单项选择题（每小题3分，共10题）1、需求分析的任务不包括（B）。
A.问题分析B.系统设计C.需求描述D.需求评审。
2、当模块中包含复杂的条件组合，只有（A）能够清晰地表达出各种动作之间的对应关系。
A.判定表和判定树B.盒图C.流程图D.关系图3、为适应软件运行环境的变化而修改软件的活动称为（B）。
A.纠错性维护B.适应性维护C.改善性维护D.预防性维护4、下列不属于软件工程方法3要素的是（D）。
A）方法B）工具C）过程D）人员5、软件的发展经历了（D）个发展阶段。
A.一B.二C.三D.四6、下列不属于UML中的动态图的是（B）。
A）状态图B）对象图C）协作图D）活动图7、一个模块的（B）是指能直接调用（控制）该模块的模块数。
A.扇出数B.扇入数C.宽度D.深度8、下列耦合中，模块独立性最好的是（A）。
A）非直接耦合B）数据耦合C）外部耦合D）内容耦合9、CMM提供了一个框架，将软件过程改进的进化步骤组织成5个成熟度等级。
除第1级外，每一级都包含了实现这一级目标的若干关键过程域，每一个关键过程域又包含若干（A）。
A 关键实践B 软件过程性能C 软件过程能力D 软件过程10、UML的扩展机制不包括（C）。
A）构造型B）标记值C）注解D）约束二、填空题（每题2分，共5题）1、任何复杂的程序流程图都只应该由5种基本控制结构组合或嵌套而成，这5中基本结构分别是顺序型、选择型、先判定型循环、后判定型循环、多情况型选择。
2、在进行结构化分析时，对数据流图进行分层应注意父图和子图平衡。
3、UML的基本构造块包含：视图、图和模型元素。
4、自行车类与自行车车轮类之间是聚集关系。
5、在进行软件规模估算时，与代码行度量方式相比，功能点度量的估算结果更客观和合理。
三、判断题（每题2分，共10题）1、目前，软件项目的进度安排比较常用的方法包括程序评估与审查技术（PERT）和关键路径法（CPM）。
（对）2、缺乏处理大型软件项目的经验。
UML补考练习汇总1、请根据本学期的课程，结合实际软件开发过程，归纳出使用面向对象技术进行项目开发，需要开展哪些活动，你认为最关键的活动是什么？(A卷考过)用例模型：用例文本和用例图(1分)领域模型分析：领域模型(1分)用例顺序图分析：用例顺序图（1分）类图建模：类图（1分）最关键的活动是领域建模。
（1分）2、“老师说要迭代开发，真是有道理。
我决定在我们的项目组实施迭代开发，第一迭代先做需求，第二个迭代做分析，第三个迭代做设计….”，这句话正确吗？为什么？不对（2分），每次迭代都是一次软件开发完整的过程，不是按步骤的每次迭代完成不同的任务（3分）。
3、假设要构造一个和用户下棋的游戏系统，哪些UML图对设计该游戏有帮助？为什么？(A卷考过)答：用例图、类图、顺序图（交互图）（2分），用例图可以归纳游戏系统需要完成的功能需求，类图分析了系统需要的类，及其承担职责，刻画了系统的静态结构。
使用顺序图可以对具体场景的交互进行动态建模。
理解系统的内部的交互过程。
（3分）。
4、在用例模型中，除了需要绘制用例图，最重要的是为每个用例编写用例文本，用例文本当中常有：主要参与者、涉众及其关注点、前置条件、后置条件、主成功场景、扩展场景、特殊需求等部分。
阿呆比较笨，老是搞不清。
请你告诉他那个部分最重要，解释该部分含义，并说明重要理由。
主成功场景场景里面有对话功能，交互过程5、根据下列代码片断，画图说明已经创建的类的数据成员及类间的关系。
（要求：如有关联需要标明关联的方向、角色名和多重性）c lass Use Case ModelCatalogueEntry - cost: String- name: String - number: StringPart- entry: CatalogueEntry entry▲6、通信图和顺序图都是交互图，阿呆不明白什么时候用通信图，什么时候用顺序图。
请你为他解释顺序图和通信图的优点和缺点。
UML组件图中的组件和接口的定义与应用范围在软件开发中，UML（统一建模语言）是一种常用的图形化建模语言，用于描述软件系统的结构和行为。
其中，UML组件图是一种用于展示软件系统中组件和它们之间关系的图形表示方式。
在UML组件图中，组件和接口是两个重要的概念，它们在软件系统的定义和设计中起着重要的作用。
首先，我们来看一下组件的定义和应用范围。
组件是指软件系统中的一个可独立部署和替换的模块，它具有明确的边界和功能。
组件可以是一个库、一个可执行文件、一个插件或者一个独立的子系统。
组件的设计和实现应该是高内聚、低耦合的，即组件内部的元素之间关联紧密，而与其他组件的关联尽可能松散。
这样可以提高系统的可维护性和可扩展性。
在UML组件图中，组件通常用矩形表示，矩形内部包含组件的名称和一些其他的属性信息。
组件之间的关系可以用连接线表示，连接线上可以标注关系的类型，如依赖、关联、聚合和组合等。
组件图可以帮助开发人员更好地理解和设计软件系统的结构，同时也可以用于与团队成员和其他利益相关者进行沟通和交流。
接下来，我们来看一下接口的定义和应用范围。
接口是指组件或者系统对外部提供的一组服务或者功能。
接口定义了组件或者系统与外部世界之间的通信协议，它定义了可以被调用的操作和可以被访问的属性。
接口可以是一种抽象的描述，也可以是一种具体的实现。
接口的设计应该遵循接口隔离原则，即接口应该精简、高内聚、低耦合，避免冗余和不必要的复杂性。
在UML组件图中，接口通常用带有斜线的小圆圈表示，小圆圈上可以标注接口的名称和一些其他的属性信息。
组件可以实现一个或多个接口，表示组件提供了接口所定义的服务或功能。
组件之间的接口关系可以用连接线表示，连接线上可以标注接口的类型，如实现、依赖、使用和扩展等。
接口图可以帮助开发人员更好地理解和设计软件系统的接口，同时也可以用于与团队成员和其他利益相关者进行沟通和交流。
在实际的软件开发中，UML组件图的应用范围非常广泛。
软件工程简答题集锦1、为什么事务型软件的结构常常具有中间大两头小的形状？答：扇入高则上级模块多，能够增加模块的利用率；扇入低则表示下级模块的复杂性。
事务型软件常常具有中间大两头小的形状，具有良好的软件设计结构，瓮型结构。
说明它在底层模式中使用了较多高扇入共享模块。
2、什么是软件需求，可以从哪些方面描述软件需求？答：软件需求是指一个软件系统必须遵循的条件或具备的能力。
条件与能力：①系统为了解决问题或到达目的所具备的条件或能力，即系统的外部特性；②系统为了满足合同，标准或其他规定文档所具备的条件或能力，即系统的内部特性。
软件需求一般包含三个不同的层次：业务需求，用户需求，功能需求软件需求的特性：①功能性②可用性③可靠性④性能⑤可支持性⑥设计约束3、面向对象设计模型包含哪几个层次？主要内容？答：面向对象设计模型包含：①系统架构层。
描述整个系统的总体架构，使所设计的软件能够满足客户定义的需求，并完成支持客户需求的技术根底设施；②类和对象层。
使系统能从通用的方法创立并不断逼近特别需求，该层同时包含了每个对象的设计表示。
③消息层。
描述对象间的消息模型，它建立了系统的内部和外部接口，包含使得每个对象能够和其协作者通信的细节。
④责任层。
包含针对每个对象的全部属性和操作的数据结构和算法的设计。
4、多模块程序的测试有哪些层次？各层次主要解决什么问题？答：多模块测试有4个层次①单元测试：通过对象模块的静态分析和动态测试，使其代码到达模块说明的要求；②集成测试：把经过单元测试的模块逐步组成具有良好一致性的完整程序；③确认测试：确认组装完毕的程序是否满足软件需求规格说明书的要求；④系统测试：检查把确认测试合格的软件安装到系统之后，能否与系统中其余局部协调运行，并完成SRS的需求。
5、瀑布开发模式有哪些特点？存在的主要问题？如何改良？答：瀑布开发模型是一种基于软件生存周期的线性开发模型主要特点：①阶段间的顺序和依赖性；②推迟完成的观点；③保证质量的观点每个阶段都必须完成规定的文档，每个阶段都要对完成的文档进行复审，以便尽快发觉问题，排除隐患。
UML中包括九种图：用例图、类图、对象图、状态图、时序图、协作图、活动图、组件图、配置图。
１）用例图（Use Case Diagram）它是UML中最简单也是最复杂的一种图。
说它简单是因为它采用了面向对象的思想，又是基于用户视角的，绘制非常容易，简单的图形表示让人一看就懂。
说它复杂是因为用例图往往不容易控制，要么过于复杂，要么过于简单。
用例图表示了角色和用例以及它们之间的关系。
２）类图（Class Diagram）是最常用的一种图，类图可以帮助我们更直观的了解一个系统的体系结构。
通过关系和类表示的类图，可以图形化的方式描述一个系统的设计部分。
３）对象图（）对象图是类图的实例，几乎使用与类图完全相同的标识。
它们的不同点在于对象图显示类的多个对象实例，而不是实例的类。
一个对象图是类图的一个实例。
由于对象存在生命周期，因此对象图只能在系统某一时间段存在。
４）状态图描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。
通常创建一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。
５）时序图又称顺序图，描述了对象之间动态的交互关系，着重体现对象间消息传递的时间顺序。
顺序图由一组对象构成，每个对象分别带有一条竖线，称作对象的生命线，它代表时间轴，时间沿竖线向下延伸。
顺序图描述了这些对象随着时间的推移相互之间交换消息的过程。
消息用从一务垂直的对象生命线指向另一个对象的生命线的水平箭头表示。
图中还可以根据需要增加有关时间的说明和其他注释。
６）协作图协作图用于显示组件及其交互关系的空间组织结构，它并不侧重于交互的顺序。
协作图显示了交互中各个对象之间的组织交互关系以及对象彼此之间的链接。
与序列图不同，协作图显示的是对象之间的关系。
另一方面，协作图没有将时间作为一个单独的维度，因此序列号就决定了消息及并发线程的顺序。
协作图是一个介于符号图和序列图之间的交叉产物，它用带有编号的箭头来描述特定的方案，以显示在整个方案过程中消息的移动情况。
>>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提出的方法进行分析，比较和分析，逐步加以改进，以提高模块的独立性。
