#8 #672 修改并补交前面的实验

students/1714080902325/Lab1.md

@@ -21,4 +21,11 @@
 7. pull request请求合并到主仓库
 
 ## 四、实验结果
-![第一个UML图](./model.jpg)
+![第一个UML图](https://github.com/stop-imagine/uml-modeling-2020/blob/master/students/1714080902325/model.jpg)
+
+## 五、实验体会
+本次实验学习了git、StarUML的使用，初步了解GitHub这个强大的开源平台。不同于其它课程，我觉得在GitHub仓库模式下，更加适合我们专业的学习，主要有以下三点：
+1. 老师能够清晰地看见学生的操作结果，即时提出意见；
+2. 学生收到意见后进行相应的修改，在1对n的情况下，相当于传统的word文档，更加高效；
+3. 在开源时代，多看看别人的编码方式，能够有效提升自己的编程思想。
+

students/1714080902325/Lab2.md

@@ -28,49 +28,36 @@
 ## 四、实验结果  
 
 1. 画图  
-![用例图](./Lab2_UseCaseDiagram.jpg)  
+![用例图](https://github.com/stop-imagine/uml-modeling-2020/blob/master/students/1714080902325/Lab2_UseCaseDiagram.jpg)  
 图1:演唱会售票系统的用例图
 
 ## 表1：新增场次用例规约  
 
 用例编号  | UC01 | 备注  
 -|:-|-  
 用例名称  | 新增场次  |   
-前置条件  | 销售人员登陆进入演唱会售票系统   | *可选*   
+前置条件  | 销售人员进入新增演唱会场次页面   | *可选*   
 后置条件  |      | *可选*   
-基本流程  | 1. 销售人员点击新增场次按钮；  |*用例执行成功的步骤*    
-~| 2. 系统显示新增场次页面；  |   
-~| 3. 销售人员输入歌手姓名、时间、场地，点击添加按钮；  |   
-~| 4. 系统查询场次信息，检查该歌手当天无场次安排，检查使用场地当天无场次安排，保存新增场次信息；  | 
-~| 5. 系统提示演唱会新增场次成功。
-扩展流程  | 4.1 系统检查发现该歌手当天已有安排，提示销售人员"歌手时间冲突"； |*用例执行失败*    
-~| 4.2 系统检查发现该场地当天已有安排，提示销售人员"场地使用冲突"。 |
+基本流程  | 1. 销售人员输入演唱会信息；  |*用例执行成功的步骤*    
+~| 2. 销售人员点击新增按钮；  |   
+~| 3. 系统检查演唱会场次没有冲突；  |   
+~| 4. 系统保存演唱会场次信息；  | 
+~| 5. 系统提示新增成功。
+扩展流程  | 3.1 系统检查演唱会场次存在冲突，提示“演唱会场次冲突”，返回演唱会新增页面； |*用例执行失败*    
 
 ## 表2：设置票价和数量用例规约  
 
 用例编号  | UC02 | 备注  
 -|:-|-  
 用例名称  | 设置票价和数量  |   
-前置条件  | 销售人员新增演唱会场次成功  | *可选*   
+前置条件  | 销售人员进入设置票价和数量界面，并选择对应演唱会场次  | *可选*   
 后置条件  |    | *可选*   
-基本流程  | 1. 销售人员点击设置票价和数量按钮；  |*用例执行成功的步骤*    
-~| 2. 系统显示票价和数量框；  |   
-~| 3. 销售人员依次输入票价和对应的数量，点击确定按钮；  |   
-~| 4. 系统查询场地信息，检查当前设置票券的总数量小于该场地容纳人数，保存票价与数量信息；  |   
-~| 5. 系统提示设置成功。  |   
-扩展流程  | 4.1 系统检查发现当前设置票券的总数量大于该场地容纳人数，提示销售人员"座位不足"。 |*用例执行失败*   
-
-## 表3：查询售票情况用例规约  
-
-用例编号  | UC03 | 备注  
--|:-|-  
-用例名称  | 查询售票情况  |   
-前置条件  | 销售人员登陆进入演唱会售票系统  | *可选*   
-后置条件  | | *可选*   
-基本流程  | 1. 销售人员点击查询按钮；  |*用例执行成功的步骤*    
-~| 2. 系统显示演唱会查询页面；  |   
-~| 3. 销售人员输入歌手姓名、选择时间，点击查询按钮；  |   
-~| 4. 系统检查歌手姓名不为空，查询场次信息，显示当前演唱会页面。  | 
-~| 5. 销售人员点击售票情况按钮；  |
-~| 6. 系统显示售票情况页面。   |
-扩展流程  | 4.1 系统检查发现歌手姓名为空，提示销售人员"歌手姓名不能为空"。 |*用例执行失败*    
+基本流程  | 1. 销售人员输入票价和对应的数量；  |*用例执行成功的步骤*    
+~| 2. 销售人员点击确认按钮；  |   
+~| 3. 系统检查总票数小于场馆容纳人数；  |   
+~| 4. 系统保存票价和数量信息；  |   
+~| 5. 系统提示添加成功。  |   
+扩展流程  | 3.1 系统检查总票数大于场馆容纳人数，提示“座位不足”，返回设置票价和数量页面。 |*用例执行失败*   
+
+## 五、实验体会
+    本次实验主要是确认系统的用例以及编写用例规约。用例是模型的核心，因为它影响系统设计的其他元素，对应系统所提供的一个功能，反应系统交付给用户的价值。实验过程中体会较深的是查询用例，查询不到信息并不属于用例执行失败（查询用例已舍去）。

students/1714080902325/Lab3.md

@@ -0,0 +1,34 @@
+# 实验三：过程建模
+
+## 一、实验目标
+
+1. 掌握过程建模方法；
+2. 掌握活动图的画法。（Activity Diagram）
+
+## 二、实验内容  
+
+1. 设计活动与操作；
+2. 画出活动图。
+
+## 三、实验步骤  
+
+1. 完善实验二用例规约；
+2. 创建两个活动图：新增场次活动图、设置票价和数量活动图；
+3. 根据用例规约添加活动过程和分支；
+4. 使用不同的颜色标出重点过程（Action）；
+5. 活动图排版；
+6. 编写实验文档。
+
+## 四、实验结果  
+
+![新增场次活动图](https://github.com/stop-imagine/uml-modeling-2020/blob/master/students/1714080902325/Lab3_ActivityDiagram1.jpg)  
+图1:新增场次的活动图
+
+![设置票价和数量活动图](https://github.com/stop-imagine/uml-modeling-2020/blob/master/students/1714080902325/Lab3_ActivityDiagram2.jpg)  
+图2:设置票价和数量的活动图
+
+## 五、实验体会
+
+1. 实验前要对本地库进行git pull进行同步修改；
+2. 使用不用的颜色标出系统的重点过程（Action）；
+3. 活动图尽量不要出现交叉的连线，保持美观。

students/1714080902325/Lab4&5.md

@@ -0,0 +1,44 @@
+# 实验四、五：类建模、高级类建模
+
+## 一、实验目标
+
+1. 掌握类建模方法；
+2. 了解MVC或你熟悉的设计模式；
+3. 掌握类图的画法；（Class Diagram）
+4. 理解类的5中关系；
+5. 掌握类之间关系的画法。
+
+## 二、实验内容  
+
+1. 基于MVC模式设计类；
+2. 设计类的关系；
+3. 画出类图。
+
+## 三、实验步骤  
+
+1. 完善实验三过程建模和实验二用例规约，提取用例中的类；
+2. 创建两个类图：新增场次类图、设置票价和数量类图；
+3. 学习MVC模式，理解类之间的5种关系
+   - 依赖（Dependency）
+   - 关联（Association）
+   - 聚合（Aggregation）
+   - 组合（Composition）"has-a"
+   - 继承（Inheritance）"is-a"
+4. 使用MVC模式画类图；
+5. 编写实验文档。
+
+## 四、实验结果  
+
+![新增场次的类图](https://github.com/stop-imagine/uml-modeling-2020/blob/master/students/1714080902325/Lab45_ClassDiagram1.jpg)  
+图1:新增场次的类图
+
+![设置票价和数量的类图](https://github.com/stop-imagine/uml-modeling-2020/blob/master/students/1714080902325/Lab45_ClassDiagram2.jpg)  
+图2:设置票价和数量的类图
+
+## 五、实验体会
+
+1. 设计模式方面的知识涉略较浅，此前对MVC模式尚有一点了解；
+2. 本系统选用MVC模式设计，MVC模式是一种软件框架模式，被广泛应用在JavaEE项目的开发中；
+3. 实验过程中加深了对类之间关系的理解，特别是“组合”与“继承”之间的区别和联系；
+4. 尽管“继承”属于OOP三大特性之一（其最大的优点就是扩展简单），但大多数缺点都很致命，因为这个扩展简单的优点太明显了，很多人并不深入思考，造成了许多问题；
+5. 在UML设计中，应注意每一个符号的作用，切勿随意使用。

students/1714080902325/Lab6.md

@@ -0,0 +1,34 @@
+# 实验六：交互建模
+
+## 一、实验目标
+
+1. 理解系统交互；
+2. 掌握UML顺序图的画法；
+3. 掌握对象交互的定义和建模方法。
+
+## 二、实验内容  
+
+1. 根据用例模型和类模型，确定功能所涉及的系统对象；
+2. 在顺序图上画出参与者；
+3. 在顺序图上画出消息。
+
+## 三、实验步骤  
+
+1. 修改前面的实验，完善类图；
+2. 创建两个顺序图：新增场次顺序图、设置票价和数量顺序图；
+3. 根据类图确定"1 + N"参与者；
+4. 根据用例规约和活动图，确定消息通信；
+5. 编写实验文档。
+
+## 四、实验结果  
+
+![新增场次的顺序图](https://github.com/stop-imagine/uml-modeling-2020/blob/master/students/1714080902325/Lab6_SequenceDiagram1.jpg)  
+图1:新增场次的顺序图
+
+![设置票价和数量的顺序图](https://github.com/stop-imagine/uml-modeling-2020/blob/master/students/1714080902325/Lab6_SequenceDiagram2.jpg)  
+图2:设置票价和数量的顺序图
+
+## 五、实验体会
+
+1. 顺序图中的顺序，仅表示执行前后顺序，不表示时间跨度；
+2. 实验过程有点类似于迭代式开发，快速设计和实现，并根据老师和同学的反馈，及时对系统模型设计做出调整，因此"反馈"是一个很重要的环节。

students/1714080902325/Lab7.md

@@ -0,0 +1,29 @@
+# 实验七：状态建模
+
+## 一、实验目标
+
+1. 掌握对象状态建模（状态图，Statechart）。
+
+## 二、实验内容  
+
+1. 观看视频学习对象的状态概念和状态建模；
+2. 提取选题中的对象并分析其状态；
+3. 画出状态图。
+
+## 三、实验步骤  
+
+1. 寻找一个关键的状态：演唱会门票；
+2. 设计演唱会门票的关键状态：已上线的、已售的、过期的；
+3. 设计状态之间的转变条件；
+4. 编写实验文档。
+
+## 四、实验结果  
+
+![演唱会门票的状态图](https://github.com/stop-imagine/uml-modeling-2020/blob/master/students/1714080902325/Lab7_StatechartDiagram.jpg)  
+图1:演唱会门票的状态图
+
+## 五、实验体会
+
+1. 描述状态是一个形容词，不能写不存在的状态；
+2. 分析对象的状态时，不要拘束于自己所选择的功能；
+3. 整个状态图都是在描述一个对象。