uml心得体会
《的翅膀》,你必须觉得奇怪,这不是1首歌的名字吗不错,它确实是1首歌的名字,可它也是一部著名的电影,一部感动中小学生的优秀国产电影。
电影一开幕就演绎了一个悲惨的故事:活泼可爱,无忧无虑的高中女生“智华”不幸的被高压电击中,失去了双手,为了上学,她不得不学习用脚写字。学会了后,“智华”能上学了。可她母亲却疯了,她爸爸肩上的担子就更重了。“智华”用毅力把自己的成绩提升上去,最后,她体育成绩比正常人好得多。校园的老师把她推荐给特级教练。
“智华”几次灰心,想回去帮父亲,都被教练劝回去。一次“智华”的母亲听说“智华”因失去了双手而不能考大学,失心疯更严重了,竟然离家出走,最后自杀了。“智华”得知此消息十分悲哀,但是“智华”最终努力获得“残疾人运动会一等奖”并因此考上大学,她十分高兴!
我觉得她很坚强,也很勇敢。主演是雷庆瑶姐姐,她没有了双手,她用脚写的字却比我们用手写的字好看得多。
我真佩服你,没有双手却有一对的翅膀。你也是歌词中的主角:每一次,就算很受伤也不闪泪光。那里的受伤是心里的受伤,皮肉伤随着时间会痊愈,心灵的受伤也期望能随着时间淡忘。
uml心得体会
轻轻的抖落书面上的尘,翻开西游,扑鼻而来的是一种历史的清香。
西游就像是一坛美酒,久而弥香。即使是第二次品茗,也是像当初一样喜爱。
也领略到更多的道理。
记得小时候爱读西游的原因是因为喜欢孙悟空。我喜欢孙悟空,因为他神通广大。他会七十二变、会翻一个三千六百米远的跟斗,还有一个神奇的金箍棒……现在,我依旧喜欢孙悟空,但不仅仅是因为这些才喜欢它,我喜欢他身上的那种不畏强权、敢于斗争的精神,还有就是他的聪明勇敢。
他勇敢、他不畏强权。在花果山时,孙悟空纵身一跃,跳如瀑布之中,率先发现了瀑布之后别有洞天。给自己和那些猴子们一个安身的好去处,因为自己的`勇敢,是群猴推举他为大王。在天宫中,他偷吃了蟠桃、惹恼了王母娘娘,还三番四次的扰乱了天庭的秩序,但他毫不畏惧,依然我行我素。玉皇大帝、诸位神仙都怕他、烦他;即使到了如来的面前,他也是敢赌、敢玩,那股天不怕、地不怕的精神是突显在文中。也是深深的印在了我的脑海之中。
他聪明,在三打白骨精中,当白骨精第二次变成一位年有八旬的老婆婆来到师徒四人的面前是,除悟空外,其他三人都认为是来寻女儿的,担心又害怕。但悟空认定这位老婆婆是妖精,靠的不是火眼金睛,而是他的聪明。他对大家说:那女子十八岁,这老妇有八十,怎么六十多岁还生产?断乎是个假的……便上前,取棒照头便打。在过火焰山时,更发生了有趣的事情——孙悟空三调芭蕉扇。一调,铁扇公主不借,无空又敌不过芭蕉扇,他便智区取,借来定风丹,真是悟空用了定风丹,任凭那铁扇扇,的确借到了扇子,不料却借来了把假扇子,把火焰山的火月扇越大,就只好再借;二调,悟空化作牛魔王,铁扇身边骗走扇;三调,大圣唤来众神仙,牛魔吓得便交扇……
合上书,悟空的聪明、悟空的勇敢,悟空那种敢于斗争的精神早已经镌刻在我的心里,其实他不就是我们的学习榜样吗?我们因该像悟空那样棉队困难时,不害怕,不退缩,即使对方很强大,也不能畏惧,都要坚持,都要战胜到底,永不放弃!
uml心得体会
在学习UML这门课之前,我一直心底有一个疑问,那就是我们和那些所谓的程序员速成班培训出来的程序员到底有什么差别,都是写代码,那我们在大学里学习的意义是什么呢,直到我学习了UML这门课。我才知道写代码并没有想象中的那么简单,对于同一个功能,肯定有着多种不同的实现方法,而这些方法也肯定有优劣之分。我们之所以不像外面那样的培训班一样速成,是因为我们需要锻炼自己去写出高质量的代码,我觉得这就是我们学习的意义。
其实在上UML课之前,我以为UML跟C++和java一样是一门编程语言,直到经过老师的介绍,我才知道UML的全称是Unified Modeling Language,他不同于C++,java这些编程语言,他是统一建模语言。UML是一种用于可视化描述系统,具有广泛用途的建模语言。作为一种标准化的图形语言,在软件工业中被用于软件系统部件的具体化,可视化,结构化描述以及撰写文档,同样在商业模型中也得到应用。
UML虽然不是一门程序设计语言,但他的重要性是不可忽视的。他的重要性主要体现在:使复杂的软件设计更为简单,也能够实现像OOP(面向对象编程)这一类被广泛应用的概念;用理解起来可能更容易的图来描述,避免了大量的文字;使表达和交流概念或系统结构变得更容易;在一张图中就能够描绘出整个系统;程序员实用类图来描述实际需求时,可让问题更加清晰明了,实现起来更容易。
很多人或许会说直接写代码要比画图分析什么的快多了,但我认为UML在分析和设计阶段十分重要。在学完职责分配原则和了解过一些设计模式过后,我更加坚定了我的想法。或许对于一个小项目来说,实现的方式有很多种,无论是哪一种,可能会有人觉得只要能够实现功能就是可用的,就是好的。但如果是一个比较庞大的项目呢?如果在具体写代码时某个类的职责过于庞杂,那么必定会给系统带来很大的压力。或者说每个类之间的关系特别复杂,那么当后续需要更改某个类的时候,必定会影响到其他的类,带来十分高昂的维护成本。而GRASP的九个原则:信息专家原则,创造者原则,低耦合原则,高内聚原则,控制器原则,多态原则,纯虚构,中介原则,受保护变量原则可以在一点程度上很有效地解决这些问题。
UML这门课程让我学会了话UML的五大类,共九种图:
用例图:从用户角度描述系统功能,并指出各功能的操作者。
静态图:包括类图和对象图。类图描述系统中类的静态结构,不仅定义系统中的类,表示类之间的联系,如关联、依赖、聚合等,也包括类的属性和操作,类图描述的是一种静态关系,在系统的整个生命周期都是有效的。对象图是类图的实例,几乎使用与类图完全相同的标识。一个对象图是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统某一时间段存在。
行为图:描述系统的动态模型和组成对象间的交互关系,包括状态图和活动图。状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件,状态图是对类图的补充,活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并进行活动。
交互图:描述对象间的交互关系,包括时序图和协作图。时序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;协作图描述对象间的协作关系,协作图跟时序图相似,显示对象间的动态合作关系。除显示信息交换外,协作图还显示对象以及它们之间的关系。如果强调时间和顺序,则使用时序图;如果强调上下级关系,则选择协作图。
实现图:包括组件图和部署图。组件图描述代码部件的物理结构及各部件之间的依赖关系,组件图有助于分析和理解部件之间的相互影响程度;部署图定义系统中软硬件的物理体系结构。
UML也同时让我自己去了解了统一过程,这部分老师并没有详细地讲,我自己查阅资料了解了一些。RUP中的软件生命周期在时间上被分解为四个顺序的阶段,分别是:初始阶段、细化阶段、构造阶段和交付阶段。每个阶段结束于一个主要的里程碑。每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话,可以允许项目进入下一个阶段。
说实话在了解GRASP,设计模式,统一过程后,我觉得UML是一门十分重要的课。但是我在知乎上看到了一个“UML现在有什么用?”的问题,上面的许多高赞答案都是在说UML的用处并不大。甚至有人说UML是糊弄人的东西。但我却不这么认为,判断知识有没有不能仅凭这自己以前的经历,或许有些人用UML的地方并不多,所以他认为UML的用处并不大,但是谁又能肯定的说你以后不会用到UML的建模方法和思想呢?我觉得我们学习的眼光应该长远一点。不管如何,我在UML结课后,仍然会继续学习UML,因为我认为他是十分有用的,虽然目前为止我并没有过参与大型项目的经历,但确实在UML建模后,我对一些问题和业务逻辑有了更深刻的认识,我相信他能帮助我提升我自己的能力,加油!