uml图验收问题集锦

昨晚针对我所画的uml图让师傅进行了一下验收,我也从一个宏观的角度对我这个阶段的学习有了一定的了解,挺感谢师傅的。开始听前辈们说她们在验收uml图之后才发现自己的很多了解犹如管中窥豹,但是处于某些原因(或许是为了赶进度)就不会再改正。虽说我的进度比较慢但是我不希望自己在这纷扰的学海中浮躁,我还是要尽自己所能稳重求快。废话说了这么多进入正题吧。

首先从系统的需求开始吧,也就是针对用例图遇到的问题进行汇总:用例图是描述系统需求的,在uml中是属于比较宏观的了,其他的图除了实现图之外其他的都是针对某个小用例而言的。在画用例图时,关系之间的注释表明的不太完善,这个缺陷会导致项目经理或者用户在了解需求时很费劲。另外对扩展和包含两类关系的运用不太好。对此,急需重申一遍两者的用法:包含是完成一个用例必须设计到另一个用例,而扩展是可以让问题解决锦上添花的用例关系。例如:我要起床必须要穿衣的,但是我可以化妆也可以素颜出门,也就是化妆针对起床出门用例来说是扩展关系。(呵呵,可能不太恰当,但是就是这个道理啦。)如下图:

确定需求之后就要去明白系统的问题域,对系统的静态架构进行描述。这就需求绘制类图和对象图以及包图之间的关系了。往往一个系统的类图会有很多,怎样才能做到尽可能的完整呢。这就必须要明确一个主线了。我的原则是从用户角色开始、接下来是边界类、控制类和实体类。我的原则依据是从用户出发,按与用户接触最近的界面然后是一系列的逻辑操作,之后是内部的数据库表实体进行描述的,师傅说我的分类思想和三层有些相似,我现在还没有学到三层只能理解到这种程度了。与此,我在uml图类图中出现的问题如下:我的类图描述不准确,每个窗体都应该建立一个类图,之后是每个功能的实现方法整体封装成一个类,但是我是直接把功能当作了类的实现中的一个操作方法,这样在代码实现阶段是很不可能的事情。还有当初对于包图的理解不够深,不知道怎么用,进而在uml图类图中也只是一带而过,没有具体的描述。在这里急需重申一些包图的用法:在画类图的时候尽量让类之间的关系少一些,也就是松耦合的思想,这样可以保持类的独立性。但是有时候有需要指明类之间的关系怎么办呢。这就需要包图发挥作用了,可以把类图用包图进行分类,然后类之间的关系用包之间的调用来完成。

在所有的图中,师傅说画的相对到位的就是活动图了。所以在这里就不提活动图有什么问题了。

活动图强调系统的动态行为,而状态图是针对行为出现的结果进行描述的。虽说师傅评价我的状态图画的还算可以吧。但是我还是在验收过程中遇到了自己的一个严重不足,我在画图初始,企图用一张状态图描述系统所有的情况,这种观点是很不现实的,就算可以勉强实现也会导致问题域不明确。所以在这里主要就是注意一下状态图只能描述一个对象在整个过程中的变化情况。

系统的动态行为明确之后,就需要对用例的具体实现形式进行描述了。这就用到了交互图,交互图包括序列图和协作图两部分,具体的可以点击“交互图”查看。在这里我所犯的错有:试图用一幅图描述整个系统,实际这也是不现实的。一个消息从建立到传递、返回和销毁之后就可以结束本交互图,进而另一个活动的描述需要重新建立一张图。在我的交互图中还需注意的一点是:所有的对象都是从类中进行实例化出来的所以一般格式是:(object
name):class name其中的对象名可以省略这样的类叫匿名类。但是很多人的对象是临时命名的。导致在对象之间进行交互时不能通过调用彼此的操作来实现。这就像过年的时候租赁女友似的,虽然临时定义一个女友可以让你带回家见爸妈。但是毕竟你们之间没有很大的默契,所以难免会出现 你发出一个信号对方无法应答的闹剧。uml图中的对象也一样,只有把提前定义好的类进行实例化,才可以直接调用彼此的操作。

最后到了实现的阶段,也就是需要用到实现图了,实现图包含组件图和部署图两种。由于现阶段我们对实现图运用和把握不太准确,这里就只能了解到这个程度了。需要完善的地方我会在以后的学习中不断的改进。

这是我昨晚的收获,经历验收过程之后终于我也可以把uml的9类图,像冰糖葫芦一样穿起来了,当然我还有许多需要完善。这里调用一句矫情的话来表达自己的思想吧:生命不息,学不止步。。。。O(∩_∩)O

uml图验收问题集锦

时间: 2024-10-12 00:35:32

uml图验收问题集锦的相关文章

团队项目——需求和UML图——改

由于上一个方案实际效果并不理想,而且与报给老师的初始项目不吻合,所以在此换成原先的设想,继续完成一笔画游戏.我们仍计划用Unity引擎进行开发,但是由于一笔画的特点,这次的成品应是一个2d横版平台解谜类游戏,以下该项目是需求和UML图. 需求: 1.游戏世界为2D横版卷轴式 2.主角骑摩托车在游戏世界里单方向行驶(没有后退,朝向不变) 3.物理效果与现实类似,摩托车只能在地面行驶(不能浮空) 4.游戏世界中的场景由起点.平台.机关.终点组成 5.在一个关卡内,玩家从起点出发,抵达终点视为此关胜利

Markdown简明教程4-Markdown UML图

1. 前言 Markdown是一种轻量级的标记语言,把作者从繁杂的排版工作中解放出来,实现易读易写的文章写作,已经逐渐成为事实上的行业标准.CSDN博客支持Markdown可以让广大博友更加专注于博客内容,大赞.但是,不少博友可能对Markdown比较生疏,本博接下来用一个系列文章<Markdown简明教程>扼要介绍Markdown,希望可以对大家有所帮助. 系列教程目录 关于Markdown Markdown基本使用 Markdown表格和公式 Markdown UML图 CSDN Mark

对于UML图的重新认识

从看UML视频一路走来,发现无时无刻不涉及到图啊!不过之前的大话设计啊!还是第一遍对于机房的画图也只是局限于表面的理解而已,对于这次机房重构与UML图的在此相遇,让自己又重新认识了一下: UML图设计面向对象的整个分析过程,其实对于每个过程使用什么图,自己已经写过博客了,详情UML图-核心基础 现在再次写这篇博客,其实主要就是想对UML有一个整体的认识.UML总共有9种,那么到底该如何把他综合一下让大脑易于理解呢?我把他分成了四种: 为什么把时序图,协作图,活动图三种放在用例图一起呢?其实你仔细

java 类与类之间的关系 及uml图

类与接口之间的关系 : 继承 类与类之间的关系 :继承关系  包含关系 类与对象之间的关系 : 实例 UML 类图中类与类之间的关系: 泛化关系(generalization) 关联关系(association) 聚合关系(aggregation) 合成关系 (compostion) 依赖关系 (dependency) 1.泛化(Generalization)[泛化]表示类与类之间的继承关系,接口与接口之间的继承关系,或类对接口的实现关系.一般化的关系是从子类指向父类的,与继承或实现的方法相反.

如何制作 Objective-C 的UML图 [1]

说明 本教程旨在教你如何制作 Objective-C 的UML图,此为第一部分. 步骤 注册(在线制作) https://www.processon.com/ 创建UML项目 协议,抽象类,具体类(抽象的都用红色表示) 一个类实例化了另一个类 -未完待续-

用Enterprise Architecture绘制十种UML图

UML课程作业要求绘制十种UML图,选择Enterprise Architecture作为绘图工具,每次绘制图都要上网找教程,感觉十分麻烦,而且有些图没有找到具体教程,靠自己摸索找到了绘制方法,现在总结一下使用Enterprise Architecture如何绘制这十种图,方便大家使用.(写完博客后发表发现图都没了,坑爹的CSDN,大家按照文字描述的步骤也能顺利完成) 首先这十种图分别是: 概念类图,活动图,状态机图,用例图,顺序图,通讯图,设计类图,包图,组件图,部署图. 先来介绍一下前五种图

使用plantuml生成uml图

主要包括以下三步: 一.到http://plantuml.com/download 下载plantuml.jar ,我将这个软件放置到home的/home/munication/WORKM/ProgramSelf/PlantUML/目录下面 二.使用顺手的编辑器,我用vim输入以下内容: 假如文件名称为: bobAlice.uml 1 @startuml 2 Bob -> Alice: Hello, how are you? 3 Alice --> Bob: Fine, thank you,

UnityEngine.UI类库UML图

今天看了下UGUI的源码,然后简单画了下他的UML图,以后若是碰到问题可以从UML图里找或者需要实现什么功能可以先到类库查看一下UGUI本身带有了那些组件给我们.

[转]解析UML建模语言中的UML图分类、 UML各种图形及作用

本文向大家介绍一下UML图分类,作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分. UML图大致可分为五类,共有九种图形. AD: 本文和大家重点讨论一下UML图分类,标准建模语言UML的重要内容可以由下列五类图(共9种图形)来定义.请看下面详细介绍. UML图分类 -------------------------------------------------------------------------------- 作为一种建模语言,UML的定义包括UML语义和UML