毕业设计之感悟 —— UML 与 ER 图

    今天毕业设计答辩,虽然我第一个上场,但是不是特别紧张,因为整个系统都是我写的。我以为自己天衣无缝,能应付所有老师的所有问题。事实上,我被老师教育了一番。

    老师说我,毕业论文中没有一个类。我一开始比较懵,什么没有类?然后我和老师说我写了什么什么类。老师说,没有 UML 类图之类的东西。

    其实我一开始是抗拒的。UML 类图,有什么用?不就是面向对象的类图嘛?直接画 E-R 图不行吗?老师和我说了面向对象的软件工程方法,首先需求分析,然后画 UML 图,UML 设计好了,再具体实现 E-R 图等等。

    虽然被说得很懵,但是回去我整理了一下思路。我记得很多企业现在并不会把 UML 图放在设计里,大多数情况下都是架构师自己画一画,并不写在设计里。不过这不是主要的,我在想,为什么我们需要 UML 图,具体而言,E-R 图难道不够替代 UML 图吗?

    其实,仔细想想,E-R 图的确不能替代 UML 图。起码 UML 图是面向对象的,E-R 图不能使纯粹的面向对象的,或者说,E-R 图并不能完全面向对象的思考。

    就比如,我现在有个测试的实体,包括测试信息(题号,题名,内容等)和多组测试用例。一定要注意多组测试用例。假如我们用 E-R 图进行思考的话,最终很容易提前走向纠结:多组测试用例到底是一张表还是和测试信息合成一张表?如果是一张表,总觉得对应现实中的实体很变扭;如果合并成一张表,那么多组测试用例要么分开保存,要么合并保存:分开保存必定有冗余性的问题;合并保存,那每组测试用例以什么作为分隔符怎么保存呢?似乎也不好,测试用例可能有多组分隔符。E-R 图非纯面向对象(至少我是这么认为的),所以不应该以 E-R 图作为需求分析阶段的图,还没有到达这种细化的地步。

    老师说的还是比较正确的,我也虚心接受批评。以后我要多认真学习一下软件工程了。

    前路漫漫,唯码作伴。

转载于:https://www.cnblogs.com/Piers/p/6957994.html

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
UML是一种常用的软件设计工具,用于表示类的结构和关系。以下是一些常见的UML设计规范: 1. 类名:使用大驼峰命名法(PascalCase)命名类名,并尽量使用清晰、具有描述性的词汇来表示类的功能。 2. 属性:在类中,属性以名称:类型的形式表示。属性名称使用小驼峰命名法(camelCase),并尽量避免使用简写或缩写,以增强可读性。 3. 方法:方法以名称(参数列表):返回类型的形式表示。方法名称同样使用小驼峰命名法,并尽量遵循动词加名词的命名规则,清晰地表达方法的功能。 4. 可见性:在UML中,属性和方法可以指定可见性,包括public(+)、private(-)、protected(#)和包级私有(~)。根据设计需求和访问控制原则,为属性和方法指定适当的可见性。 5. 关联关系:在类中,关联关系通过连接两个类之间的线表示。可以使用无箭头线表示双向关联,箭头指向关联方表示单向关联。 6. 继承关系:继承关系使用带空心三角形的实线表示,箭头指向父类。子类继承了父类的属性和方法。 7. 实现关系:实现关系使用带空心三角形的虚线表示,箭头指向实现的接口。类需要实现接口中定义的所有方法。 8. 类之间的依赖关系:依赖关系使用带箭头的虚线表示,箭头指向被依赖的类。依赖关系表示一个类使用了另一个类作为方法参数、局部变量或返回类型。 9. 类布局:根据设计需要,可以将相关联的类分组排布在一起,以增强可读性。 这些是常见的UML设计规范,具体的设计方式还需根据项目需求和团队约定进行调整。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值