|
|
|
|
@ -0,0 +1,989 @@
|
|
|
|
|
# 实验二操作指南 v3.1：软件需求分析
|
|
|
|
|
|
|
|
|
|
**实验课时安排：** 2课时，90分钟（第一次课程）+ 2课时，90分钟（第二次课程）
|
|
|
|
|
|
|
|
|
|
> **版本信息**：v3.1
|
|
|
|
|
> **更新日期**：2025-11-09
|
|
|
|
|
> **更新内容**：参考实验一操作V3.md格式，优化文档结构，调整时间估算，修正编程语言为Java，添加EAGitOps实验环境支持
|
|
|
|
|
> **适用项目**：校园代理系统
|
|
|
|
|
> **适用团队**：G9组（范孝宝,董文远，董玉坤，程璟琦）
|
|
|
|
|
> **预计完成时间**：900分钟（约15小时）
|
|
|
|
|
> **实验环境**：EAGitOps（Enterprise Architect + Git + Jenkins + SonarQube + MYSQL）
|
|
|
|
|
|
|
|
|
|
**重要提示：** 本文档中的"个人功能"是通用术语，学生在完成实验时应替换为自己实际负责的具体功能。例如：
|
|
|
|
|
- 范孝宝同学应将"个人功能"替换为"注册登录功能"（包括人员注册、账号登录和密码找回三个子功能）
|
|
|
|
|
|
|
|
|
|
## 1. 实验环境与工具
|
|
|
|
|
|
|
|
|
|
### 1.1 EAGitOps实验环境
|
|
|
|
|
|
|
|
|
|
本实验使用EAGitOps（Enterprise Architect + Git + Jenkins + SonarQube + PostgreSQL）集成环境，提供完整的软件工程工具链支持。
|
|
|
|
|
|
|
|
|
|
#### 1.1.1 环境组件
|
|
|
|
|
|
|
|
|
|
| 工具类别 | 工具名称 | 版本要求 | 用途说明 |
|
|
|
|
|
|---------|---------|---------|---------|
|
|
|
|
|
| 建模工具 | Enterprise Architect | v13.0以上 | 需求建模、UML图绘制 |
|
|
|
|
|
| 版本控制 | Git | v2.0以上 | 代码版本管理 |
|
|
|
|
|
| 数据库 | MYSQL | v12.0以上 | 数据存储与管理 |
|
|
|
|
|
| 开发环境 | TRAE | v1.0以上 | 文档生成与代码优化 |
|
|
|
|
|
| 构建工具 | Maven | v3.6以上 | 项目构建与依赖管理 |
|
|
|
|
|
| 持续集成 | Jenkins | v2.300以上 | 自动化构建与测试 |
|
|
|
|
|
| 代码质量 | SonarQube | v8.0以上 | 代码质量分析 |
|
|
|
|
|
| 代码仓库 | Gitea | v1.16以上 | Git仓库管理服务 |
|
|
|
|
|
| 数据库 | MYSQL | v12.0以上 | 数据存储与管理 |
|
|
|
|
|
|
|
|
|
|
#### 1.1.2 EAGitOps环境启动顺序
|
|
|
|
|
|
|
|
|
|
1. **启动MYSQL数据库服务**
|
|
|
|
|
```
|
|
|
|
|
net start mysql
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
2. **启动Gitea代码仓库服务**
|
|
|
|
|
```
|
|
|
|
|
cd /d E:\eagitops\gitea
|
|
|
|
|
gitea.exe web
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
3. **启动Tomcat服务器（Jenkins）**
|
|
|
|
|
```
|
|
|
|
|
cd /d E:\eagitops\tomcat\bin
|
|
|
|
|
startup.bat
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
4. **启动SonarQube服务**
|
|
|
|
|
```
|
|
|
|
|
cd /d E:\eagitops\sonarqube\bin\windows-x86-64
|
|
|
|
|
StartSonar.bat
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
#### 1.1.3 EAGitOps环境访问地址
|
|
|
|
|
|
|
|
|
|
| 服务名称 | 访问地址 | 默认账号 | 默认密码 |
|
|
|
|
|
|---------|---------|---------|---------|
|
|
|
|
|
| Gitea | http://localhost:3000 | root | password |
|
|
|
|
|
| Jenkins | http://localhost:8080/jenkins | admin | admin |
|
|
|
|
|
| SonarQube | http://localhost:9000 | admin | admin |
|
|
|
|
|
| MYSQL | localhost:3306 | root | root |
|
|
|
|
|
|
|
|
|
|
### 1.2 环境配置要求
|
|
|
|
|
|
|
|
|
|
- **操作系统**：Windows 11
|
|
|
|
|
- **内存要求**：最低8GB，推荐16GB
|
|
|
|
|
- **存储空间**：至少20GB可用空间
|
|
|
|
|
- **网络要求**：稳定的互联网连接（用于工具下载和更新）
|
|
|
|
|
- **EAGitOps安装路径**：E:\eagitops\（默认路径，可根据实际情况调整）
|
|
|
|
|
|
|
|
|
|
### 1.3 EAGitOps工具链使用指南
|
|
|
|
|
|
|
|
|
|
#### 1.3.1 环境变量配置
|
|
|
|
|
|
|
|
|
|
在使用EAGitOps工具链前，需要配置以下环境变量：
|
|
|
|
|
|
|
|
|
|
```batch
|
|
|
|
|
@echo off
|
|
|
|
|
REM 设置EAGitOps环境变量
|
|
|
|
|
set EAGITOPS_HOME=E:\eagitops
|
|
|
|
|
set JAVA_HOME=%EAGITOPS_HOME%\jdk
|
|
|
|
|
set POSTGRESQL_HOME=%EAGITOPS_HOME%\postgresql
|
|
|
|
|
set GIT_HOME=%EAGITOPS_HOME%\git
|
|
|
|
|
set SONAR_HOME=%EAGITOPS_HOME%\sonarqube
|
|
|
|
|
set JENKINS_HOME=%EAGITOPS_HOME%\tomcat\webapps\jenkins
|
|
|
|
|
|
|
|
|
|
REM 添加到PATH
|
|
|
|
|
set PATH=%JAVA_HOME%\bin;%POSTGRESQL_HOME%\bin;%GIT_HOME%\bin;%PATH%
|
|
|
|
|
|
|
|
|
|
echo EAGitOps环境变量配置完成
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
#### 1.3.2 工具链使用流程
|
|
|
|
|
|
|
|
|
|
1. **需求建模阶段**
|
|
|
|
|
- 使用Enterprise Architect进行需求分析和建模
|
|
|
|
|
- 创建UML图（用例图、类图、序列图等）
|
|
|
|
|
- 导出需求文档和模型文件
|
|
|
|
|
|
|
|
|
|
2. **代码开发阶段**
|
|
|
|
|
- 使用TRAE进行Java代码开发
|
|
|
|
|
- 使用Git进行版本控制
|
|
|
|
|
- 提交代码到Gitea仓库
|
|
|
|
|
|
|
|
|
|
3. **持续集成阶段**
|
|
|
|
|
- 配置Jenkins构建任务
|
|
|
|
|
- 设置自动化测试和代码质量检查
|
|
|
|
|
- 集成SonarQube进行代码质量分析
|
|
|
|
|
|
|
|
|
|
4. **部署运维阶段**
|
|
|
|
|
- 使用PostgreSQL进行数据持久化
|
|
|
|
|
- 通过Jenkins实现自动化部署
|
|
|
|
|
- 使用SonarQube监控代码质量
|
|
|
|
|
|
|
|
|
|
#### 1.3.3 EAGitOps控制面板
|
|
|
|
|
|
|
|
|
|
EAGitOps提供了便捷的GUI控制面板（eagitops.au3），支持以下功能：
|
|
|
|
|
|
|
|
|
|
- **环境变量设置**：一键配置所有工具的环境变量
|
|
|
|
|
- **服务启停控制**：快速启动/停止各个服务组件
|
|
|
|
|
- **工具快速启动**：直接打开各种开发工具
|
|
|
|
|
- **状态监控**：实时查看各服务运行状态
|
|
|
|
|
|
|
|
|
|
控制面板使用方法：
|
|
|
|
|
1. 双击运行`eagitops.au3`文件
|
|
|
|
|
2. 根据需要点击相应按钮启动/停止服务
|
|
|
|
|
3. 使用"启动工具"菜单快速打开开发工具
|
|
|
|
|
4. 查看"服务状态"了解当前环境运行情况
|
|
|
|
|
|
|
|
|
|
## 时间估算与分配建议
|
|
|
|
|
|
|
|
|
|
### 总体时间安排
|
|
|
|
|
|
|
|
|
|
**实验二总时间：900分钟（15小时）**
|
|
|
|
|
- 课堂时间：180分钟（3小时，2次课程）
|
|
|
|
|
- 课后时间：720分钟（12小时）
|
|
|
|
|
|
|
|
|
|
### 详细时间分配
|
|
|
|
|
|
|
|
|
|
**第一次课程（课堂时间90分钟，1.5课时）：**
|
|
|
|
|
- 第一阶段：需求基础建模（45分钟，0.75课时）
|
|
|
|
|
- 项目词汇定义：10分钟
|
|
|
|
|
- 需求建模：15分钟
|
|
|
|
|
- 用例建模：20分钟
|
|
|
|
|
|
|
|
|
|
- 第二阶段：系统分析与设计（45分钟，0.75课时）
|
|
|
|
|
- 鲁棒建模：15分钟
|
|
|
|
|
- 分析类图：15分钟
|
|
|
|
|
- 界面设计：15分钟
|
|
|
|
|
|
|
|
|
|
**第一次课程后补充时间（360分钟，6小时）：**
|
|
|
|
|
- 用例建模（活动图绘制）：50分钟
|
|
|
|
|
- 行为建模：25分钟
|
|
|
|
|
- 数据设计：10分钟
|
|
|
|
|
- 设计类：20分钟
|
|
|
|
|
- 测试建模：20分钟
|
|
|
|
|
- 测试管理：15分钟
|
|
|
|
|
- 包图：10分钟
|
|
|
|
|
- 组件模型：10分钟
|
|
|
|
|
- 编码建模：10分钟
|
|
|
|
|
- 个人功能完整开发测试：120分钟
|
|
|
|
|
- 项目报告（第一部分）：60分钟
|
|
|
|
|
|
|
|
|
|
**第二次课程（课堂时间90分钟，1.5课时）：**
|
|
|
|
|
- 第一阶段：高级建模（45分钟，0.75课时）
|
|
|
|
|
- 行为建模：25分钟
|
|
|
|
|
- 数据设计：10分钟
|
|
|
|
|
- 设计类：10分钟
|
|
|
|
|
|
|
|
|
|
- 第二阶段：测试与部署（45分钟，0.75课时）
|
|
|
|
|
- 测试建模：20分钟
|
|
|
|
|
- 测试管理：15分钟
|
|
|
|
|
- 部署建模：10分钟
|
|
|
|
|
|
|
|
|
|
**第二次课程后补充时间（360分钟，6小时）：**
|
|
|
|
|
- 跟踪建模：10分钟
|
|
|
|
|
- 登录流水线：20分钟
|
|
|
|
|
- 所有模型优化与完善：60分钟
|
|
|
|
|
- 模型一致性检查：30分钟
|
|
|
|
|
- 个人功能完整开发测试：150分钟
|
|
|
|
|
- 项目报告（第二部分）：60分钟
|
|
|
|
|
- 实验总结与提交：30分钟
|
|
|
|
|
|
|
|
|
|
**总计：900分钟（15小时）**
|
|
|
|
|
|
|
|
|
|
### 个人甘特图
|
|
|
|
|
|
|
|
|
|
个人甘特图是规划实验二进展的重要工具，用于跟踪个人功能完成情况和时间安排。
|
|
|
|
|
|
|
|
|
|
#### 实验一检查结果甘特图
|
|
|
|
|
|
|
|
|
|
实验一的甘特图主要用于检查结果，包含以下内容：
|
|
|
|
|
|
|
|
|
|
| 实验阶段 | 课时 | 周数 | 时间安排 |
|
|
|
|
|
|---------|------|------|---------|
|
|
|
|
|
| 软件项目计划 | 2课时 | 1周 | 11.3-11.9 |
|
|
|
|
|
| 软件需求分析 | 4课时 | 2周 | 11.10-11.23 |
|
|
|
|
|
| 软件系统设计 | 6课时 | 3周 | 11.24-12.14 |
|
|
|
|
|
| 软件系统编码 | 2课时 | 2周 | 12.15-12.21 |
|
|
|
|
|
| 软件系统测试 | 2课时 | 2周 | 12.22-12.28 |
|
|
|
|
|
|
|
|
|
|
实验一甘特图资源分配：
|
|
|
|
|
- 范孝宝（开发人员）：负责注册登录功能开发和实现以及测试，包括人员注册、账号登录和密码找回三个子功能
|
|
|
|
|
|
|
|
|
|
#### 实验二甘特图绘制内容
|
|
|
|
|
|
|
|
|
|
实验二甘特图是计划性工具，用于规划实验二的工作。使用EA工具创建，包含以下内容：
|
|
|
|
|
|
|
|
|
|
1. **任务分解**：将实验二分解为24个主要任务（对应文档中的24个章节）
|
|
|
|
|
2. **时间安排**：为每个任务设置合理的时间期限（基于时间估算与分配建议）
|
|
|
|
|
3. **依赖关系**：设置多组任务间的依赖关系（如词汇定义→需求建模→用例建模等）
|
|
|
|
|
4. **资源分配**：为每个任务分配适当的资源（个人姓名）
|
|
|
|
|
|
|
|
|
|
#### EA创建甘特图步骤
|
|
|
|
|
|
|
|
|
|
1. **创建图表**：在EA中创建新的甘特图
|
|
|
|
|
2. **添加24项任务**：添加项目词汇定义、需求建模、用例建模等24项任务
|
|
|
|
|
3. **设置多组依赖关系**：建立任务间的依赖关系（如词汇定义→需求建模→用例建模等）
|
|
|
|
|
4. **分配资源**：为每个任务分配资源（个人姓名）
|
|
|
|
|
5. **导出分享**：导出甘特图为PNG或PDF格式
|
|
|
|
|
|
|
|
|
|
#### 实验二甘特图与实验一甘特图的区别
|
|
|
|
|
|
|
|
|
|
1. **用途不同**：
|
|
|
|
|
- 实验一甘特图：用于检查结果，展示已完成的工作
|
|
|
|
|
- 实验二甘特图：用于计划工作，规划即将完成的任务
|
|
|
|
|
|
|
|
|
|
2. **内容不同**：
|
|
|
|
|
- 实验一甘特图：展示5个实验阶段的时间安排和资源分配
|
|
|
|
|
- 实验二甘特图：展示24个具体任务的时间安排、依赖关系和资源分配
|
|
|
|
|
|
|
|
|
|
3. **时间范围不同**：
|
|
|
|
|
- 实验一甘特图：覆盖整个学期的5个实验阶段
|
|
|
|
|
- 实验二甘特图：仅覆盖实验二的15小时（900分钟）
|
|
|
|
|
|
|
|
|
|
### 时间管理建议
|
|
|
|
|
1. **第一次课程重点**：第一次课程主要完成基础建模工作，建立需求分析的基本框架
|
|
|
|
|
2. **第二次课程重点**：第二次课程主要完成行为建模和测试建模，完善需求分析
|
|
|
|
|
3. **课后补充完成**：课后时间主要用于活动图绘制、项目报告撰写和模型完善
|
|
|
|
|
4. **个人功能完整开发**：个人功能完整开发测试需要充足时间，第一次课程后120分钟，第二次课程后150分钟，确保功能完整实现
|
|
|
|
|
5. **重点任务**：优先完成用例建模、分析类图和行为建模，这些是需求分析的核心内容
|
|
|
|
|
6. **及时保存**：EA模型和文档要经常保存，避免意外丢失
|
|
|
|
|
7. **工具熟练度**：提前熟悉EA工具的各项功能，可显著提高建模效率
|
|
|
|
|
8. **模型一致性**：确保两次课程之间模型的一致性和连贯性，避免重复工作
|
|
|
|
|
9. **开发测试规划**：合理安排个人功能完整开发测试时间，确保有足够时间完成功能的完整开发、测试和运维
|
|
|
|
|
10. **合理时间分配**：实验总时长为15小时，课堂时间3小时，课后时间12小时，确保质量
|
|
|
|
|
11. **甘特图管理**：使用个人甘特图跟踪任务进度，及时调整计划，确保按时完成
|
|
|
|
|
12. **新增任务安排**：包图、组件模型和编码建模等新增任务已纳入时间分配，确保所有建模内容完整覆盖
|
|
|
|
|
13. **报告撰写时间**：项目报告时间已优化为每次课程后60分钟，确保报告质量同时避免时间浪费
|
|
|
|
|
|
|
|
|
|
## 目录
|
|
|
|
|
|
|
|
|
|
1. [时间估算与分配建议](#时间估算与分配建议)
|
|
|
|
|
2. [个人功能清单与团队协作](#2-个人功能清单与团队协作)
|
|
|
|
|
3. [项目词汇定义](#3-项目词汇定义)
|
|
|
|
|
4. [需求建模](#4-需求建模)
|
|
|
|
|
5. [用例建模](#5-用例建模)
|
|
|
|
|
6. [鲁棒建模](#6-鲁棒建模)
|
|
|
|
|
7. [分析类图](#7-分析类图)
|
|
|
|
|
8. [界面设计](#8-界面设计)
|
|
|
|
|
9. [数据设计](#9-数据设计)
|
|
|
|
|
10. [设计类](#10-设计类)
|
|
|
|
|
11. [行为建模](#11-行为建模)
|
|
|
|
|
12. [包图](#12-包图)
|
|
|
|
|
13. [组件模型](#13-组件模型)
|
|
|
|
|
14. [编码建模](#14-编码建模)
|
|
|
|
|
15. [测试建模](#15-测试建模)
|
|
|
|
|
16. [测试管理](#16-测试管理)
|
|
|
|
|
17. [部署建模](#17-部署建模)
|
|
|
|
|
18. [跟踪建模](#18-跟踪建模)
|
|
|
|
|
19. [登录流水线](#19-登录流水线)
|
|
|
|
|
20. [项目报告](#20-项目报告)
|
|
|
|
|
21. [实验提交内容](#21-实验提交内容)
|
|
|
|
|
22. [评分标准](#22-评分标准)
|
|
|
|
|
23. [注意事项](#23-注意事项)
|
|
|
|
|
24. [版本更新说明](#24-版本更新说明)
|
|
|
|
|
|
|
|
|
|
## 2. 个人功能清单与团队协作
|
|
|
|
|
|
|
|
|
|
### 个人功能清单
|
|
|
|
|
每位成员需要在feature_姓名拼音缩写分支中完成以下任务：
|
|
|
|
|
|
|
|
|
|
1. **范孝宝（开发人员）**
|
|
|
|
|
- 负责注册登录功能的完整开发，包括人员注册、账号登录和密码找回三个子功能
|
|
|
|
|
- 完成相关功能的完整测试
|
|
|
|
|
- 完成相关功能的完整运维
|
|
|
|
|
- 完成相关功能的完整模型绘制
|
|
|
|
|
- 在feature_fxb分支中完成个人功能
|
|
|
|
|
|
|
|
|
|
### 个人功能完整开发测试流程
|
|
|
|
|
1. **第一次课程后个人功能完整开发测试（120分钟）**
|
|
|
|
|
- 各成员在个人功能分支中完成个人功能的完整开发
|
|
|
|
|
- 完成个人功能的完整测试
|
|
|
|
|
- 完成个人功能的完整运维
|
|
|
|
|
- 提交代码到个人功能分支
|
|
|
|
|
- 完成个人功能的完整模型绘制
|
|
|
|
|
- 完成个人功能的完整文档记录
|
|
|
|
|
- 使用TRAE辅助生成和优化文档
|
|
|
|
|
|
|
|
|
|
2. **第二次课程后个人功能完整开发测试（150分钟）**
|
|
|
|
|
- 各成员在个人功能分支中完成优化后的个人功能
|
|
|
|
|
- 完善个人功能的开发、测试和运维
|
|
|
|
|
- 提交代码到个人功能分支
|
|
|
|
|
- 完善个人功能的完整模型绘制
|
|
|
|
|
- 完善个人功能的完整文档记录
|
|
|
|
|
- 使用TRAE辅助生成和优化文档
|
|
|
|
|
|
|
|
|
|
### 最终提交成果物
|
|
|
|
|
1. **个人功能完整开发测试报告**（Markdown格式）
|
|
|
|
|
- 包含个人功能概述、开发过程、测试结果、运维情况等完整内容
|
|
|
|
|
- 附有EA绘制的个人功能完整模型图
|
|
|
|
|
- 附有个人甘特图，记录实验二进展
|
|
|
|
|
- 使用TRAE辅助生成和优化报告内容
|
|
|
|
|
|
|
|
|
|
2. **个人功能EA模型文件**（.qea格式）
|
|
|
|
|
- 个人功能词汇定义
|
|
|
|
|
|
|
|
|
|
- 个人功能需求模型
|
|
|
|
|
|
|
|
|
|
- 个人功能用例模型
|
|
|
|
|
|
|
|
|
|
- 个人功能分析类图
|
|
|
|
|
|
|
|
|
|
- 个人功能设计类图
|
|
|
|
|
- 个人功能行为模型
|
|
|
|
|
|
|
|
|
|
- 个人功能测试模型
|
|
|
|
|
|
|
|
|
|
- 个人功能部署模型等
|
|
|
|
|
|
|
|
|
|
- 个人甘特图模型
|
|
|
|
|
|
|
|
|
|
1. **个人功能头歌项目仓库**
|
|
|
|
|
- 包含个人功能的完整文档结构
|
|
|
|
|
- 个人功能的完整代码和测试
|
|
|
|
|
- 个人功能的运维配置和说明文档
|
|
|
|
|
- 个人甘特图文件（PNG或PDF格式）
|
|
|
|
|
- TRAE生成的辅助文档
|
|
|
|
|
|
|
|
|
|
2. **实验二个人总结报告**
|
|
|
|
|
- 个人功能完整开发测试总结
|
|
|
|
|
- 个人工具使用心得
|
|
|
|
|
- 个人问题与解决方案
|
|
|
|
|
- 个人甘特图分析与总结
|
|
|
|
|
|
|
|
|
|
## 3. 项目词汇定义（预计时间：20分钟）
|
|
|
|
|
|
|
|
|
|
**步骤：**
|
|
|
|
|
1. 打开EA软件，创建新项目
|
|
|
|
|
2. 在项目中创建"项目词汇"包
|
|
|
|
|
3. 添加必要的项目词汇和定义
|
|
|
|
|
4. 导出词汇列表并粘贴到报告中
|
|
|
|
|
5. 使用TRAE辅助生成和优化词汇定义部分
|
|
|
|
|
|
|
|
|
|
**注意事项：**
|
|
|
|
|
- 词汇应包括系统中的关键术语和缩写
|
|
|
|
|
- 每个词汇应有明确的定义
|
|
|
|
|
- 使用EA的导出列表功能，不要截图
|
|
|
|
|
- TRAE生成的词汇定义需要人工审查和修改
|
|
|
|
|
|
|
|
|
|
## 4. 需求建模（预计时间：25分钟）
|
|
|
|
|
|
|
|
|
|
**步骤：**
|
|
|
|
|
1. 在EA中创建"需求建模"包
|
|
|
|
|
2. 添加系统需求项
|
|
|
|
|
3. 为每个需求添加详细描述
|
|
|
|
|
4. 建立需求之间的关联关系
|
|
|
|
|
5. 导出需求列表并粘贴到报告中
|
|
|
|
|
6. 使用TRAE辅助生成和优化需求文档
|
|
|
|
|
|
|
|
|
|
**注意事项：**
|
|
|
|
|
- 需求应明确、可测试、可验证
|
|
|
|
|
- TRAE生成的需求文档需要人工审查和修改
|
|
|
|
|
|
|
|
|
|
## 5. 用例建模（预计时间：60分钟）
|
|
|
|
|
|
|
|
|
|
**步骤：**
|
|
|
|
|
1. 在EA中创建"用例建模"包
|
|
|
|
|
2. 识别系统参与者（如用户、系统管理员等）
|
|
|
|
|
3. 识别系统用例（如人员注册、账号登录、密码找回等）
|
|
|
|
|
4. 绘制用例图
|
|
|
|
|
5. 为主要用例编写用例描述
|
|
|
|
|
6. 绘制用例活动图：
|
|
|
|
|
- 在EA中选择用例，右键点击并选择"新建子图"→"活动图"
|
|
|
|
|
- 识别活动开始点和结束点
|
|
|
|
|
- 添加活动节点，表示用例中的主要步骤
|
|
|
|
|
- 添加决策节点，表示条件判断
|
|
|
|
|
- 添加泳道（可选），表示不同参与者的职责
|
|
|
|
|
- 设置活动之间的转换关系
|
|
|
|
|
- 添加必要的注释和约束
|
|
|
|
|
- 检查活动图的完整性和正确性
|
|
|
|
|
7. 使用TRAE辅助生成和优化用例描述
|
|
|
|
|
|
|
|
|
|
**注意事项：**
|
|
|
|
|
- 用例图应包含参与者、用例和它们之间的关系
|
|
|
|
|
- 活动图应清晰展示用例的执行流程和决策点
|
|
|
|
|
- 活动图中的每个活动应对应用例描述中的步骤
|
|
|
|
|
- TRAE生成的用例描述需要人工审查和修改
|
|
|
|
|
|
|
|
|
|
## 6. 鲁棒建模（预计时间：35分钟）
|
|
|
|
|
|
|
|
|
|
**步骤：**
|
|
|
|
|
1. 在EA中创建"鲁棒建模"包
|
|
|
|
|
2. 以登录为例，识别视图对象、控制对象和实体对象
|
|
|
|
|
3. 绘制鲁棒图
|
|
|
|
|
4. 使用TRAE辅助生成和优化鲁棒建模说明
|
|
|
|
|
|
|
|
|
|
**账号登录鲁棒建模示例：**
|
|
|
|
|
- 视图对象：用户登录界面、输入界面、错误界面、欢迎界面等
|
|
|
|
|
- 控制对象：用户登录成功与否控制对象
|
|
|
|
|
- 实体对象：用户账号、密码等属性的实体对象
|
|
|
|
|
|
|
|
|
|
**注意事项：**
|
|
|
|
|
- 鲁棒图是分析阶段的产物，用于初步设计系统结构
|
|
|
|
|
- 可保留不修改
|
|
|
|
|
- TRAE生成的鲁棒建模说明需要人工审查和修改
|
|
|
|
|
|
|
|
|
|
## 7. 分析类图（预计时间：45分钟）
|
|
|
|
|
|
|
|
|
|
**步骤：**
|
|
|
|
|
1. 在EA中创建"分析类图"包
|
|
|
|
|
2. 识别系统中的关键类
|
|
|
|
|
3. 确定类的属性和操作
|
|
|
|
|
4. 建立类之间的关系（关联、继承、聚合等）
|
|
|
|
|
5. 绘制分析类图
|
|
|
|
|
6. 使用TRAE辅助生成和优化类图说明
|
|
|
|
|
|
|
|
|
|
**注意事项：**
|
|
|
|
|
- 分析类图应反映业务领域建模
|
|
|
|
|
- 更新此图，确保与系统需求一致
|
|
|
|
|
- TRAE生成的类图说明需要人工审查和修改
|
|
|
|
|
|
|
|
|
|
## 8. 界面设计（预计时间：35分钟）
|
|
|
|
|
|
|
|
|
|
**步骤：**
|
|
|
|
|
1. 在EA中创建"界面设计"包
|
|
|
|
|
2. 设计系统主要界面
|
|
|
|
|
3. 绘制界面原型图
|
|
|
|
|
4. 使用TRAE辅助生成和优化界面设计说明
|
|
|
|
|
|
|
|
|
|
**注意事项：**
|
|
|
|
|
- 界面设计应符合用户习惯和系统需求
|
|
|
|
|
- 考虑界面的易用性和美观性
|
|
|
|
|
- TRAE生成的界面设计说明需要人工审查和修改
|
|
|
|
|
|
|
|
|
|
## 9. 数据设计（预计时间：45分钟）
|
|
|
|
|
|
|
|
|
|
**步骤：**
|
|
|
|
|
1. 在EA中创建"数据设计"包
|
|
|
|
|
2. 设计系统物理模型
|
|
|
|
|
3. 绘制ER图（实体-关系图）（概念转逻辑转物理模型/数据模型）
|
|
|
|
|
4. EA生成或编写DDL语句
|
|
|
|
|
5. 推荐使用SQLite数据库或PostgreSQL数据库
|
|
|
|
|
6. 使用TRAE辅助生成和优化数据设计文档
|
|
|
|
|
|
|
|
|
|
**注意事项：**
|
|
|
|
|
- 物理模型应考虑数据库性能和扩展性
|
|
|
|
|
- DDL语句应完整且可执行
|
|
|
|
|
- TRAE生成的数据设计文档需要人工审查和修改
|
|
|
|
|
|
|
|
|
|
## 10. 设计类（预计时间：55分钟）
|
|
|
|
|
|
|
|
|
|
**步骤：**
|
|
|
|
|
1. 在EA中创建"设计类"包
|
|
|
|
|
2. 基于分析类图进行细化设计
|
|
|
|
|
3. 添加详细的属性和方法
|
|
|
|
|
4. 考虑实现细节和技术选型
|
|
|
|
|
5. 绘制设计类图
|
|
|
|
|
6. 使用TRAE辅助生成和优化设计类说明
|
|
|
|
|
|
|
|
|
|
**注意事项：**
|
|
|
|
|
- 更新后，只保留类，说明性图文
|
|
|
|
|
- 设计类图应考虑系统实现的技术细节
|
|
|
|
|
- TRAE生成的设计类说明需要人工审查和修改
|
|
|
|
|
|
|
|
|
|
## 11. 行为建模（预计时间：70分钟）
|
|
|
|
|
|
|
|
|
|
**步骤：**
|
|
|
|
|
1. 在EA中创建"行为建模"包
|
|
|
|
|
2. 进行分析级行为建模：
|
|
|
|
|
- 识别类，找出关键属性和操作以及类间关系
|
|
|
|
|
- 可中文描述，是开发者从系统用户需求和业务需求提炼得到
|
|
|
|
|
3. 进行设计级别行为建模：
|
|
|
|
|
- 着重考虑系统需求，实现数据存储数据库的业务需求和系统需求
|
|
|
|
|
4. 进行实现级别行为建模：
|
|
|
|
|
- 此图为所有模型图的核心，所有类，及其对象的行为
|
|
|
|
|
5. 补充文字描述此图的逻辑序列
|
|
|
|
|
6. 使用TRAE辅助生成和优化行为建模说明
|
|
|
|
|
|
|
|
|
|
**注意事项：**
|
|
|
|
|
- 分析级行为建模图与分析类图对应，都属于分析级别的UML模型图
|
|
|
|
|
- 实现级别行为建模是所有模型图的核心，必须掌握
|
|
|
|
|
- TRAE生成的行为建模说明需要人工审查和修改
|
|
|
|
|
|
|
|
|
|
## 12. 包图（预计时间：25分钟）
|
|
|
|
|
|
|
|
|
|
**步骤：**
|
|
|
|
|
1. 在EA中创建"包图"包
|
|
|
|
|
2. 设计个人功能包结构
|
|
|
|
|
3. 绘制包图
|
|
|
|
|
4. 使用TRAE辅助生成和优化包图说明
|
|
|
|
|
|
|
|
|
|
**注意事项：**
|
|
|
|
|
- 个人功能包中应包含视图、控制、实体类等
|
|
|
|
|
- 包结构应清晰 reflect个人功能的模块划分
|
|
|
|
|
- TRAE生成的包图说明需要人工审查和修改
|
|
|
|
|
|
|
|
|
|
## 13. 组件模型（预计时间：25分钟）
|
|
|
|
|
|
|
|
|
|
**步骤：**
|
|
|
|
|
1. 在EA中创建"组件模型"包
|
|
|
|
|
2. 识别个人功能组件
|
|
|
|
|
3. 绘制组件图
|
|
|
|
|
4. 更新后截图
|
|
|
|
|
5. 使用TRAE辅助生成和优化组件模型说明
|
|
|
|
|
|
|
|
|
|
**注意事项：**
|
|
|
|
|
- 组件应具有明确的功能和接口
|
|
|
|
|
- 组件之间的关系应清晰
|
|
|
|
|
- 组件模型应支持个人功能的独立开发和测试
|
|
|
|
|
- TRAE生成的组件模型说明需要人工审查和修改
|
|
|
|
|
|
|
|
|
|
## 14. 编码建模（预计时间：50分钟）
|
|
|
|
|
|
|
|
|
|
**步骤：**
|
|
|
|
|
1. 在EA中创建"编码建模"包
|
|
|
|
|
2. 设计代码结构
|
|
|
|
|
3. 实现关键功能的代码片段
|
|
|
|
|
4. 记录实现的【图文码】
|
|
|
|
|
- EA所绘制的模型图
|
|
|
|
|
- 文、码可采用TRAE辅助生成和优化
|
|
|
|
|
- 头歌项目托管提供质检、部署的运维管理
|
|
|
|
|
|
|
|
|
|
**核心：**
|
|
|
|
|
- 个人在本次实验中完成个人功能的完整开发测试
|
|
|
|
|
|
|
|
|
|
**注意事项：**
|
|
|
|
|
- 代码应符合编码规范
|
|
|
|
|
- 考虑代码的可读性和可维护性
|
|
|
|
|
- 建议使用TRAE进行代码补全和优化，但不要直接生成代码
|
|
|
|
|
- TRAE生成的代码需要人工审查和修改
|
|
|
|
|
|
|
|
|
|
## 15. 测试建模（预计时间：60分钟）
|
|
|
|
|
|
|
|
|
|
**步骤：**
|
|
|
|
|
1. 在EA中创建"测试建模"包
|
|
|
|
|
2. 补充测试框架，测试类型等必要的文字说明
|
|
|
|
|
3. 进行编码vs单测建模
|
|
|
|
|
4. 进行设计vs集测建模
|
|
|
|
|
5. 进行分析vs系测建模
|
|
|
|
|
6. 进行需求vs验测建模
|
|
|
|
|
7. 使用TRAE辅助生成和优化测试用例
|
|
|
|
|
|
|
|
|
|
**注意事项：**
|
|
|
|
|
- 测试建模应覆盖系统的各个层面
|
|
|
|
|
- 不同级别的测试有不同的目标和范围
|
|
|
|
|
- TRAE生成的测试用例需要人工审查和修改
|
|
|
|
|
|
|
|
|
|
## 16. 测试管理（预计时间：35分钟）
|
|
|
|
|
|
|
|
|
|
**步骤：**
|
|
|
|
|
1. 在EA中创建"测试管理"包
|
|
|
|
|
2. 设计测试用例
|
|
|
|
|
3. 制定测试计划
|
|
|
|
|
4. 导出测试列表并粘贴到报告中
|
|
|
|
|
5. 使用TRAE辅助生成和优化测试计划
|
|
|
|
|
|
|
|
|
|
**注意事项：**
|
|
|
|
|
- 使用EA的导出列表功能
|
|
|
|
|
- 测试用例应覆盖主要功能和边界情况
|
|
|
|
|
- TRAE生成的测试计划需要人工审查和修改
|
|
|
|
|
|
|
|
|
|
## 17. 部署建模（预计时间：25分钟）
|
|
|
|
|
|
|
|
|
|
**步骤：**
|
|
|
|
|
1. 在EA中创建"部署建模"包
|
|
|
|
|
2. 设计系统部署架构
|
|
|
|
|
3. 绘制部署图
|
|
|
|
|
4. 更新后截图
|
|
|
|
|
5. 使用TRAE辅助生成和优化部署文档
|
|
|
|
|
|
|
|
|
|
**注意事项：**
|
|
|
|
|
- 部署图应反映系统的物理架构
|
|
|
|
|
- 考虑系统的性能和可用性要求
|
|
|
|
|
- TRAE生成的部署文档需要人工审查和修改
|
|
|
|
|
|
|
|
|
|
## 18. 跟踪建模（预计时间：25分钟）
|
|
|
|
|
|
|
|
|
|
**步骤：**
|
|
|
|
|
1. 在EA中创建"跟踪建模"包
|
|
|
|
|
2. 建立需求与设计元素之间的跟踪关系
|
|
|
|
|
3. 绘制跟踪图
|
|
|
|
|
4. 更新后截图
|
|
|
|
|
5. 使用TRAE辅助生成和优化跟踪文档
|
|
|
|
|
|
|
|
|
|
**注意事项：**
|
|
|
|
|
- 跟踪关系应确保需求可追溯
|
|
|
|
|
- 跟踪图应清晰显示需求与设计元素之间的关系
|
|
|
|
|
- TRAE生成的跟踪文档需要人工审查和修改
|
|
|
|
|
|
|
|
|
|
## 19. 登录流水线（预计时间：50分钟）
|
|
|
|
|
|
|
|
|
|
### 19.1 EAGitOps研发模式理解
|
|
|
|
|
|
|
|
|
|
EAGitOps是一种集成的软件开发模式，结合了Enterprise Architect、Git、Jenkins、SonarQube等工具，实现从需求分析到部署运维的全流程自动化。
|
|
|
|
|
|
|
|
|
|
**核心组件：**
|
|
|
|
|
- **Enterprise Architect**：完成项目的所有定义、需求、分析、设计、编码、测试以及各种管理与追踪工作
|
|
|
|
|
- **Git/Gitea**：现代版本管理工具，基于它完成团队协作
|
|
|
|
|
- **Jenkins**：自动化构建、测试、交付和发布以及部署
|
|
|
|
|
- **SonarQube**：代码质量分析和质量门禁检查
|
|
|
|
|
- **PostgreSQL**：数据持久化存储
|
|
|
|
|
- **TRAE**：文档生成与代码优化辅助工具
|
|
|
|
|
|
|
|
|
|
**开发过程模型：**
|
|
|
|
|
本项目采用DevOps模式开发，开发过程模型采用EAGitOps模式，并结合"W模型"进行软件计划测试，其中编码测试改为单元测试。这种组合模型确保了开发过程的高效性和测试的全面性，实现了开发与测试的同步进行。
|
|
|
|
|
|
|
|
|
|
### 19.2 EAGitOps流水线操作流程
|
|
|
|
|
|
|
|
|
|
#### 19.2.1 环境准备
|
|
|
|
|
1. **启动EAGitOps环境**
|
|
|
|
|
```
|
|
|
|
|
# 启动PostgreSQL
|
|
|
|
|
net start postgresql-x64-14
|
|
|
|
|
|
|
|
|
|
# 启动Gitea
|
|
|
|
|
cd /d E:\eagitops\gitea
|
|
|
|
|
gitea.exe web
|
|
|
|
|
|
|
|
|
|
# 启动Tomcat（Jenkins）
|
|
|
|
|
cd /d E:\eagitops\tomcat\bin
|
|
|
|
|
startup.bat
|
|
|
|
|
|
|
|
|
|
# 启动SonarQube
|
|
|
|
|
cd /d E:\eagitops\sonarqube\bin\windows-x86-64
|
|
|
|
|
StartSonar.bat
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
2. **配置环境变量**
|
|
|
|
|
```
|
|
|
|
|
set EAGITOPS_HOME=E:\eagitops
|
|
|
|
|
set JAVA_HOME=%EAGITOPS_HOME%\jdk
|
|
|
|
|
set POSTGRESQL_HOME=%EAGITOPS_HOME%\postgresql
|
|
|
|
|
set GIT_HOME=%EAGITOPS_HOME%\git
|
|
|
|
|
set SONAR_HOME=%EAGITOPS_HOME%\sonarqube
|
|
|
|
|
set PATH=%JAVA_HOME%\bin;%POSTGRESQL_HOME%\bin;%GIT_HOME%\bin;%PATH%
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
#### 19.2.2 流水线操作步骤
|
|
|
|
|
1. **Git拉取源码**
|
|
|
|
|
```bash
|
|
|
|
|
git clone http://localhost:3000/team/campus-agent-system.git
|
|
|
|
|
cd campus-agent-system
|
|
|
|
|
git checkout feature_fxb
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
2. **代码静态扫描**
|
|
|
|
|
- 使用SonarQube进行代码质量分析
|
|
|
|
|
- 检查代码规范、潜在bug、代码复杂度等
|
|
|
|
|
- 生成代码质量报告
|
|
|
|
|
|
|
|
|
|
3. **质量门禁检查**
|
|
|
|
|
- 设置代码质量阈值
|
|
|
|
|
- 不符合质量标准的代码无法进入下一阶段
|
|
|
|
|
- 确保代码质量持续改进
|
|
|
|
|
|
|
|
|
|
4. **构建**
|
|
|
|
|
```bash
|
|
|
|
|
mvn clean compile
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
5. **单元测试**
|
|
|
|
|
```bash
|
|
|
|
|
mvn test
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
6. **集成测试**
|
|
|
|
|
```bash
|
|
|
|
|
mvn verify
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
7. **EA的系测、验测以及测试管理**
|
|
|
|
|
- 使用EA进行系统测试和验收测试
|
|
|
|
|
- 管理测试用例和测试结果
|
|
|
|
|
- 生成测试报告
|
|
|
|
|
|
|
|
|
|
8. **交付、部署和运行**
|
|
|
|
|
- 打包应用程序
|
|
|
|
|
- 部署到测试环境
|
|
|
|
|
- 部署到生产环境
|
|
|
|
|
- 监控应用程序运行状态
|
|
|
|
|
|
|
|
|
|
9. **TRAE辅助文档生成**
|
|
|
|
|
- 使用TRAE生成项目文档
|
|
|
|
|
- 优化代码质量和文档结构
|
|
|
|
|
- 辅助生成测试报告
|
|
|
|
|
|
|
|
|
|
### 19.3 EAGitOps过程模型图与W模型图的组合
|
|
|
|
|
|
|
|
|
|
绘制EAGitOps过程模型图与W模型图的组合图，展示开发与测试的同步进行，包括：
|
|
|
|
|
|
|
|
|
|
- **需求分析 → 需求测试**
|
|
|
|
|
- 使用EA进行需求建模和需求测试
|
|
|
|
|
- 使用TRAE辅助生成需求文档
|
|
|
|
|
- 确保需求覆盖完整、可测试
|
|
|
|
|
|
|
|
|
|
- **概要设计 → 概要设计测试**
|
|
|
|
|
- 使用EA进行概要设计和设计测试
|
|
|
|
|
- 使用TRAE辅助生成设计文档
|
|
|
|
|
- 确保设计满足需求
|
|
|
|
|
|
|
|
|
|
- **详细设计 → 详细设计测试**
|
|
|
|
|
- 使用EA进行详细设计和设计测试
|
|
|
|
|
- 使用TRAE辅助生成详细设计文档
|
|
|
|
|
- 确保设计细节正确
|
|
|
|
|
|
|
|
|
|
- **编码实现 → 单元测试**
|
|
|
|
|
- 使用TRAE进行编码
|
|
|
|
|
- 使用TRAE进行代码补全和优化
|
|
|
|
|
- 使用JUnit进行单元测试
|
|
|
|
|
- 使用SonarQube进行代码质量检查
|
|
|
|
|
|
|
|
|
|
- **模块集成 → 集成测试**
|
|
|
|
|
- 使用Maven进行模块集成
|
|
|
|
|
- 使用JUnit进行集成测试
|
|
|
|
|
- 使用Jenkins自动化集成测试
|
|
|
|
|
- 使用TRAE辅助生成集成测试报告
|
|
|
|
|
|
|
|
|
|
- **系统构建 → 系统测试**
|
|
|
|
|
- 使用Jenkins进行系统构建
|
|
|
|
|
- 使用EA进行系统测试
|
|
|
|
|
- 使用TRAE辅助生成系统测试报告
|
|
|
|
|
- 确保系统功能完整
|
|
|
|
|
|
|
|
|
|
- **系统安装 → 验收测试**
|
|
|
|
|
- 使用Jenkins进行系统部署
|
|
|
|
|
- 使用EA进行验收测试
|
|
|
|
|
- 使用TRAE辅助生成验收测试报告
|
|
|
|
|
- 确保系统满足用户需求
|
|
|
|
|
|
|
|
|
|
### 19.4 EAGitOps工具链集成
|
|
|
|
|
|
|
|
|
|
**工具链集成流程：**
|
|
|
|
|
1. **EA → Git**：将EA模型导出为文档，提交到Git仓库
|
|
|
|
|
2. **Git → Jenkins**：Jenkins监听Git仓库变化，触发构建
|
|
|
|
|
3. **Jenkins → SonarQube**：Jenkins调用SonarQube进行代码质量检查
|
|
|
|
|
4. **SonarQube → Jenkins**：SonarQube返回质量检查结果，影响构建流程
|
|
|
|
|
5. **Jenkins → PostgreSQL**：Jenkins将测试结果存储到PostgreSQL
|
|
|
|
|
6. **PostgreSQL → EA**：EA从PostgreSQL读取测试结果，更新测试模型
|
|
|
|
|
7. **TRAE → 全流程**：TRAE辅助各阶段文档生成和代码优化
|
|
|
|
|
|
|
|
|
|
**注意事项：**
|
|
|
|
|
- EAGitOps是课程的核心，包括：
|
|
|
|
|
- 面向对象方法核心（Java的OO编程、UML的OO语言）
|
|
|
|
|
- DevOps模式核心（整合Git、Gitea、Jenkins、SonarQube、PostgreSQL等多种平台）
|
|
|
|
|
- 工具核心（从IDE到CASE再到UML以及DevOps）
|
|
|
|
|
- 辅助工具核心（TRAE文档生成与代码优化）
|
|
|
|
|
- 确保各工具之间的版本兼容性
|
|
|
|
|
- 定期备份重要数据和配置文件
|
|
|
|
|
- 监控各服务的运行状态，及时处理异常情况
|
|
|
|
|
- 合理使用TRAE辅助工具，提高效率但不过度依赖
|
|
|
|
|
|
|
|
|
|
## 20. 项目报告（预计时间：40分钟）
|
|
|
|
|
|
|
|
|
|
**步骤：**
|
|
|
|
|
1. 在实验二软件需求分析文档基础上修改完成
|
|
|
|
|
2. 确保所有图表和内容都已更新
|
|
|
|
|
3. 检查文档格式和结构
|
|
|
|
|
4. 完成最终报告
|
|
|
|
|
5. 使用TRAE辅助生成和优化报告内容
|
|
|
|
|
|
|
|
|
|
**注意事项：**
|
|
|
|
|
- 报告应包含所有实验内容和结果
|
|
|
|
|
- 确保图表清晰可读
|
|
|
|
|
- 检查文档的完整性和准确性
|
|
|
|
|
- TRAE生成的报告内容需要人工审查和修改
|
|
|
|
|
|
|
|
|
|
## 21. 实验提交内容
|
|
|
|
|
|
|
|
|
|
1. 注册登录功能完整开发测试报告
|
|
|
|
|
2. 注册登录功能用例图（EA格式）
|
|
|
|
|
3. 注册登录功能活动图（EA格式）
|
|
|
|
|
4. 注册登录功能UCP估算报告
|
|
|
|
|
5. 注册登录功能需求跟踪矩阵
|
|
|
|
|
6. 个人实验报告（包含注册登录功能所有EA模型图的截图和说明）
|
|
|
|
|
7. 个人甘特图（EA格式和导出的PNG/PDF格式）
|
|
|
|
|
8. TRAE辅助生成文档（包含TRAE生成的各类辅助文档和优化建议）
|
|
|
|
|
|
|
|
|
|
### 提交方式
|
|
|
|
|
1. **头歌平台提交**
|
|
|
|
|
- 将所有成果物上传至头歌平台个人仓库
|
|
|
|
|
- 确保文件结构清晰，命名规范
|
|
|
|
|
- 提交前进行自查，确保完整性
|
|
|
|
|
|
|
|
|
|
2. **文档整理**
|
|
|
|
|
- 将所有报告和文档整理到docs目录
|
|
|
|
|
- 确保Markdown文件格式正确
|
|
|
|
|
- 检查图片链接是否有效
|
|
|
|
|
|
|
|
|
|
3. **模型文件整理**
|
|
|
|
|
- 将EA模型文件整理到models目录
|
|
|
|
|
- 确保模型文件可以正常打开
|
|
|
|
|
- 导出关键模型图为PNG格式
|
|
|
|
|
|
|
|
|
|
4. **甘特图文件整理**
|
|
|
|
|
- 将个人甘特图EA文件整理到models目录
|
|
|
|
|
- 导出甘特图为PNG或PDF格式，整理到docs目录
|
|
|
|
|
- 确保甘特图清晰可读，包含完整的任务信息和进度标记
|
|
|
|
|
|
|
|
|
|
5. **TRAE辅助文档整理**
|
|
|
|
|
- 将TRAE生成的辅助文档整理到trae目录
|
|
|
|
|
- 确保文档格式正确，内容完整
|
|
|
|
|
- 添加必要的说明和注释
|
|
|
|
|
|
|
|
|
|
## 22. 评分标准
|
|
|
|
|
|
|
|
|
|
### 评分细则
|
|
|
|
|
|
|
|
|
|
| 评分项目 | 分值 | 评分标准 |
|
|
|
|
|
|---------|------|---------|
|
|
|
|
|
| 个人功能完整开发测试报告 | 15 | 内容完整、逻辑清晰、格式规范 |
|
|
|
|
|
| 注册登录功能用例图（EA格式） | 15 | 用例完整、关系正确、符合规范 |
|
|
|
|
|
| 注册登录功能活动图（EA格式） | 15 | 流程合理、状态转换正确、符合规范 |
|
|
|
|
|
| 注册登录功能UCP估算报告 | 15 | 计算准确、分析合理、符合规范 |
|
|
|
|
|
| 注册登录功能需求跟踪矩阵 | 15 | 需求覆盖完整、跟踪关系正确 |
|
|
|
|
|
| 个人实验报告 | 20 | 内容完整、格式规范、分析深入 |
|
|
|
|
|
| 个人甘特图 | 5 | 任务分解合理、时间安排科学、依赖关系正确 |
|
|
|
|
|
|
|
|
|
|
### 评分说明
|
|
|
|
|
|
|
|
|
|
1. **注册登录功能完整开发测试报告**（15分）
|
|
|
|
|
- 报告结构完整，包含功能需求、设计、实现和测试
|
|
|
|
|
- 分析深入，逻辑清晰，表达准确
|
|
|
|
|
- 格式规范，符合学术写作要求
|
|
|
|
|
|
|
|
|
|
2. **注册登录功能用例图**（15分）
|
|
|
|
|
- 用例图完整，包含所有必要的参与者和用例
|
|
|
|
|
- 关系正确，包含关联、包含和扩展关系
|
|
|
|
|
- 符合UML规范，布局合理美观
|
|
|
|
|
|
|
|
|
|
3. **注册登录功能活动图**（15分）
|
|
|
|
|
- 活动图完整，包含所有必要的活动和决策点
|
|
|
|
|
- 流程合理，状态转换正确
|
|
|
|
|
- 符合UML规范，布局清晰
|
|
|
|
|
|
|
|
|
|
4. **注册登录功能UCP估算报告**（15分）
|
|
|
|
|
- UCP计算准确，步骤完整
|
|
|
|
|
- 分析合理，考虑因素全面
|
|
|
|
|
- 符合UCP估算规范
|
|
|
|
|
|
|
|
|
|
5. **注册登录功能需求跟踪矩阵**（15分）
|
|
|
|
|
- 需求覆盖完整，无遗漏
|
|
|
|
|
- 跟踪关系正确，映射准确
|
|
|
|
|
- 格式规范，易于阅读
|
|
|
|
|
|
|
|
|
|
6. **个人实验报告**（20分）
|
|
|
|
|
- 内容完整，包含所有EA模型图的截图和说明
|
|
|
|
|
- 格式规范，符合学术写作要求
|
|
|
|
|
- 分析深入，有个人见解和思考
|
|
|
|
|
|
|
|
|
|
7. **个人甘特图**（5分）
|
|
|
|
|
- 任务分解合理，覆盖实验二所有主要任务
|
|
|
|
|
- 时间安排科学，考虑任务复杂度和依赖关系
|
|
|
|
|
- 依赖关系正确，关键路径清晰
|
|
|
|
|
- 甘特图格式规范，易于理解
|
|
|
|
|
|
|
|
|
|
### 加分项
|
|
|
|
|
|
|
|
|
|
1. **创新性**（最多加3分）
|
|
|
|
|
- 在功能设计或实现上有创新点
|
|
|
|
|
- 提出独特的解决方案或优化建议
|
|
|
|
|
|
|
|
|
|
2. **完整性**（最多加3分）
|
|
|
|
|
- 超出基本要求，提供额外的功能或分析
|
|
|
|
|
- 文档和模型特别详细和完整
|
|
|
|
|
|
|
|
|
|
3. **规范性**（最多加4分）
|
|
|
|
|
- 所有文档和模型严格遵循规范
|
|
|
|
|
- 代码和文档质量特别高
|
|
|
|
|
|
|
|
|
|
4. **TRAE工具使用**（最多加2分）
|
|
|
|
|
- 合理使用TRAE工具提高效率
|
|
|
|
|
- TRAE生成的内容经过适当修改和优化
|
|
|
|
|
|
|
|
|
|
### 扣分项
|
|
|
|
|
|
|
|
|
|
1. **迟交**（每天扣5分）
|
|
|
|
|
- 迟交作业将按天扣分，最多扣20分
|
|
|
|
|
|
|
|
|
|
2. **格式不规范**（每项扣2-5分）
|
|
|
|
|
- 文档格式不符合要求
|
|
|
|
|
- 模型不符合UML规范
|
|
|
|
|
|
|
|
|
|
3. **内容不完整**（每项扣5-10分）
|
|
|
|
|
- 缺少必要的部分或内容
|
|
|
|
|
- 分析不够深入或准确
|
|
|
|
|
|
|
|
|
|
4. **抄袭**（该项记0分）
|
|
|
|
|
- 发现抄袭行为，该项记0分
|
|
|
|
|
- 严重抄袭可能导致整个实验记0分
|
|
|
|
|
|
|
|
|
|
5. **过度依赖TRAE**（每项扣2-3分）
|
|
|
|
|
- 直接使用TRAE生成的内容，未进行适当修改
|
|
|
|
|
- TRAE生成的内容存在明显错误
|
|
|
|
|
|
|
|
|
|
## 23. 注意事项
|
|
|
|
|
|
|
|
|
|
### 实验操作注意事项
|
|
|
|
|
1. 所有EA截图操作：EA -> Public -> Save to clipboard -> Word中粘贴（Ctrl+V）
|
|
|
|
|
2. 注册登录功能模型图中作者为自己的姓名或项目代号（CHZU_CS231_SEBG09）
|
|
|
|
|
3. 除导出列表外，其他内容需要截图
|
|
|
|
|
4. 实验过程中注意保存注册登录功能EA项目文件
|
|
|
|
|
5. 个人实验报告应及时提交，避免逾期（范孝宝同学应提交"注册登录功能实验报告"）
|
|
|
|
|
6. 本次实验暂时不进行小组合并，但要求个人功能完成功能的完整开发、测试和运维
|
|
|
|
|
7. **重要：** 文档中的"个人功能"是通用术语，请务必替换为您实际负责的具体功能名称，范孝宝同学应使用"注册登录功能"（包括人员注册、账号登录和密码找回三个子功能）
|
|
|
|
|
|
|
|
|
|
### 时间管理注意事项
|
|
|
|
|
8. 合理安排时间，确保在两次课程之间有足够时间完成个人功能的完整开发测试
|
|
|
|
|
9. 建议使用甘特图跟踪进度，及时调整计划，避免临近截止日期匆忙完成
|
|
|
|
|
10. 优先完成核心建模任务（需求建模、用例建模、分析类图、行为建模），再完善其他模型
|
|
|
|
|
11. 合理安排TRAE辅助工具使用时间，确保有足够时间审查和修改生成的内容
|
|
|
|
|
|
|
|
|
|
### 实验流程注意事项
|
|
|
|
|
12. 确保模型之间的一致性，特别是需求、用例、分析和设计模型之间的对应关系
|
|
|
|
|
13. 在完成每个模型后，及时检查是否符合UML规范和课程要求
|
|
|
|
|
14. 建议在完成每个主要阶段后进行自我评估，确保达到评分标准要求
|
|
|
|
|
15. 遇到问题及时与教师或助教沟通，不要拖延到实验后期
|
|
|
|
|
|
|
|
|
|
### EAGitOps环境注意事项
|
|
|
|
|
16. **环境启动顺序**：严格按照PostgreSQL→Gitea→Tomcat(Jenkins)→SonarQube的顺序启动服务
|
|
|
|
|
17. **环境变量配置**：确保EAGitOps环境变量正确配置，包括JAVA_HOME、POSTGRESQL_HOME等
|
|
|
|
|
18. **服务端口检查**：启动前检查端口3000(Gitea)、8080(Jenkins)、9000(SonarQube)、5432(PostgreSQL)是否被占用
|
|
|
|
|
19. **服务状态监控**：定期检查各服务运行状态，异常情况及时处理
|
|
|
|
|
20. **数据备份**：定期备份Git仓库、PostgreSQL数据库和Jenkins配置
|
|
|
|
|
21. **版本兼容性**：确保各工具版本之间兼容，避免因版本不匹配导致的问题
|
|
|
|
|
22. **资源占用监控**：EAGitOps环境占用资源较多，确保系统内存和存储空间充足
|
|
|
|
|
23. **控制面板使用**：使用eagitops.au3控制面板可以简化环境管理操作
|
|
|
|
|
24. **日志查看**：遇到问题时查看各服务的日志文件，快速定位问题原因
|
|
|
|
|
25. **网络连接**：确保网络连接稳定，部分工具需要网络下载依赖或更新
|
|
|
|
|
26. **权限设置**：确保有足够的系统权限启动服务和管理文件
|
|
|
|
|
27. **防火墙设置**：检查防火墙设置，确保各服务端口可以正常访问
|
|
|
|
|
28. **服务关闭顺序**：关闭服务时按相反顺序操作：SonarQube→Tomcat(Jenkins)→Gitea→PostgreSQL
|
|
|
|
|
|
|
|
|
|
## 24. 版本更新说明
|
|
|
|
|
|
|
|
|
|
### v3.1 (2025-11-09)
|
|
|
|
|
- 添加EAGitOps实验环境支持
|
|
|
|
|
- 更新实验环境与工具章节，详细介绍EAGitOps组件
|
|
|
|
|
- 添加EAGitOps环境启动顺序和访问地址
|
|
|
|
|
- 新增EAGitOps工具链使用指南
|
|
|
|
|
- 更新登录流水线部分，添加EAGitOps具体操作步骤
|
|
|
|
|
- 添加EAGitOps环境变量配置和工具启动指南
|
|
|
|
|
- 更新注意事项，添加EAGitOps环境相关内容
|
|
|
|
|
- 添加TRAE辅助工具相关内容和使用指南
|
|
|
|
|
- 更新评分标准，添加TRAE工具使用相关评分项
|
|
|
|
|
|
|
|
|
|
### v3.0 更新内容（2025-11-09）
|
|
|
|
|
1. **文档结构优化**：
|
|
|
|
|
- 参考实验一操作V3.md格式，重新组织文档结构
|
|
|
|
|
- 添加了完整的目录结构，方便快速导航
|
|
|
|
|
- 统一了章节编号格式
|
|
|
|
|
|
|
|
|
|
2. **时间估算与分配**：
|
|
|
|
|
- 调整总时间估算为900分钟（约15小时），更符合个人功能完整开发测试的工作量
|
|
|
|
|
- 将实验内容分为两次课程，每次课程包含具体任务和时间分配
|
|
|
|
|
- 添加了时间管理建议，帮助学生更好地规划实验进度
|
|
|
|
|
|
|
|
|
|
3. **内容调整**：
|
|
|
|
|
- 修正编程语言为Java，更符合项目实际情况
|
|
|
|
|
- 添加了编码建模、组件模型、部署建模、跟踪建模和登录流水线等个人功能完整开发测试内容
|
|
|
|
|
- 保留了需求分析的核心内容：项目词汇定义、需求建模、用例建模等
|
|
|
|
|
|
|
|
|
|
4. **个人功能内容**：
|
|
|
|
|
- 添加了个人功能清单，明确各成员个人功能完整开发测试职责
|
|
|
|
|
- 详细说明了个人功能完整开发测试流程
|
|
|
|
|
- 列出了个人功能最终提交成果物清单
|
|
|
|
|
|
|
|
|
|
### 版本历史
|
|
|
|
|
- v1.0：初始版本，包含基本的实验内容和步骤
|
|
|
|
|
- v2.0：添加了详细的时间估算和注意事项
|
|
|
|
|
- v3.0：参考实验一操作V3.md格式，优化文档结构，调整时间估算，修正编程语言为Java
|
|
|
|
|
- v3.1：添加EAGitOps实验环境支持和TRAE辅助工具相关内容
|
GGBond
