如何绘制UML活动图

本文介绍了UML活动图,它可记录单个操作、用户案例或业务流程的逻辑。创建UML活动图需反复执行以下步骤:定义活动图范围、添加起始和结束点、添加活动、添加活动间转变、添加决策点以及找出可并行活动之处。
部署运行你感兴趣的模型镜像

Scott W. Ambler 
  UML 活动图记录了单个操作或方法的逻辑,单个用户案例,或者单个业务流程的逻辑。要创建一个 UML 活动图,您需要反复执行下列步骤。
  第一步,定义活动图的范围首先应该定义您要对什么建模。单个用户案例力?一个用户案例的一部分?一个包含多个用户案例的商务流程?一个类的单个方法?一旦您定义了您所作图的范围,您应该在其顶部,用一个标注添加标签,指明该图的标题和唯一的标示符。您有可能也想要包括该图的时间甚至作者名。
  第二步,添加起始和结束点每个活动图有一个起始点和结束点,因此您也要马上添加它们。在 《UML 精粹》(UML Distilled) (参见参考资料),Fowler 和 Scott 认为结束点是可选的。有时候一个活动只是一个简单的结束,如果是这种情况,指明其唯一的转变是到一个结束点也是无害的。这样,当其他人阅读您的图时,他或她知道您已经考虑了如何退出这些活动。
  第三步,添加活动如果您正对一个用户案例建模,对每个角色(actor)所发出的主要步骤引入一个活动(该活动可能包括起始步骤,加上对起始步骤系统响应的任何步骤)。如果您正对一个高层的商务流程建模,对每个主要流程引入一个活动,通常为一个用户案例或用户案例包。最后,如果您正对一个方法建模,那么对此引入一个活动是很常见的。   第四步,添加活动间的转变我的风格总是应该退出一个活动,即使它是转变到一个结束点。一旦一个活动有多个转变时,您必需对每个转变加以相应标示。
  第五步,添加决策点有时候,您所建模的逻辑需要做出一个决策。有可能是需要检查某些事务或比较某些事务。要注意的是,使用决策点是可选的。例如,在图 1 中,我可以只是简单地将“接受”和“拒绝”两个转变直接接到“在大学报名(Enroll in University)”活动。
  第六步,找出可并行活动之处当两个活动间没有直接的联系,而且它们都必需在第三个活动开始前结束,那它们是可以并行运行的。在图 1 中,您看到是有可能“参加简要介绍(attend overview)”和“报名研讨班(enroll in seminars)”可以按任意次序进行,但是它们都得在您结束整个流程前完成。

图 1. 一个在学校首次报名的 UML 活动图 

 

您可能感兴趣的与本文相关的镜像

Stable-Diffusion-3.5

Stable-Diffusion-3.5

图片生成
Stable-Diffusion

Stable Diffusion 3.5 (SD 3.5) 是由 Stability AI 推出的新一代文本到图像生成模型,相比 3.0 版本,它提升了图像质量、运行速度和硬件效率

<think>首先,用户要求我根据“学生注册信息及档案系统项目的功能需求、用户角色和任务划分”绘制一个UML活动图。用户提到了参考之前的引用,但这些引用是关于其他系统的UML应用示例,所以我需要基于用户描述来创建活动图。 用户提供的引用中,有关于UML建模的通用信息,但没有直接给出这个特定系统的需求。用户说:“我想根据给定的学生注册信息及档案系统的项目描述绘制UML活动图”,但没有提供实际的项目描述。我需要检查上下文。 在用户的消息中,他说:“上述引用仅供参考,并不是用户真正的需求,请尽可能多的参考用户上一次的问题和你的回答。”所以,我应该回顾之前的对话。 回顾对话历史: - 用户上一次的问题是:“请根据给定的学生注册信息及档案系统的项目描述绘制UML活动图” - 但在当前消息中,用户没有重复项目描述。用户说:“我想根据给定的学生注册信息及档案系统的项目描述绘制UML活动图”,可能是在引用之前的消息。 在系统指令中,有一个示例是关于快速排序的,但没有直接的项目描述。用户当前的输入包括引用,但这些引用是关于其他主题的。 用户的消息:"我想根据给定的学生注册信息及档案系统的项目描述绘制UML活动图" – 但没有提供描述。用户说:"上述引用仅供参考,并不是用户真正的需求",所以真正的需求可能来自之前的交互。 在对话历史中,用户第一次消息是系统指令的示例。然后,用户发送了当前消息,引用了一些UML相关的内容。 用户说:“请尽可能多的参考用户上一次的问题和你的回答。” – 上一次的问题是什么?在对话中,用户的上一条消息是当前这条,其中包含了引用和请求。 或许用户是在暗示项目描述在之前的消息中。但在提供的对话中,没有显式的项目描述。用户说“给定的学生注册信息及档案系统的项目描述”,但没有给出。 再看用户消息:"参考站内引用:引用[1]:...引用[2]:...引用[3]:...引用[4]:...引用[5]:" – 这些引用是关于UML的其他应用,不是直接的项目描述。 用户说:“依据学生注册信息及档案系统项目的功能需求、用户角色和任务划分” – 所以我需要推断或基于通用知识来创建活动图,因为用户没有提供具体描述。 为了响应,我应该创建一个通用的学生注册信息及档案系统UML活动图,基于常见需求。 关键元素: - **功能需求**:用户提到了学生注册信息及档案系统。典型功能包括:学生注册、登录、提交信息、更新档案、管理员审核等。 - **用户角色**:常见的角色包括:学生、管理员(例如注册官)、系统管理员等。 - **任务划分**:描述不同角色如何交互完成任务。 基于引用中的模式: - 引用[4]中有用户、商家、配送人员等角色和活动。 - 引用[5]是关于教师登录和上传文件的活动。 - 所以我应该定义角色和活动。 假设标准的系统: - **用户角色**: - 学生:注册、登录、更新个人信息、查看档案。 - 管理员:审核注册、管理档案、处理请求(例如成绩更新)。 - 可能有系统管理员维护系统。 - **功能需求**: - 学生可以注册新账户。 - 学生登录后可以提交或更新个人信息(如地址、联系方式)。 - 学生可以查看自己的学术档案(如成绩、课程注册)。 - 管理员可以审核新注册、批准信息更改、生成报告等。 - **任务划分**:活动图可以从学生开始注册或登录,再到具体操作。 UML活动图元素: - 开始节点。 - 动作节点(活动)。 - 决策节点(菱形)。 - 合并节点。 - 结束节点。 - 泳道(代表不同角色)。 结构: 1. **开始**:例如,学生访问系统。 2. **注册流程**:如果新学生,则注册;否则登录。 3. **登录流程**:验证凭证。 4. **主菜单**:登录后,学生可以选择查看档案、更新信息等。 5. **具体操作**:例如,更新信息可能需要管理员批准。 6. **结束**:操作完成后。 包括错误处理:例如,密码找回(参考引用[2])。 基于引用[5]的登录活动图示例。 绘制活动图文本描述或伪代码格式,因为这是文本响应。 响应结构: 1. 解释活动图。 2. 提供活动图的描述或代码块。 3. 生成相关问题。 系统指令要求: - 使用中文回答。 - 行内数学表达式用$...$,但这里不需要LaTeX数学。 - 独立公式用$$...$$,但可能不适用。 - 生成相关问题。 - 引用末尾添加引用标识,如果需要。 在回应中,我需要创建一个UML活动图描述。 最终输出: - 描述活动图。 - 可能用文本或伪代码表示。 - 然后在“相关问题”部分生成问题。 </think>根据您的请求,我将为您绘制一个关于“学生注册信息及档案系统”的UML活动图活动图用于描述系统的业务流程和角色交互,重点关注功能需求、用户角色和任务划分。我会基于常见的学生注册系统需求进行设计,并参考您提供的引用内容(特别是引用[4]和[5]中关于活动图、角色和流程的示例)。如果您有更具体的需求细节(如系统功能的详细描述),请提供以便进一步定制。 ### 系统概述 - **功能需求**:系统支持学生注册、登录、个人信息管理、档案查看及更新;管理员负责审核注册申请、管理档案数据、处理请求(如成绩录入或信息修改)。 - **用户角色**: - **学生**:注册新账户、登录系统、更新个人信息、查看学术档案(如成绩单、课程记录)。 - **管理员**:审核学生注册申请、批准信息变更、生成报告、维护系统数据。 - **系统管理员**:系统维护和用户管理(参考引用[4]中的角色划分)。 - **任务划分**:学生触发注册或登录流程;管理员处理审核任务;系统管理员监控整体流程。活动图会使用泳道(Swimlane)区分角色,确保任务分工明确(类似引用[4]的活动图示例)。 ### UML活动图设计 活动图从系统入口开始,涵盖注册、登录、操作和错误处理等场景。决策节点(菱形)表示分支(如验证失败),动作节点表示具体任务。泳道用于隔离不同角色的活动(学生泳道、管理员泳道、系统泳道),以提高可读性。以下是活动图的文本描述(基于UML标准): ```plantuml @startuml title 学生注册信息及档案系统活动图 partition 学生 { :开始访问系统; if (是否为新用户?) then (是) :填写注册信息(姓名、邮箱、密码等); else (否) :输入用户名和密码登录; endif :提交信息; } partition 系统 { if (信息有效?) then (是) if (针对注册请求) then (是) :生成注册申请; -> 管理员泳道; // 切换泳道 else (针对登录请求) :验证登录凭证; if (验证成功?) then (是) :记录登录状态; -> 学生泳道; // 切换回学生泳道 else (否) :显示错误提示; -> 学生泳道; // 返回错误处理 endif endif else (否) :显示错误提示(如信息不完整); -> 学生泳道; endif } partition 管理员 { :接收注册申请; :审核申请(检查资料真实性); if (审核通过?) then (是) :批准注册; :创建学生档案; -> 系统泳道; // 切换泳道 else (否) :拒绝申请; :通知学生; -> 结束; // 流程终止 endif } partition 学生 { :登录后主菜单; switch (选择操作) case (更新个人档案) :提交信息变更(如地址、联系方式); -> 管理员泳道; // 切换泳道 case (查看学术档案) :请求查看成绩或课程记录; :系统显示档案; case (找回密码) :输入邮箱验证; :系统发送重置链接; :重置密码; endswitch } partition 管理员 { :接收信息变更请求; :审核变更; if (批准?) then (是) :更新档案数据库; :通知学生; else (否) :拒绝变更; endif } partition 系统 { :记录操作日志; :更新数据库; :结束; } @enduml ``` ### 活动图说明 1. **开始和注册/登录流程**:学生访问系统时,决策节点判断是否为新用户。新用户填写注册信息后,提交到系统验证;现有用户直接登录(参考引用[5]的登录流程)。 2. **系统验证和错误处理**:系统检查信息有效性。无效时显示错误(如密码错误或信息不全),学生可重新输入或找回密码(基于引用[2]的密码恢复功能)。 3. **管理员审核**:注册申请或信息变更需管理员审核(类似引用[4]的订单管理员审核流程)。批准后创建或更新档案;拒绝则通知学生。 4. **学生操作**:登录后,学生可选择更新档案、查看档案或找回密码。查看档案直接由系统响应;更新操作需管理员介入。 5. **系统维护**:所有操作后,系统记录日志并更新数据库(系统泳道负责)。 6. **结束**:操作完成后流程终止。 此设计确保了角色任务清晰:学生触发流程,管理员处理审批,系统保障数据一致性和错误恢复(如密码找回)。活动图覆盖了主要功能路径,包括异常处理(验证失败),提高了系统的可靠性和用户体验[^4]。 ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值