您现在的位置是：首页 >技术杂谈 >头歌实践教学平台软件工程答案网站首页技术杂谈
头歌实践教学平台软件工程答案
目录
第1关：将数据流图转换为模块结构图-认识StarUML中的相关元素
第1关：将数据流图转换为模块结构图-认识StarUML中的相关元素
面向数据流的设计方法-2
第1关：将数据流图转换为模块结构图-认识StarUML中的相关元素
- 什么是模块结构图；
- 数据流图转换为模块结构图的流程。
相关知识
模块结构图
模块结构图（Module Structure Diagram, MSD）是用来表示系统的模块划分与层次分解关系，表示模块的调用关系、模块间数据流与控制流的传递关系以及模块与外界或数据存储的信息接口的规范化图形，是结构化系统设计的一种重要的图表描述工具。
组成元素
- 方框：内有名称，表示模块；
- 直线：表示上层模块对下层模块的调用；
- 尾部带空心圆的箭头：表示按方向传递的数据信息；
- 尾部带实心圆的箭头：表示按方向传递的控制信息。
作用
描述模块间参数交换情况、评价模块间耦合情况、确定模块间的接口。结构图一般不列入设计文档，只用于设计阶段检查模块设计的正确性和模块独立性。
变换设计
变换设计就是从变换型数据流图映射出软件模块结构的过程，也称以变换为中心的设计。 变换设计的基本方法有两步：
- 分解第一层模块结构，就是把整个变换分解成输入控制模块Ci、输出控制模块Co和变换中心控制模块Ct，由主控模块控制；
图1 变换设计
图2 变换设计 - 分别设计输入、输出和处理的下层模块结构，方法是：从变换中心边界向两侧移动，分别把输入通路和输出通路的每个处理映射成输入控制模块Ci和输出控制模块Co的下属模块。变换中心的下层模块，是把每个处理映射成变换中心控制模块Ct的一个直接下属模块。
图3 变换设计
事务设计
事务设计就是从事务型数据流图映射出软件模块结构的过程，也称为以事务为中心的设计。
事务设计的基本方法有两步：
- 建立主控模块、接收输入类型分析模块和事务调度模块；
图4 事务设计 - 分别设计输入类型分析模块和调度模块的下层模块结构。方法是：将输出的每条通路作为调度模块的一个判断分支，而输入类型分析模块的下层模块与变换设计类似。
图5 事务设计
图6 事务设计
StarUML中的相关元素
由于 StarUML 中没有专门绘制模块结构图的工具，所以我们使用 Data Flow Diagram 中的元素来代替模块结构图所需元素。 其中，方框代表模块，箭头代表上层模块对下层模块的调用，也代表传递的数据信息。示例如图7所示。
图7 模块结构图示例
另外，StarUML中的线条默认是折线的形式，若想要将其改为直线或者曲线，需要选中该线条后，在界面右侧的Editors中做出修改，具体如图8所示，红框中的按钮分别代表直线和曲线。
图8 Editors
闯关要求
题目
请认真学习以上描述，并模仿图7，在StarUML中绘制出模块结构图。将答案保存至“/home/headless/Desktop/workspace/myshixun/模块结构图/submit/step_0/”目录下，文件命名为“step0.mdj”。
第2关：将数据流图转换为模块结构图-画出主模块
闯关要求
案例介绍
网上商城订单系统具有如下功能流程： （1）顾客提交订单至订单管理系统审核，在系统审核完成后会向用户反馈订单状态。在订单入库后即为“提交成功、尚未审核”状态，此时更新 订单文件；订单管理员在后台浏览到顾客提交的订单（订单文件），在审核订单并确认订单信息有效后，将订单的状态更改为“订单已审核，尚未付款”，若未通过审核，则将“订单无效”信息发给顾客。 （2）若系统读取 货物库存文件，得知商品无货信息，则向管理员通知商品无货。 该系统的数据流图如下：
图7 订单系统数据流图
题目
本题中我们将该订单子系统看作为一个独立系统，请完成下述题目： 请分析该数据流图和案例描述，找出模块结构图的主模块，在 StarUML 中画出该主模块。请将文件保存至“/home/headless/Desktop/workspace/myshixun/模块结构图/submit/step_1/”目录下，文件命名为“step1.mdj”。
第3关：将数据流图转换为模块结构图-画出输入部分
闯关要求
题目
本题中我们将该订单子系统看作为一个独立系统，请完成下述题目： 请分析该数据流图和案例描述，找出模块结构图的输入部分，在上一关的基础上，画出该输入部分。请将文件保存至“/home/headless/Desktop/workspace/myshixun/模块结构图/submit/step_2/”目录下，文件命名为“step2.mdj”。 File下的“Save As”是“另存为”按钮，可以直接将打开的文件另存到指定目录下。
第4关：将数据流图转换为模块结构图-画出变换部分
闯关要求
题目
本题中我们将该订单子系统看作为一个独立系统，请完成下述题目： 请分析该数据流图和案例描述，找出模块结构图的变换部分，在上一关的基础上，画出该变换部分。请将文件保存至“/home/headless/Desktop/workspace/myshixun/模块结构图/submit/step_3/”目录下，文件命名为“step3.mdj”。 File下的“Save As”是“另存为”按钮，可以直接将打开的文件另存到指定目录下。
第5关：将数据流图转换为模块结构图-画出输出模块
闯关要求
题目
本题中我们将该订单子系统看作为一个独立系统，请完成下述题目： 请分析该数据流图和案例描述，找出模块结构图的输出部分，在上一关的基础上，画出该输出部分。
第6关：事务型结构图
闯关要求
案例介绍
网上商城首页（购物界面）的数据流图如下：
图7 购物界面数据流图
题目
请分析该数据流图，思考下如何将其转换为模块结构图。完成选择题，补全图2中的空缺部分。
图8 事务流结构图
软件详细设计-1
第1关：判定树-网上商城系统库存模块
闯关要求
案例介绍
在网上商城系统中，管理员可以查看具体库存情况。详细描述如下： 若库存量小于等于0，则按缺货处理；否则，若库存量小于等于库存下限，则按下限报警处理；若库存量大于库存下限，而又小于等于储备定额，则按订货处理；若库存量大于库存下限，小于库存上线，而又大于储备定额，则按正常处理；若库存量大于等于库存上线，而又大于储备定额，则按上限报警处理。
题目
请根据网上商城系统库存量监控功能的处理逻辑，完成判定树的填空。
图1 判定树
第2关：判定表-网上商城系统库存模块
闯关要求
案例介绍
商城管理员根据用户欠款时间长短和现有库存情况处理用户订货的方案。对于欠款时间小于等于30天的客户，若其需求量小于库存量，则立即发货；若库存量不足，则按库存发货，进货后再补发。对于欠款时间大于30天且小于等于100天的客户，若其需求量小于库存量，则通知其先付款再发货；若库存量不足，则不发货。对于欠款时间大于100天的客户，通知其先付欠款再议。
题目
请根据上述描述，完成选择题。
第3关：PAD图-网上商城系统购买商品模块
闯关要求
案例介绍
用户在完成登陆后，可以进入到购物界面。在购物界面中，用户可以挑选商品，并且将商品加入到购物车中。之后用户可以选择是否停止购物，选择是会返回购物界面；选择否会进入确认订单页面。至此新建订单操作完成。 该模块的程序流程图如下：
图2 程序流程图
题目
请根据上述描述以及程序流程图，完成题目。
第4关：N-S图-网上商城系统登录购物模块(1)
闯关要求
案例介绍
用户进入用户登陆界面后，系统会提示用户曾经是否注册过账号。若未注册过账号，则需进行新用户注册，之后再进行登陆操作；若注册过账号，则直接填写完用户密码即可。之后点击登录按钮，通过密码审核即登录成功，否则重新执行用户登录操作。登陆成功后，即进入购物界面，在购物界面中，用户可以选择关键字检索、分类商品、最新商品、推荐商品功能。 该模块的程序流程图如下：
图5 程序流程图
题目
请根据上述描述以及程序流程图，完成题目。
第5关：N-S图-网上商城系统登录购物模块(2)
闯关要求
案例介绍
用户进入用户登陆界面后，系统会提示用户曾经是否注册过账号。若未注册过账号，则需进行新用户注册，之后再进行登陆操作；若注册过账号，则直接填写完用户密码即可。之后点击登录按钮，通过密码审核即登录成功，否则重新执行用户登录操作。登陆成功后，即进入购物界面，在购物界面中，用户可以选择关键字检索、分类商品、最新商品、推荐商品功能。 该模块的程序流程图如下：
图5 程序流程图
图6 N-S图
题目
请根据上述描述以及程序流程图，完成题目。
软件详细设计-2
第1关：绘制程序流程图-认识StarUML中的相关元素
闯关要求
案例介绍
开始之后，用户进入用户登录界面，系统会提示曾经用户是否注册过账号。若未注册过账号，则需进行新用户注册，之后再进行登录操作；若注册过账号，则直接填写完用户密码即可。之后点击登录按钮，通过密码审核即登录成功，若未通过审核则重新执行用户登录操作。
上述案例所对应的程序流程图如图5所示。
图5 程序流程图示
题目
请模仿图5的程序流程图，使用StarUML重新绘制一遍，
第2关：绘制程序流程图-网上商城系统新建订单模块
闯关要求
案例介绍
开始之后，进入到购物界面。在购物界面中，用户可以挑选商品，并且将商品加入购物车中。之后用户可以选择是否继续购物，选择Y会返回购物界面；选择N会进入确认订单页面，然后结束。至此新建订单操作完成。
题目
请根据描述，完成程序流程图。
第3关：绘制程序流程图-网上商城系统订单审核模块
闯关要求
案例介绍
开始之后，进入订单审核界面。若用户通过订单审核（即分支为Y），则会进入到付款界面，完成付款后即完成订单，然后结束；若未通过订单审核（即分支为N），则直接结束。
题目
请根据描述，完成程序流程图。
第4关：McCabe方法
闯关要求
案例介绍
用户在完成登陆后，可以进入到购物界面。在购物界面中，用户可以挑选商品，并且将商品加入到购物车中。之后用户可以选择是否停止购物，选择是会返回购物界面；选择否会进入确认订单页面。至此新建订单操作完成。 该模块的程序流程图如下：
图1 程序流程图
题目
请根据上述描述以及程序流程图，完成题目。
第5关：Halstead方法
闯关要求
案例介绍
有如下代码片段
if (month < 3) {month += 12;–year;}return dayray((int)(day + (month + 1) * 26/10 + year +year/4 + 6 * (year/100) + year/400)% 7);
题目
请根据以上代码片段，完成题目。
软件设计规约及评审
第1关：软件设计规约
任务描述
本关考察软件设计规约。为了完成本关任务，你需要掌握：
- 了解软件设计规约的定义及组成；
- 能够制作软件设计说明书。
相关知识
什么是软件设计规约
软件设计规约对软件的组织或其组成部分的内部结构的描述，满足系统需求规约所指定的全部功能及性能要求。
软件设计规约组成
软件设计规约通常有概要设计规约和详细设计规约，分别为相应设计过程的输出文档。
概要设计规约
概要设计规约指明软件的组织结构，其主要内容包括:
- 系统环境：
- 硬件、软件接口与人机界面
- 外部定义的数据库
- 与设计有关的限定条件
- 设计描述：
- 软件模块的结构
- 模块之间的接口
- 数据流和主要数据结构
- 对每个模块的描述：
- 处理过程外部行为
- 界面定义
- 数据结构
- 必要的注释
- 文件结构和全局数据
- 文件的逻辑结构、记录描述以及访问方式
- 交叉引用信息
详细设计规约
详细设计规约是对软件各组成部分内部属性的描述，它是概要设计的细化。即在概要设计规约的基础上，增加以下内容:
- 各处理过程的算法
- 算法所涉及的全部数据结构的描述，特别地，对主要数据结构往往包括与算法实现有关的描述
设计规约格式
1. 引言1.1 编写目的说明编写本软件设计说明书的目的。1.2 背景说明（1）给出待开发的软件产品的名称；（2）说明本项目的提出者、开发者及用户；（3）说明该软件产品将做什么，如有必要，说明不做什么；1.3 术语定义列出本文档中所用的专门术语的定义和外文首字母组词的原词组。1.4 参考文献列出本文档中所引用的全部资料，包括标题、文档编号、版本号、出版日期及出版单位等，必要时注明资料来源。2. 总体设计2.1 需求规定说明对本软件的主要输入、输出、处理等功能及性能要求。2.2 运行环境简要说明对本软件运行的软件、硬件环境和支持环境的要求。2.3 处理流程说明本软件的处理流程，尽量使用图、文、表的形式。2.2 软件结构在 DFD 图的基础上，用模块结构图来说明各层模块的划分及其相互关系，划分原则上应细到程序级（即程序单元），每个单元必须执行单独一个功能（即单元不能再分了）。3. 运行设计3.1 运行模块的组合说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块的组合，说明每种运行所经历的内部模块和支持软件。3.2 运行控制说明各运行控制方式、方法和具体的操作步骤。4. 系统出错处理4.1 出错信息简要说明每种可能的出错或故障情况出现时，系统输出信息的格式和含义。4.2 出错处理方法及补救措施说明故障出现后可采取的措施，包括：（1）后备技术。当原始系统数据万一丢失时启用的副本的建立和启动的技术，如周期性的信息转储；（2）性能降级。使用另一个效率稍低的系统或方法（如手工操作、数据的人工记录等），以求得到所需结果的某些部分；（3）恢复和再启动。用建立恢复点等技术，使软件再开始运行。5. 模块设计说明以填写模块说明表的形式，对每个模块给出下述内容：（1）模块的一般说明，包括名称、编号、设计者、所在文件、所在库、调用本模块的模块名称和本模块调用的其他模块名；（2）功能概述；（3）处理描述；（4）引用格式；（5）返回值；（6）内部接口，说明本软件内部各模块间的接口关系，包括：（a）名称；（b）意义；（c）数据类型；（d）有效范围；（e）I/O 标志；（7）外部接口，说明本软件同其他软件及硬件间的接口关系，包括：（a）名称；（b）意义；（c）数据类型；（d）有效范围；（e）I/O 标志；（f）格式，指输入或输出数据的语法规则和有关规定；（g）媒体；（8）用户接口，说明将向用户提供的命令和命令的语法结构，以及软件的回答信息，包括：（a）名称；（b）意义；（c）数据类型；（d）有效范围；（e）I/O 标志；（f）格式，指输入或输出数据的语法规则和有关规定；（g）媒体；
闯关要求
题目
请学习完相关知识点后，完成题目
第2关：软件设计评审
任务描述
本关考察软件设计评审相关知识点。为了完成本关任务，你需要掌握：
- 理解软件设计评审的概念，评审目标、评审原则；
- 能够用软件设计评审方法进行评审。
相关知识
软件设计评审
设计评审（Design Review），就是对设计文档的评审。对于软件设计来说，评审与其技术设计方法本身是一样重要，评审对于研制项目的成功而言是绝对必要的。对设计进行评审是为了尽早发现软件的欠缺，尽可能把这些缺欠在进入下一阶段工作之前，予以纠正，从而避免后期付出更多的代价。
设计评审方法
目前存在着两种不同的设计评审方法:
- 非正式评审
- 正式技术评审
软件设计评审指南
- 概要设计评审和详细设计评审应该分开进行，不允许合并为一次复审；
- 概要设计评审评价从需求到设计数据和体系结构的变换
- 详细设计评审，通常叫详细设计走查,注重算法过程的正确性；
- 建立一个议事日程并遵循它；
- 评审设计文档，不评审设计者；
- 评审中提出的问题应详细记录，但不要谋求当场解决；
- 限制参与人数和坚持充分准备；
- 除软件开发人员外，概要设计评审必须有用户代表参加，必要时还可邀请有关领域的专家到会；
- 详细设计评审一般不邀请用户和其他领域的代表；
- 为设计文档开发一个检查表，以帮助评审人员集中在重要问题上；
- 为了提高评审的效率，所有评审的参加者应接受一定的正规的培训；
- 评审结束前，应作出本次评审能否通过的结论。
闯关要求
题目
请在学习完知识点后，完成题目。
面向对象分析的基本概念
第1关：用例图的基本概念
任务描述
了解用例图（Use case diagram）的相关知识点，并练习相关选择题目，为之后的实操关卡打下坚实的基础。
相关知识
用例图的基本概念
含义：由参与者（Actor）、用例（UseCase）以及他们之间的关系构成的用于描述系统功能的动态视图成为用例图。其中用例和参与者之间的对应关系又叫做通讯关联，他表示参与者使用了系统中的哪些用例。用例图是从软件需求分析到最终实现的第一步，他显示了系统的用户和用户希望提供的功能，有利于用户和软件开发人员之间的沟通
用例图的参与者和用例
参与者：参与者是指存在于系统外部并直接与系统交互的人、系统、子系统或类的外部实体的抽象。如同所示
用例：位于系统内部，用例是系统提供给参与者的功能。如图所示
用例之间的重要关系
泛化 泛化关系代表一般与特殊的关系, 与继承类似. 在泛化关系中, 子用例继承了父用例的行为和含义, 子用例也可以增加新的行为和含义或覆盖父用例中的行为和含义. 包含 包含关系是指一个用例(基用例)的行为包含了另一个用例(被包含用例)的行为. 包含关系是依赖关系的版型, 但其含义更多. 扩展 扩展关系的基本含义与泛化关系类似，但对扩展用例有更多限制，即基本用例必须声明若干“扩展点”，扩展用例只能在扩展点上增加行为和含义。 基用例可以使用扩展用例的行为，但不是必须的； 扩展用例可以被基用例激活，进而将扩展用例的行为插入基用例中。
案例需求用例表
| 参与者 | 用例 |
|---|---|
| 客户 | 维护个人基本信息、获取酒店信息、 撤销订单、查看订单信息、注册会员、提交订单、评价酒店服务 |
| 酒店工作人员 | 更新退房信息、执行客户订单、更新入住信息、恢复客户订单、制定酒店促销策略、维护酒店基本信息 |
| 软件营销人员 | 制定软件促销策略、分析未执行订单情况、撤销异常订单、信用充值 |
| 软件管理人员 | 调整用户信息 |
闯关要求
根据以上知识点讲解，完成以下题目，开始你的闯关之旅吧！
第2关：类图的基本概念
任务描述
了解类图（Class diagram）的相关知识点，并练习相关选择题目，为之后的实操关卡打下坚实的基础。
相关知识
类图简单介绍
1.类图分为三部分，依次是类名、属性、方法 2.以<<开头和以>>结尾的为注释信息 3.修饰符+代表public，-代表private，#代表protected，什么都没有代表包可见。 4.带下划线的属性或方法代表是静态的。
类图关系
1.依赖（Dependence） 依赖关系的定义为：对于两个相对独立的对象，当一个对象负责构造另一个对象的实例，或者依赖另一个对象的服务时，这两个对象之间主要体现为依赖关系。定义比较晦涩难懂，但在java中的表现还是比较直观的：类A当中使用了类B，其中类B是作为类A的方法参数、方法中的局部变量、或者静态方法调用。类上面的图例中：People类依赖于Book类和Food类，Book类和Food类是作为类中方法的参数形式出现在People类中的。
2.关联（Association） 体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我和我的朋友；这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的、关联可以是单向、双向的。
3.聚合（Aggregation） 聚合关系是关联关系的一种，耦合度强于关联，他们的代码表现是相同的，仅仅是在语义上有所区别：关联关系的对象间是相互独立的，而聚合关系的对象之间存在着包容关系，他们之间是“整体-个体”的相互关系。
4.组合（Composition） 相比于聚合，组合是一种耦合度更强的关联关系。存在组合关系的类表示“整体-部分”的关联关系，“整体”负责“部分”的生命周期，他们之间是共生共死的；并且“部分”单独存在时没有任何意义。在下图的例子中，People与Soul、Body之间是组合关系，当人的生命周期开始时，必须同时有灵魂和肉体；当人的生命周期结束时，灵魂肉体随之消亡；无论是灵魂还是肉体，都不能单独存在，他们必须作为人的组成部分存在。
5.继承（Generalization） 继承表示类与类（或者接口与接口）之间的父子关系。在java中，用关键字extends表示继承关系。UML图例中，继承关系用实线+空心箭头表示，箭头指向父类。
6.实现（Implementation） 表示一个类实现一个或多个接口的方法。接口定义好操作的集合，由实现类去完成接口的具体操作。在java中使用implements表示。UML图例中，实现关系用虚线+空心箭头表示，箭头指向接口。
本案例对象分析表
| 对象 | 属性 | 操作 |
|---|---|---|
| 客户 | id(String) | saveUserInfo，getHotelInfo,cancelOrder,getOrderInfo,submitOrder,assessHotelService |
| 酒店客房 | id(String)、hotelId(String)、status(int) | addRoom,deleteRoom,updateRoom,getRoom |
| 软件管理员 | id(String) | updateUserInfo(userId) |
| 酒店工作人员 | id(String) | updateRoomInfo,carryUserOrder,maintainHotelInfo |
| 软件营销人员 | id(String) | analysisOrderInfo,cancelOrder |
| 订单 | id(String) roomId(String) status(int) addr(String) amount(int) orderPrice(decimal) | addOrder, deleteOrder, updateOrder, getOrder |
| 软件营销人员 | id(String) | analysisOrderInfo,cancelOrder |
闯关要求
根据以上知识点讲解，完成以下题目，开始你的闯关之旅吧！
第3关：顺序图的基本概念
任务描述
了解顺序图（Sequence diagram）的相关知识点，并练习相关选择题目，为之后的实操关卡打下坚实的基础。
相关知识
顺序图的构成元素
1.活动者：指用况中的活动者。 2.对象：指在用况中的内部对象。 3.生命线：在顺序图中的一个对象下面的竖线，用以显示这个对象的生命期。时间从上到下流过。生命线实际上显示了消息的顺序，在生命线之上的消息比在它之下的消息先发生。在生命线中的棒形方框表示的是活动生命线，用以强调一个对象只有在一个场景的部分中处于活动状态。 4.消息：指场景内由事件流定义的内部事件成为在对象和活动者或其他对象之间的消息。 同步消息——返回消息。同步消息假定有一个返回消息。同步消息用有实心的箭头表示；返回消息用虚线、箭头也不是实心来表示。 反身消息——消息的发送方和接收方是同一个对象。 异步消息——没有返回值的消息。用非实心箭头表示。 定时消息——对消息附加时间约束条件，包括：发送时间、接收时间、已用时间等。
本案例介绍
系统显示酒店当前的基本信息，酒店工作人员选择需要修改的项目，酒店工作人员输入当前待修改项目的值，系统显示修改过的酒店基本信息，酒店工作人员重复2～4步，直到所有待修改的项目完成，酒店工作人员提交修改过的酒店基本信息，系统记录新的酒店基本信息。以下是酒店工作人员在维护酒店基本信息时的过程图
闯关要求
根据以上知识点讲解，完成以下题目，开始你的闯关之旅吧！
第4关：活动图的基本概念
任务描述
了解活动图（Activity diagram）的相关知识点，并练习相关选择题目，为之后的实操关卡打下坚实的基础。
相关知识
活动图的相关介绍
活动图（Activity diagram）是一种描述系统行为的图，它把一项行为表示成一个可以由计算机、人或者其他执行者执行的活动，通过给出活动中的各个动作以及动作之间的转移关系来描述系统的行为。 组成元素主要包括：动作、活动、动作流、分支与合并、分叉与汇合、泳道、对象流。 1.动作：代表一个原子操作，仅有描述不做命名。 2.活动节点：是一系列动作，活动节点在图例上的表达方式与动作一样，他们之间的区分要借助编辑工具或者附件说明。 3.开始和终止：是两个标记符号，活动图必须有且仅有一个开始标记，一般至少有一个终止标记，有时候有多个终止标记，另外，存在一些特殊的无穷过程不存在终止标记。 4.控制流：两边都是活动（动作），他负责当一个动作或活动节点执行完毕后，将执行主体从当前已完毕的节点转移到过程的下一个动作或活动节点。 5.判断节点：进行逻辑判断并创造分支的一种方法，具有一个进入控制流和至少两个导出控制流。对于导出控制流，应该在箭头上附件控制条件。判断节点用一个菱形表示。 6.合并节点：将多个控制流合并，并统一导出到同一个离开控制流。注意：仅有逻辑意义而没有时间和数据上的意义，不需要互相等待或者数据同步啥的。同样是菱形表示，至少两个指向他的箭头，有且仅有一个由他发出的箭头指向其他动作或活动节点。注意：他的几个进入控制流之间是or的关系，只需要满足一个就好，不用全部满足! 7.泳道：将活动中的具体活动按照负责进行该活动的对象进行分区，一条泳道中的所有活动都由一个对象执行。 8.并发：指的是同一时间间隔中，系统内有两个或多个事件一起发生。在并发情况下，不可以对多个事件的发生顺序做预测。 9.分叉节点：是从线性流程进入并发过程的过渡节点，他拥有一个进入控制流和多个离开控制流，分叉节点的所有离开流程是并发关系，分叉节点在活动图中表示为一根粗横线。 10.结合节点：功能上与合并节点相似，但有关键区别。合并节点没有等待和同步，但是结合节点的各个进入控制流有并发关系，他们再系统中同时运行。在各个支流收束时，为了保证数据的统一性，先到达结合节点的控制流必须等待直到所有的流程全部到达这个结合节点后才继续进行，转移到离开控制流所指向的动作。也是用一根粗横线表示。 11.对象流：很少使用！当活动图中描述的过程具有一些对关键对象的属性要求时，通过添加对象流的放发可以在活动图中呈现操作的对象。如果想表现出对象流，必须先绘制泳道，且对象应该作为泳道的负责对象出现，在某些关键动作前后，设计人员可以通过加入对象的状态描述来呈现对象状态，描述文字应该简明扼要。 12.扩展区域：用来表示循环。具体做法：在活动图中围绕一个区域画一个虚线框来表示扩展区域。区域要有输入输出的定义，输入输出的集合表示为数组。如果扩展区域运行时可以并发执行，也有可能多次迭代并发执行，直到迭代工作执行完毕，集合中的每个元素对应的处理成一个输出元素，全部输出元素的集合对应输入时的顺序同样表示为一个数组，然后向下执行。
详细说明
状态依次为进入酒店管理系统主页、酒店业务主页、订房服务、满房（有空房）、处理订单。 开始之后进入网络，画出进入酒店管理系统主页的状态，下一步画出酒店业务状态，之后选择服务，画出订房服务状态，之后出现分支，状态分别为满房和有空房，在分支汇合时，汇合条件为无法预订和提交订房订单，下一步画出处理订单状态，最后结束。
闯关要求
根据以上知识点讲解，完成以下题目，开始你的闯关之旅吧！
站长推荐
- SpringSecurity实现前后端分离认证授权
SpringSecurity实现前后端分离认证授权 - stm32使用HAL库配置串口中断收发数据（保姆级教程）
stm32使用HAL库配置串口中断收发数据（保姆级教程） - U8W/U8W-Mini使用与常见问题解决
U8W/U8W-Mini使用与常见问题解决 - 【社区图书馆】伴我前行的一本书《The C Programming Language》
【社区图书馆】伴我前行的一本书《The C Programming Language》 - 【云原生进阶之容器】第六章容器网络6.6.1--Cilium网络方案概述
【云原生进阶之容器】第六章容器网络6.6.1--Cilium网络方案概述