Merge pull request #2213 from cyh1069247088/master

#7 #6 #1185 Create lab7.md and Fix lab6.md

students/1714080901141/lab6.md

@@ -27,10 +27,13 @@
 - 顺序图的构成与时间顺序：由参与者和消息的交互构成。时间先后对应从上到下，时间的顺序会自动标号。
 - 参与者的存活条/激活条的画法：点击Lifeline。
 - 消息画法：点击Message，并编辑消息名称。
+- 交互的概念：输入+处理+输出。
 
 1.2.2 实验要求及注意事项
 - 顺序图和用例图的数量要相等。
 - 总集里面有分集的时间表示，可以跳时间分开看。
+- 检查不是在模型上进行的，修改的地方可以在下一个实验提交的时候提交，注意标明"#N"。
+- 要把方框缩小一些，截图就不会太小，也可规避显示有点模糊的现象。
 
 1.2.3 视频演示收获
 - 先找到第一个参与者（一般是系统外的用户），然后根据类图（lab3）找到N个参与者，最后结合活动图传递消息。注意期间可能需要改进类图和活动图。
@@ -43,8 +46,8 @@
 #### 2. 确定核心要素
 
 2.1 "1 + N"参与者的确定： 主要根据类图确定
-- 添加航班： 管理员 + （航班、添加航班控制器、航班添加成功的页面和航班添加的操作页面）
-- 取消航班： 管理员 + （航班、订单、航班取消控制器、所选航班正在取消的页面、可取消的航班的信息页面和航班取消成功的页面）
+- 添加航班： 管理员 + （航班、添加航班控制器和航班添加的操作页面）
+- 取消航班： 管理员 + （航班、订单、航班取消控制器和可取消的航班的信息页面）
 
 2.2 消息确定： 主要根据活动图确定
 

students/1714080901141/lab7.md

@@ -0,0 +1,82 @@
+# 实验7名称：状态建模
+
+## 一、实验目标
+
+#### 1. 掌握对象状态建模（状态图，Statechart）。
+#### 2. 整理之前的实验，避免前后矛盾。
+
+## 二、实验内容
+
+#### 1. 记录学习过程；
+#### 2. 确定核心要素；
+#### 3. 画状态图。
+
+## 三、实验步骤
+
+#### 1. 观看录制视频、学习课堂文档：
+
+1.1 学习来源：
+- [b站资料](https://space.bilibili.com/44472532/)的实验7部分
+- [实验7内容及讲义](https://github.com/hzuapps/uml-modeling-2020/issues/7)
+
+1.2 学习笔记：
+
+1.2.1 概念讲解：
+
+(1). 对象的状态：
+- 找关键（最重要的）对象进行建模（不能拘泥于你选择的功能）。
+- 对象的状态取决于对象所包含的所有数据。
+- 状态是指条件在某一特定时间的存在。可以是主动的状态，也可以是被动的状态。
+
+(2). 状态图及其画法：
+- 状态图还是属于逻辑视图。
+- 状态（节点）、事务（转变条件）和箭头直线（转变方向）组成。
+- 第一，找到对象；第二，找到该对象的所有状态；第三，找到状态转换的事务。
+- 初始状态，结束状态（都是虚拟的）。
+
+(3). 事务：
+- 原始状态到目标状态转变的条件。
+
+1.2.2 实验要求
+
+- 实验目标：掌握对象状态建模（状态图，Statechart）。
+
+1.2.3 状态图画图演示：根据用例图、用例规约、活动图、类图、顺序图来画图：
+
+(1). 寻找1个重要的对象：
+- 不拘泥于你所选择的功能，选择所建模软件系统中最终要的对象。
+
+(2). 寻找这个对象的所有重要状态：
+- 状态命名：形容词。
+- 注意合并相同的状态：数据的值明显相同的。
+- 注意有些状态在系统中是没有存在的。
+
+(3). 写出状态之间的转变触发方式，注意方向。
+
+#### 2. 确定核心要素
+
+2.1 确定几个重要的对象：
+- 航班。（理由：两个用例规约都出现了航班，本次issue也是航班状态的转换，即取消和添加。）
+- 订单。（理由：取消航班之后会出现订单的相关业务，对应订单状态的变化。）
+
+2.2 确定对象的所有重要状态：
+- 售票中的、在途中的、到达的和取消的航班。
+- 待付款的、已付款的、已出票的、待取消的和已退款的订单。
+
+2.3 确定对象的状态之间的关键转换条件：
+- 售票中的航班转换为取消的航班是通过管理员取消航班。
+- 已出售的订票为待取消的是通过管理员取消航班；待取消的订单转换为已退票的是通过触发退款业务。
+
+## 四、实验结果
+
+#### 1. 航班状态图
+
+![StatechartDiagram1](./lab7_StatechartDiagram1.png)
+
+#### 2. 订单状态图
+
+![StatechartDiagram2](./lab7_StatechartDiagram2.png)
+
+## 五、实验总结
+- 对象状态建模步骤：寻找1个重要的对象，寻找这个对象的所有重要状态，写出状态之间的转变触发方式。
+- 对于实验检查有新的理解，可以先修改后面的，然后再此基础上往前修改，但是每个实验要记录好要点，修改的时候不至于破坏原本的正确的地方。

students/1714080901141/lab8.md

@@ -0,0 +1,132 @@
+# 实验8名称：综合实验
+
+## 一、实验目标
+- 掌握基于UML 2.0的建模概念与方法，掌握各种UML图的概念与画法，其中包括用例图、活动图、类图、顺序图、组件图和状态图等。
+
+## 二、实验设备与环境
+- 操作系统：Ubuntu16.04LTS；建模工具：StarUML。
+
+## 三、实验要求
+
+#### 1. 实验及实验报告以增量方式完成，每次作业都在上一次作业的基础上完成；
+
+#### 2. 请将实验报告中“占位符”信息替换为自己的实验相关信息；
+
+#### 3. 请认真撰写实验体会，按『教学助理』微信小程序要求发送作业。
+
+## 四、实验内容、程序清单及运行结果
+
+- 功能：添加航班，取消航班。
+- 添加航班：由于在节假日人流量较平日更大，管理员会添加更多的航班，以满足客户需求并提高公司盈利，客户订票就能查到比平日更多的票了。
+- 取消航班：由于飞机故障、重大卫生事故或人流量回降，管理员需要通过取消航班限制人流，以保障乘客安全与降低公司亏损，客户订票受限。
+
+#### 1. 实验一：需求建模 - 用例模型
+![UseCaseDiagram](./lab2_UseCaseDiagram.jpg)
+
+- 表1：添加航班用例规约  
+
+用例编号  | UC01 | 备注  
+-|:-|-  
+用例名称  |  添加航班 |   
+前置条件  |  管理员已在航班添加的操作页面   | *可选*   
+后置条件  |     | *可选*   
+基本流程  | 1. 管理员输入添加的航班；| *用例执行成功的步骤*
+~| 2. 管理员点击确认按钮； |
+~| 3. 系统检查航班时间可兼容;  |
+~| 4. 系统检查对应类型航班有闲置;  |
+~| 5. 系统保存添加信息；  |
+~| 6. 系统显示航班添加成功的页面。 |
+扩展流程  | 3.1 系统检查航班时间不可兼容，提示“航班时间冲突，添加失败”，返回航班添加的操作页面；  |*用例执行失败的步骤*
+~| 4.1 系统检查对应类型航班无闲置，提示“航班忙碌，添加失败”，返回航班添加的操作页面。 |
+
+- 表2：取消航班用例规约  
+
+用例编号  | UC02 | 备注  
+-|:-|-  
+用例名称  |  取消航班 |   
+前置条件  |  管理员已在可取消的航班的信息页面   | *可选*   
+后置条件  |     | *可选*   
+基本流程  | 1. 管理员编辑航班；|*用例执行成功的步骤* 
+~| 2. 管理员点击确认按钮；  |
+~| 3. 系统检测到所选航班可取消；  |
+~| 4. 系统显示所选航班正在取消的页面；  | 
+~| 5. 系统保存取消信息；  |
+~| 6. 系统修改客户订单；  |
+~| 7. 系统触发对应客户的退款业务；  |
+~| 8. 系统发送致歉信息给对应客户；  |
+~| 9. 系统显示航班取消成功的页面。  |
+扩展流程  | 3.1 系统重新检测到所选航班不可取消，显示航班取消失败的页面。 |*用例执行失败的步骤* 
+
+#### 2. 实验二：过程建模 – 活动模型
+- 使用活动图描述系统的业务过程。
+- 方法：将用例规约中的基本流程与扩展流程抽象为过程步骤（Action），画出对应的活动图。
+- 活动图1：
+
+![ActivityDiagram1](./lab3_ActivityDiagram1.png)
+
+- 活动图2：
+
+![ActivityDiagram2](./lab3_ActivityDiagram2.png)
+
+#### 3. 实验三：逻辑建模 – 类模型
+- 基于MVC设计模式找出实现用例的类。
+- 方法：分别找出实现用例的模型（Model）、视图（View）和控制器（Controller）类，确定类之间的关系及其关键属性，画出类图。
+- 参考：讲义P26页。
+- 类图1： 
+
+![ClassDiagram1](./lab4_5_ClassDiagram1.png)
+
+- 类图2： 
+
+![ClassDiagram2](./lab4_5_ClassDiagram2.png)
+
+#### 4. 实验四：交互建模 – 顺序模型
+- 创建各个类（MVC及Actor）的对象，并描述对象之间的交互。
+- 方法：分别创建参与者（Actor）、界面类（View）、控制器类（Controller）和模型类（Model）的对象，描述各个对象之间的消息及其顺序，画出顺序图。
+- 参考：讲义P33页8.7.2。
+- 顺序图1： 
+
+![SequenceDiagram1](./lab6_SequenceDiagram1.png)
+
+- 顺序图2： 
+
+![SequenceDiagram2](./lab6_SequenceDiagram2.png)
+
+#### 5. 实验五：状态建模 – 状态模型
+- 对系统中最重要的对象进行状态建模。
+- 方法：选择一种对象，定义该对象的状态，描述状态之间的切换及条件，画出状态图。
+- 参考：讲义P9和P10页。
+- 状态图：
+
+![StatechartDiagram](./lab7_StatechartDiagram.png)
+
+## 五、实验体会
+
+#### 1. 实验一：需求建模 - 用例模型
+1.1 养成良好的表达习惯，有助于锻炼思维，可以通过写作提高；
+1.2 要经常使用git pull 和 git push；
+1.3 依赖关系是弱的关联关系，用带箭头的虚线表示，这种使用关系是具有偶然性的、临时性的、非常弱的；
+1.4 用例规约中，基本流程和拓展流程的每一个step，是活动（动态的）而非状态（静态的），这一点要明确；
+1.5 用例建模是整个UML建模的核心及基础：  
+- 核心：需求分析是软件系统开发的核心：解决需求，可行性判定；  
+- 基础：后续模型要以用例模型为基础：用例图（参与者、用例），用例规约（基本流程、拓展流程）。  
+
+#### 2. 实验二：过程建模 – 活动模型
+1.1 过程建模的方法如下：
+- 依据用例规约的基本流程和拓展流程，实现过程建模
+1.2 活动图画法如下（画法顺序不唯一）：
+- 创建Activity Diagra -> 添加初始结点、添加结束结点 -> 添加活动、分支处添加决策 -> 添加流程线、调整整体
+1.3 决策前应有类似检查的动作，检查后要有条件表明分支（yes/no、true/false或文字描述，与检查的动作相匹配），条件过后系统要有对应的动作保存信息（lab2.md提及），再之后就要动作有反馈（增加友好性）
+
+#### 3. 实验三：逻辑建模 – 类模型
+1.1 MVC设计模式是一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。
+1.2 本次类图的画法为： 先根据Model（业务数据）、View（页面）和Controller（功能+控制器）找出具体的类，标注好类型（M/V/C），确定类之间的关系，如果有箭头，注意箭头指向。
+
+#### 4. 实验四：交互建模 – 顺序模型
+1.1 实验总是需要迭代修改的，不能期望一次性完成实验，而且要反复检查，才能尽可能避免低级错误。老师若是提到不足的地方，要主动修改，想想有没有类似的错误。
+1.2 先找到第一个参与者（一般是系统外的用户），然后根据类图找到N个参与者，（就有1+N个参与者了），最后结合活动图传递消息。注意期间（很）可能需要改进类图和活动图。
+
+#### 5. 实验五：状态建模 – 状态模型
+1.1 对象状态建模步骤：寻找1个重要的对象，寻找这个对象的所有重要状态，写出状态之间的转变触发方式。
+1.2 对于实验检查有新的理解，可以先修改后面的，然后再此基础上往前修改，但是每个实验要记录好要点，修改的时候不至于破坏原本的正确的地方。
+