Merge pull request #2402 from xavier-bulos/master

#2 #3 #4 #5 #6 #7 #1087 实验4,5,6,7及修改实验2,3

students/1714080902406/lab2.md

@@ -12,11 +12,11 @@
 3.2  题目是#1087 手机商品订单管理系统    
 3.3  创建用例图      
 （1）确认参与者：手机店主  
-（2）添加用例：获取订单详情，修改订单信息       
+（2）添加用例：获取订单详情，修改订单       
 （3）使用StartUML画出用例图       
 3.4 编写用例规约   
 （1）编写获取订单详情用例规约    
-（2）编写修改订单信息用例规约    
+（2）编写修改订单用例规约    
 ## 4 实验结果  
 ![第一张用例图](./UseCaseDiagram1.jpg)  
  图1：手机商品订单管理系统用例图     
@@ -28,23 +28,34 @@
 用例名称  | 获取订单详情  |   
 前置条件  |   手机店主有订单   | *可选*   
 后置条件  |      | *可选*   
-基本流程  | 1. 系统显示订单列表  |*用例执行成功的步骤*   
-~| 2. 手机店主点击列表项  | 
-~| 3. 系统获取订单详细表  |
-~|4. 页面显示订单信息|
-扩展流程  | 1.1 系统没有显示订单列表|*用例执行失败*    
+基本流程  | 1. 手机店主点击订单未出货订单按钮 |*用例执行成功的步骤*   
+~| 2. 系统查询未出货订单列表  |
+~| 3.1. 查询结果为空，系统提示“没有订单”|
+~| 3.2. 查询结果不为空，系统显示订单列表，进入步骤4  | 
+~| 4. 手机店主点击列表项  | 
+~| 5. 系统查询订单详细  |
+~| 6. 系统显示订单信息页面|
+扩展流程  | |*用例执行失败*        
 
-## 表2：修改订单信息用例规约  
+## 表2：修改订单用例规约  
 
 用例编号  | UC02 | 备注  
 -|:-|-  
 用例名称  |修改订单信息 |   
 前置条件  |  系统显示订单详情页面    | *可选*   
 后置条件  |      | *可选*   
 基本流程  |1. 手机店主点击修改订单按钮 |*用例执行成功的步骤*    
-~| 2. 页面获取订单详细表并并显示可修改订单信息页面 |
-~| 3. 手机店主输入订单信息 |
-~|4. 手机店主点击完成按钮|
-~| 5. 系统保存到订单详细表，提示“修改订单成功”  |
-~| 6. 系统跳转到订单详情页面  |  
-扩展流程  | 3.1  系统检测订单信息输入的内容为空 ，提示“输入内容不能为空”|*用例执行失败*   
+~| 2. 系统查询订单详细 |
+~| 3. 系统显示可修改订单信息页面 |
+~| 4. 手机店主输入订单信息 |
+~| 5. 手机店主点击完成按钮|
+~| 6. 系统更新订单详细，提示“修改订单成功”  |  
+扩展流程  | 5.1.  系统检测订单信息输入的内容为空 ，提示“输入内容不能为空”|*用例执行失败* 
+~| 5.2. 返回步骤4 |
+~| 5.3. 系统检测订单信息输入的内容不合法，提示“输入内容不合法” |
+~| 5.4. 返回步骤4 |
+
+## 5 实验总结
+1. 用例规约编写要写清楚系统的关键行为。
+2. 用例规约编写要清楚判断的条件，前一步的关键行为会产生什么不同的结果。
+3. 分清用例执行失败的条件是什么，阻止用例执行的因素有哪些？

students/1714080902406/lab3.md

@@ -7,20 +7,28 @@
 
 ## 二.实验内容
 
-根据实验二中的用例规约创建活动图
+根据实验二中的用例规约创建活动图。
 
 ## 三.实验步骤
 
-1. 观看老师视频，熟悉活动图（Activity Diagram）的符号及其用法
-2. 在StarUML创建Activity Diagram
-3. 添加Initial结点
+1. 观看老师视频，熟悉活动图（Activity Diagram）的符号及其用法。
+2. 在StarUML创建Activity Diagram。
+3. 添加Initial结点。
 4. 根据实验二中的用例规约添加Action和Decision
-5. 用Control Flow连接图形
-6. 添加Final结点
-7. 调节符号之间的间距和比例，完善活动图
+5. 边画边思考用例规约的每一步。
+6. 发现错误或不足，修改第二次实验的用例规约。
+7. 完善活动图。
+8. 提交活动图图到GitHub上并撰写实验报告。
 
 ## 四.实验结果
+
 ![Lab3_1](./lab3_1.jpg)  
 图1：获取订单详情活动图  
+
 ![Lab3_2](./lab3_2.jpg)   
-图2：修改订单信息活动图  
+图2：修改订单活动图  
+
+## 五.实验总结
+1. 仔细分析条件判断的前一步关键行为有没有其他的结果。
+2. 系统的关键行为要画出来。
+3. 依照用例规约画活动图，边画边思考，不断完善用例规约。

students/1714080902406/lab4.md

@@ -0,0 +1,33 @@
+# 实验四五：类建模
+
+## 一、实验目标
+
+1. 掌握类建模方法。
+2. 掌握类图的画法。（Class Diagram）
+3. 了解MVC设计模式。
+
+## 二、实验内容
+
+1. 根据用例规约图中的基本流程和扩展流程设计类。
+2. 基于MVC设计模式画出类图。
+
+## 三、实验步骤
+
+1. 先确定整个用例所设计到的类、试图和控制器。
+2. 根据用例规约添加相应的类、试图和控制器。
+3. 分析各个类之间的关系。
+4. 给每个类、试图和控制器连接建立关系。
+5. 完善类图。
+6. 提交类图到GitHub上并撰写实验报告。
+
+## 四、实验结果
+
+![Lab4_1](./lab4_1.jpg)  
+图1：获取订单详情类图 
+
+![Lab4_2](./lab4_2.jpg)   
+图2：修改订单活类图  
+
+## 五.实验总结
+1. 深刻理解类和类的属性。像类与类之间是聚合还是继承或者说是联合(association)。
+2. 从需求分析中深度挖掘需要的类。

students/1714080902406/lab6.md

@@ -0,0 +1,36 @@
+# 实验六：交互建模
+
+## 一、实验目标
+
+1. 理解系统交互。
+2. 掌握UML顺序图的画法。
+3. 掌握对象交互的定义与建模方法。
+
+## 二、实验内容
+
+1. 根据用例模型和类模型，确定功能所涉及的系统对象。
+2. 在顺序图上画出参与者（对象）。
+3. 在顺序图上画出消息（交互）。
+
+## 三、实验步骤
+
+1. 打开实验二用例规约，实验三活动图，实验四五类图。
+2. 根据视频内容和前面的实验绘制画顺序图。
+3. 在StarUML中新建Sequence Diagram。
+4. 查看实验二用例规约，查找actor，以及根据实验四五类图，创建N+1个参与者。
+5. 根据实验三活动图的操作流程，在顺序图中画出与参与者的关系。
+6. 发现错误或不足修改之前的实验。
+7. 完善顺序图。
+8. 提交顺序图到GitHub上并撰写实验报告。
+
+## 四、实验结果
+
+![Lab6_1](./lab6_1.jpg)  
+图1：获取订单详情顺序图 
+
+![Lab6_2](./lab6_2.jpg)   
+图2：修改订单顺序图  
+
+## 五.实验总结
+1. 不被其他的程序设计思维限制到自己的系统分析与设计。
+2. 清楚理解各个类之间的联系和控制器怎么处理。

students/1714080902406/lab7.md

@@ -0,0 +1,29 @@
+# 实验7：状态建模
+
+## 一、实验目标
+
+1.掌握状态建模方法。
+2.掌握状态图的画法。（Statechart）
+
+## 二、实验内容
+
+1.根据用例规约图、活动图、用例图、类图、顺序图创建状态图。
+2.寻找一个最关键的对象。
+3.设计对象的关键状态，并用形容词描述。
+4.为各个状态的转换添加转变条件。
+
+## 三、实验步骤
+
+1. 根据用例规约图、活动图、用例图、类图、顺序图画状态图
+2. 添加Initial和Final
+3. 添加关键对象，这次实验选取对象为订单。
+4. 结合活动图，顺序图添加关键状态。
+5. 为各个状态之间的转换添加条件
+6. 完善状态图。
+7. 提交顺序图到GitHub上并撰写实验报告。
+
+## 四、实验结果
+
+![订单状态图](./lab7_1.jpg)
+
+图1:订单状态图