UML学习:机房收费系统-类图

前言

上回说到一个软件系统的用例图在开发过程中起到的作用,并且通过机房收费系统对用例图进行了阐述,这次继续看看类图在软件开发中的一些作用和特点。
在以前的认识中,一直觉得学生可以当作一般用户,但是再后来的学习中,才发现如果将学生归为一般类,那么在接下来的类图中,一般用户的行为将无法再划分,即老师和学生的行为会出现冲突,导致该类的执行错误。所以,将学生进行单个归类之后,就可以将一般用户级别的类进行具体的行为细化。

机房收费系统类图

类图分析

学生类

属性行为一览图:
这里写图片描述

一般用户类

属性行为一览图:
这里写图片描述

操作员类

属性行为一览图:
这里写图片描述

管理员类

属性行为一览图:
这里写图片描述

附加类

此外,对于机房收费系统中最关键的一个类别就是“上机卡”了,有了上机卡的卡号,我们才可以正常使用机房收费系统,下面是“卡”这个类的类图
属性行为一览图:
这里写图片描述

关系总图

下面就是我对机房收费系统的一个初步的理解整理而成的类图。对于管理员,操作员,一般用户之间的关系,我开始觉得用泛化比较贴切,因为一般用户的权限管理员和操作员可以有,操作员的权限管理员可以有。所以,一般用户的操作权限是从操作员继承而来,同理,操作员继承了管理员。但是,后来想了想,操作员和一般用户之间在代码上并没有明确的对管理员进行继承,反而是两个单独的类,只是权限共享范围不同而已,所以做了一下小的修改形成了这张图。
这里写图片描述

总结

总之,一个软件的类图是用例的一个具体的体现,好的类图才能让接口写起来更加清楚,让开发的分工更加明确。
通过对类图的描绘,总算是对这个机房收费系统有了更深一步的理解,也通过画类图,对我在逻辑方面的想法有了一次小锻炼。

以下是宿舍管理系统类图UML示例: ![宿舍管理系统类图](https://i.imgur.com/7IhBdXl.png) 在上面的类图中,我们可以看到以下几个类: 1. Student(学生):代表学生,具有属性如姓名、学号、性别等,以及方法如查询个人信息、缴费等。 2. Dormitory(宿舍):代表宿舍,具有属性如宿舍号、宿舍类型、床位数等,以及方法如查询宿舍信息、安排床位等。 3. Roommate(室友):代表室友,具有属性如姓名、联系方式等,以及方法如查询室友信息、联系室友等。 4. DormitoryManager(宿舍管理员):代表宿舍管理员,具有属性如姓名、联系方式等,以及方法如管理宿舍、处理学生投诉等。 5. System(系统):代表整个宿舍管理系统,具有方法如查询学生信息、安排床位、处理学生投诉等。 这个类图展示了上述类之间的关系,如: - 学生与宿舍之间的关系是多对一,即一个宿舍可以有多个学生,一个学生只能属于一个宿舍。 - 宿舍与室友之间的关系是一对多,即一个宿舍可以有多个室友,一个室友只能属于一个宿舍。 - 宿舍管理员与宿舍之间的关系是一对多,即一个宿舍管理员可以管理多个宿舍,一个宿舍只能有一个宿舍管理员。 - 系统与其他类之间的关系是聚合关系,即系统包含了学生、宿舍、室友和宿舍管理员,系统可以调用这些类的方法来完成宿舍管理的功能。 这个宿舍管理系统类图仅为示例,实际系统中可能需要更多的类和关系来完整地描述宿舍管理系统的功能。
评论 27
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值