UML实验心得体会

合集下载

uml学习心得体会

uml学习心得体会

uml学习心得体会篇一:UmL学习心得耿庆博UmL学习心得(一)UmL(UnifiedmodelingLanguage,统一建模语言)是一组用于描述ooad过程的图形化表达方式。

UmL为交流面向对象的设计中的需求,行为、体系结构的实现提供了一套综合的表示法。

(二)UmL由9个不同类型的图组成:用例图:显示了系统的外部可视行为。

用例图描述了系统外的人员和系统的交互动作,以及系统的响应,该类型的图可以用于描述系统的功能需求。

活动图:显示系统行为的峡谷纳西描述。

活动图描述了单个功能需求内部的细节行为,包括基本的场景和一些可选的场景。

组件图:显示了系统的体系结构。

组件图描述了系统的可部署单元(可执行文件,组件,数据存储和其他一些内容)以及一些借口,可部署单元通过这些接口进行交互,该图可以用于研究系统的体系结构。

顺序图:显示了对象随着时间的交互。

顺序图描述了某个功能需求的路径或场景内相对时间的详细行为,该图可用于理解系统元素之间的消息流程。

协作图:显示了对象的交互,强调对象之间的关系。

(在UmL2.0里面找不到了)类图:显示了类的定义和关系。

类图描述了系统设计中的类和接口,以及他们之间的关系。

该图可用于定义内部的,面向对象的代码结构。

状态图:显示了响应时间的状态改变。

状态图描述了系统如何改变状态以相应内部的和外部的事件,确保每个事件都被适当的处理。

部署图:显示了系统的物理体系结构。

部署图描述了系统的可部署单元(应用,组件,数据存储等)如何被赋予不同的节点,这些节点如何交互通信,用于系统映射和负载的研究。

包图:显示了设计的层次结构。

包图描述了设计的相关元素如何按组结合在一起,以及他们之间的关系。

(三)各种图的作用1.用例图(Usecasediagram)它是UmL中最简单也是最复杂的一种图。

说它简单是因为它采用了面向对象的思想,又是基于用户视角的,绘制非常容易,简单的图形表示让人一看就懂。

说它复杂是因为用例图往往不容易控制,要么过于复杂,要么过于简单。

uml实验心得体会_0

uml实验心得体会_0

uml实验心得体会篇一:UmL实训总结实训总结(收获与体会)通过一个学期的Uml学习,我从书本上获取了基本的理论知识,而真正的学以致用,将书本理论知识运用到实际的过程,是这次UmL 实训的体现。

三个周的UmL实训,主要是围绕着一个实训题目“基于UmL系统需求分析与设计--合倍利业务流管理系统”进行的,以小组为单位进行文档的编写,其中还对各种流程图、类图、用例图等的绘制,整个过程设计了知识的方方面面。

从中让我认识到UmL的作用和运作模式以及方法,它是一种统一建模的标准语言,现在对于大多数软件开发来说,都使用Uml作为建模语言,形成了统一的标准。

它是图形化的的语言,可以很直观的描述一个事物的状态、行为与特征,很好的说明与表达了“合贝利任务管理”这个系统。

总之,在我看来,UmL是一种定义良好、易于表达、功能强大且普遍适用建模语言。

融入软件工程领域的心思想、新方法和新技术,作用域不限于支持面向对象的分析和设计,也不单纯是一种方法,仅仅是一组符号而已,它可以对任何具有静态机构和动态行为的系统进行建模,所以我很喜欢适用UmL,在今后的学习中,我还会进一步对该模型的学习,因为它方便、简洁、干净、清爽,直观形象,把整个软件系统的开发流程都融入进去。

这次实训过程中,文档方面的编写,遇到了很多的问题,这些问题主要是对基础知识的理解和把握不够,不能融会贯通和学以致用,有时遇到困难的时候真的不知如何着手解决,但是,我始终相信的那句话“读万卷书,不如行万里路,行万里路不如名师指路”。

所以,当遇到自己模糊和自己难以解决的问题时,向指导老师和懂的同学请教,帮助解决我遇到的问题,经过他们的讲解后,我下来自己在分析,在动手,从不理解到理解,从不会到会,从懂到懂,这是一个让我学习愉快的过程,在这个过程中,既可以丰富了自己的知识,还可以和老师和同学进行有效地方沟通。

在这次实训过程中,感触最深的也就是合作精神了。

独木难成林,单枪匹马,那是最错误的思想和做法。

uml心得体会4篇最新汇总

uml心得体会4篇最新汇总

uml心得体会4篇最新汇总UML是统一建模语言(UnifiedModelingLanguage)的缩写,它发表于1997年,是一个支持模型化和软件系统开发的图形化语言,为软件开发的所有阶段提供模型化和可视化支持。

”下面给大家带来一些关于uml心得体会,希望对大家有所帮助。

uml心得体会1作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分。

l UML语义:描述基于UML的精确元模型定义。

l UML表示法:定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。

这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。

标准建模语言UML可以由下列5类图来定义。

用例图:从用户角度描述系统功能,并指出各功能的操作者。

静态图:包括类图和对象图。

类图描述系统中类的静态结构,不仅定义系统中的类,表示类之间的联系,如关联、依赖、聚合等,也包括类的属性和操作,类图描述的是一种静态关系,在系统的整个生命周期都是有效的。

对象图是类图的实例,几乎使用与类图完全相同的标识。

一个对象图是类图的一个实例。

由于对象存在生命周期,因此对象图只能在系统某一时间段存在。

行为图:描述系统的动态模型和组成对象间的交互关系,包括状态图和活动图。

状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件,状态图是对类图的补充,活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并进行活动。

交互图:描述对象间的交互关系,包括时序图和协作图。

时序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;协作图描述对象间的协作关系,协作图跟时序图相似,显示对象间的动态合作关系。

除显示信息交换外,协作图还显示对象以及它们之间的关系。

如果强调时间和顺序,则使用时序图;如果强调上下级关系,则选择协作图。

实现图:包括组件图和部署图。

组件图描述代码部件的物理结构及各部件之间的依赖关系,组件图有助于分析和理解部件之间的相互影响程度;部署图定义系统中软硬件的物理体系结构。

uml实训总结(范本)

uml实训总结(范本)

uml实训总结um‎l实训总结‎篇一:‎UML实训‎总结实训总结(收获‎与体会)通过一个学‎期的Uml学习,我从‎书本上获取了基本的理‎论知识,而真正的学以‎致用,将书本理论知识‎运用到实际的过程,是‎这次UML实训的体现‎。

三个周的UML 实‎训,主要是围绕着一个‎实训题目“基于UML‎系统需求分析与设计-‎-合倍利业务流管理系‎统”进行的,以小组为‎单位进行文档的编写,‎其中还对各种流程图、‎类图、用例图等的绘制‎,整个过程设计了知识‎的方方面面。

从中让我‎认识到UML的作用和‎运作模式以及方法,它‎是一种统一建模的标准‎语言,现在对于大多数‎软件开发来说,都使用‎U ml作为建模语言,‎形成了统一的标准。

它‎是图形化的的语言,可‎以很直观的描述一个事‎物的状态、行为与特征‎,很好的说明与表达了‎“合贝利任务管理”这‎个系统。

总之,在我‎看来,UML是一种定‎义良好、易于表达、功‎能强大且普遍适用建模‎语言。

融入软件工程领‎域的心思想、新方法和‎新技术,作用域不限于‎支持面向对象的分析和‎设计,也不单纯是一种‎方法,仅仅是一组符号‎而已,它可以对任何具‎有静态机构和动态行为‎的系统进行建模,所以‎我很喜欢适用UML,‎在今后的学习中,我还‎会进一步对该模型的学‎习,因为它方便、简洁‎、干净、清爽,直观形‎象,把整个软件系统的‎开发流程都融入进去。

‎这次实训过程中,文‎档方面的编写,遇到了‎很多的问题,这些问题‎主要是对基础知识的理‎解和把握不够,不能融‎会贯通和学以致用,有‎时遇到困难的时候真的‎不知如何着手解决,但‎是,我始终相信的那句‎话“读万卷书,不如行‎万里路,行万里路不如‎名师指路”。

所以,当‎遇到自己模糊和自己难‎以解决的问题时,向指‎导老师和懂的同学请教‎,帮助解决我遇到的问‎题,经过他们的讲解后‎,我下来自己在分析,‎在动手,从不理解到理‎解,从不会到会,从懂‎到懂,这是一个让我学‎习愉快的过程,在这个‎过程中,既可以丰富了‎自己的知识,还可以和‎老师和同学进行有效地‎方沟通。

uml建模心得体会.doc

uml建模心得体会.doc

uml建模心得体会篇一:UmL学习心得耿庆博UmL学习心得(一)UmL(UnifiedmodelingLanguage,统一建模语言)是一组用于描述ooAd过程的图形化表达方式。

UmL为交流面向对象的设计中的需求,行为、体系结构的实现提供了一套综合的表示法。

(二)UmL由9个不同类型的图组成:用例图:显示了系统的外部可视行为。

用例图描述了系统外的人员和系统的交互动作,以及系统的响应,该类型的图可以用于描述系统的功能需求。

活动图:显示系统行为的峡谷纳西描述。

活动图描述了单个功能需求内部的细节行为,包括基本的场景和一些可选的场景。

组件图:显示了系统的体系结构。

组件图描述了系统的可部署单元(可执行文件,组件,数据存储和其他一些内容)以及一些借口,可部署单元通过这些接口进行交互,该图可以用于研究系统的体系结构。

顺序图:显示了对象随着时间的交互。

顺序图描述了某个功能需求的路径或场景内相对时间的详细行为,该图可用于理解系统元素之间的消息流程。

协作图:显示了对象的交互,强调对象之间的关系。

(在UmL2.0里面找不到了)类图:显示了类的定义和关系。

类图描述了系统设计中的类和接口,以及他们之间的关系。

该图可用于定义内部的,面向对象的代码结构。

状态图:显示了响应时间的状态改变。

状态图描述了系统如何改变状态以相应内部的和外部的事件,确保每个事件都被适当的处理。

部署图:显示了系统的物理体系结构。

部署图描述了系统的可部署单元(应用,组件,数据存储等)如何被赋予不同的节点,这些节点如何交互通信,用于系统映射和负载的研究。

包图:显示了设计的层次结构。

包图描述了设计的相关元素如何按组结合在一起,以及他们之间的关系。

(三)各种图的作用1.用例图(Usecasediagram)它是UmL中最简单也是最复杂的一种图。

说它简单是因为它采用了面向对象的思想,又是基于用户视角的,绘制非常容易,简单的图形表示让人一看就懂。

说它复杂是因为用例图往往不容易控制,要么过于复杂,要么过于简单。

UML学习心得体会

UML学习心得体会

UML学习心得体会第一篇:UML学习心得体会——uml学习体会养成良好的绘制uml序列图的习惯在学习uml的过程中,你可能会遇到绘制uml序列图的问题,这里就讨论一下怎样才能养成良好的绘制uml序列图的习惯。

有一些方法可以帮助您提高uml序列图的质量和效力。

它们包括:和主题问题专家一起验证决策;使解决方案尽量简单;为绘制消息和返回值选择一种一致且有效的风格;将序列图分层;遵循一致的逻辑风格;牢记序列图是动态的。

一:验证决策绘制uml序列图时,我做了一些对其它模型可能有潜在影响的决策。

例如,在对第10步建模时,假设(大致上是个设计决策)费用显示屏幕同时也处理学生对费用是否可接受所进行的验证。

该决策应该由用户界面原型反映出来,并由主题问题专家(sme)进行验证。

您应该和sme(特别是那些对于如何开发类似模型有着深刻见解的富有经验的人)一起执行序列图的绘制工作。

二:保持简单在对第2和第3步建模时,我忽然意识到学生可能应该使用口令进入系统。

在向sme提出了这个概念后发觉我错了:姓名和学号组合对于我们的目的来说已经足够唯一,并且学校也不希望增加复杂的口令管理。

这是个很有意思的决策,因为这是学校的一个运作策略,所以可以作为一条商业规则记载到增补规范中。

通过与sme一起检验这个想法,而不是假定我比他们知道得更多,我避免了“镀金”的机会,因而减少了我们小组开发这一系统所需的工作。

三:绘制消息和返回值绘制uml序列图时我更喜欢从左至右地绘制消息,从右至左地绘制返回值,尽管这样对于复杂的对象/类来说不总是非常合适。

我将消息上的标签和返回值对齐到离箭头最近的位置。

我不喜欢在序列图上标出返回值,为的是使图尽可能地简化。

不过,始终标出返回值也同样有效,特别是在序列图用于设计而不是分析目的时。

(我希望我的分析图尽量简单,而设计图尽量全面。

)在分析期间,我的目标是理解逻辑和确保逻辑的正确性。

而在设计期间,则要赋予消息精确的细节。

uml心得体会4篇最新汇总

uml心得体会4篇最新汇总

uml心得体会4篇最新汇总UML是统一建模语言(UnifiedModelingLanguage)的缩写,它发表于1997年,是一个支持模型化和软件系统开发的图形化语言,为软件开发的所有阶段提供模型化和可视化支持。

”下面给大家带来一些关于uml心得体会,希望对大家有所帮助。

uml心得体会1作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分。

l UML语义:描述基于UML的精确元模型定义。

l UML表示法:定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。

这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。

标准建模语言UML可以由下列5类图来定义。

用例图:从用户角度描述系统功能,并指出各功能的操作者。

静态图:包括类图和对象图。

类图描述系统中类的静态结构,不仅定义系统中的类,表示类之间的联系,如关联、依赖、聚合等,也包括类的属性和操作,类图描述的是一种静态关系,在系统的整个生命周期都是有效的。

对象图是类图的实例,几乎使用与类图完全相同的标识。

一个对象图是类图的一个实例。

由于对象存在生命周期,因此对象图只能在系统某一时间段存在。

行为图:描述系统的动态模型和组成对象间的交互关系,包括状态图和活动图。

状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件,状态图是对类图的补充,活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并进行活动。

交互图:描述对象间的交互关系,包括时序图和协作图。

时序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;协作图描述对象间的协作关系,协作图跟时序图相似,显示对象间的动态合作关系。

除显示信息交换外,协作图还显示对象以及它们之间的关系。

如果强调时间和顺序,则使用时序图;如果强调上下级关系,则选择协作图。

实现图:包括组件图和部署图。

组件图描述代码部件的物理结构及各部件之间的依赖关系,组件图有助于分析和理解部件之间的相互影响程度;部署图定义系统中软硬件的物理体系结构。

uml实训总结

uml实训总结

uml‎实训总‎结u‎m l实‎训总结‎‎‎‎‎篇一:‎‎ U‎M L实‎训总结‎实训‎总结(‎收获与‎体会)‎通过‎一个学‎期的U‎m l学‎习,我‎从书本‎上获取‎了基本‎的理论‎知识,‎而真正‎的学以‎致用,‎将书本‎理论知‎识运用‎到实际‎的过程‎,是这‎次UM‎L实训‎的体现‎。

三‎个周的‎U ML‎实训,‎主要是‎围绕着‎一个实‎训题目‎“基于‎U ML‎系统需‎求分析‎与设计‎--合‎倍利业‎务流管‎理系统‎”进行‎的,以‎小组为‎单位进‎行文档‎的编写‎,其中‎还对各‎种流程‎图、类‎图、用‎例图等‎的绘制‎,整个‎过程设‎计了知‎识的方‎方面面‎。

从中‎让我认‎识到U‎M L的‎作用和‎运作模‎式以及‎方法,‎它是一‎种统一‎建模的‎标准语‎言,现‎在对于‎大多数‎软件开‎发来说‎,都使‎用Um‎l 作为‎建模语‎言,形‎成了统‎一的标‎准。

它‎是图形‎化的的‎语言,‎可以很‎直观的‎描述一‎个事物‎的状态‎、行为‎与特征‎,很好‎的说明‎与表达‎了“合‎贝利任‎务管理‎”这个‎系统。

‎总之‎,在我‎看来,‎U ML‎是一种‎定义良‎好、易‎于表达‎、功能‎强大且‎普遍适‎用建模‎语言。

‎融入软‎件工程‎领域的‎心思想‎、新方‎法和新‎技术,‎作用域‎不限于‎支持面‎向对象‎的分析‎和设计‎,也不‎单纯是‎一种方‎法,仅‎仅是一‎组符号‎而已,‎它可以‎对任何‎具有静‎态机构‎和动态‎行为的‎系统进‎行建模‎,所以‎我很喜‎欢适用‎U ML‎,在今‎后的学‎习中,‎我还会‎进一步‎对该模‎型的学‎习,因‎为它方‎便、简‎洁、干‎净、清‎爽,直‎观形象‎,把整‎个软件‎系统的‎开发流‎程都融‎入进去‎。

这‎次实训‎过程中‎,文档‎方面的‎编写,‎遇到了‎很多的‎问题,‎这些问‎题主要‎是对基‎础知识‎的理解‎和把握‎不够,‎不能融‎会贯通‎和学以‎致用,‎有时遇‎到困难‎的时候‎真的不‎知如何‎着手解‎决,但‎是,我‎始终相‎信的那‎句话“‎读万卷‎书,不‎如行万‎里路,‎行万里‎路不如‎名师指‎路”。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

uml实验报告学院班级学号姓名uml实验报告实验一:用例图实验结果:小结实验心得体会:用例模型用于需求分析阶段,它描述了待开发系统的功能需求,并驱动了需求分析之后各阶段的开发工作。

用例图是uml中用来对系统的动态方面进行建模的7种图之一。

用例图描述了用例、参与者以及它们之间的关系。

用例图从用户角度描述系统功能,并指出各功能的操作者。

通过本次实验,我熟悉rational rose建模环境,更加清楚的了解了用例图的语义和功能,如何清晰明了的识别参与者、用例,学会了如何使用事件流描述用例。

同时掌握了用例间的类属关系、include关系和extend关系的语义、功能和应用。

最后通过本次实验学习了如何使用用例图为系统的上下文以及系统的需求建模。

思考题:1. 如果要删除参与者、用例,请问是在导航窗口删除,还是在绘图窗口删除?答:都可以删除,但在绘图窗口中有两种删除方式:一种是只删除参与者、用例,而不改变其在导航窗口中的存在,另一种是从建模中完全删除。

2. 如果要删除参与者和用例的联系,用例和用例的联系,请问是在绘图中删除,还是在参与者或用例的设置对话框中删除?答:都可以删除。

实验二:类对象模型的建立实验结果:小结实验心得体会:类图是面向对象系统建模最常用的图,描述了类图、接口集、协作以及它们之间的关系。

类图描述了系统的静态设计视,该视主要体现系统的功能需求,即系统应该提供给用户的服务。

通过本次实验,加深了我对类图语义的理解和功能的应用,掌握了类之间的联系,关联、依赖、聚合等,同时基本掌握了在rational rose中绘制类的关联、依赖、泛化关系。

思考题:选中一个模型对象,点击鼠标右键,比较快捷菜单项“edit——delete”与“edit——delete from model”,它们二者之间区别在哪里?答:“edit——delete”只是在绘图窗口中删除了模型对象,而“edit——delete frommodel”则是彻底的删除了模型对象。

实验三:顺序图、协作图实验结果:顺序图:1.归还图书2.借出图书协作图:1. 归还图书2. 借出图书小结实验心得体会:顺序图描述了对象之间的动态合作关系,它强调对象之间消息发送的时间顺序,同时显示对象之间的交互。

协作图与顺序图是同构的,rose可自动转换。

顺序图是强调消息的交互作用图,协作图描述了对象间的关系,是强调发送和接收消息的对象的组织结构的交互作用图。

通过本次实验,掌握了对图书管理功能中的借书用例、还书用例进行动态建模。

实验过程中由于对rational rose工具软件的不熟识,导致出现了不该出现的错误。

在设计阶段,顺序图中需要引入边界类和控制类,在识别对象职责的基础上,需要将消息转换为类的方法,为方法定义参数、返回值类型,便于计算机的实现。

其中,为方法定义参数、返回值类型的时候,还是不能够快速准确的作出判断。

实验四:活动图实验结果:篇二:uml实验总结实验一1.源代码生成,在逻辑视图中绘制下图,生成java源文件生成代码步骤:“tools”-〉“java”-〉“genenate codes”。

public class meeting {private string username;private string scheduled_user; private date start_time; private dateend_time; private string label; public string getuser() { return null; }public string getother() { return null; }public date getstart() {return null; }public date getend() { return null; }public string getlabel() { return null; }public string tostring() { return null; }public void main(string args) { return null; } }2.进行逆向工程,自行找到一个项目软件源代码,进行逆向工程。

(ftp上有一个小源程序文件)逆向工程的实现“tools”->“java”-〉“reverse engineer java…”。

public class student { private string name; public student() { } public void test() { } } 实验二根据下属需求,分析参与者和用例,并建立网络教学系统的用例图。

网络教学系统的功能需求主要包括以下几个方面:①学生可以登录网站浏览信息、查找信息和下载文件。

②教师可以登录网站输入课程简介、上传课件文件、发布消息、修改和更新消息。

③系统管理员可以对页面维护以及批准用户的注册申请。

录入课程简介下载文件查找信息修改消息注册信息处理实验三1、已知借书的活动图如图3所示,若要求欠费的读者需结清欠款才能借书,请完善该活动图,并在rose内绘制出来。

图3 借书处理活动图2、图4为图书“借书”活动图,文字描述此活动图包括哪些活动,活动按照怎样的顺序发生?图4 “借书处理”活动图(1)读者查找所需的图书,若找到图书,将所需的图书带到借阅台;(2)工作人员输入读者信息,检查读者身份是否合法,如果读者身份合法,进入(3);(3)录入图书信息,并检查图书是否允许借阅,如果允许,则记录借阅信息,否则直接进入(4);(4)检查是否还有图书需要录入,如果还需录入,进入(3),否则提借阅信息。

3、绘制“删除读者信息”用例的活动图。

删除读者信息一般按照以下步骤进行:(1)管理员在录入界面,输入待删除的读者名;(2)“业务逻辑”组件在数据库中,查找待删除的读者名;(3)如果不存在,则显示出错信息,返回步骤(1),如果存在则继续;(4)“业务逻辑”组件判断“待删除的读者”是否可以删除;(5)如果不可以,则显示出错信息,返回步骤(8),如果可以则继续;(6)在数据库中,删除相关信息;(7)显示删除成功信息;(8)结束。

篇三:uml实训总结实训总结(收获与体会)通过一个学期的uml学习,我从书本上获取了基本的理论知识,而真正的学以致用,将书本理论知识运用到实际的过程,是这次uml实训的体现。

三个周的uml实训,主要是围绕着一个实训题目“基于uml系统需求分析与设计--合倍利业务流管理系统”进行的,以小组为单位进行文档的编写,其中还对各种流程图、类图、用例图等的绘制,整个过程设计了知识的方方面面。

从中让我认识到uml的作用和运作模式以及方法,它是一种统一建模的标准语言,现在对于大多数软件开发来说,都使用uml作为建模语言,形成了统一的标准。

它是图形化的的语言,可以很直观的描述一个事物的状态、行为与特征,很好的说明与表达了“合贝利任务管理”这个系统。

总之,在我看来,uml是一种定义良好、易于表达、功能强大且普遍适用建模语言。

融入软件工程领域的心思想、新方法和新技术,作用域不限于支持面向对象的分析和设计,也不单纯是一种方法,仅仅是一组符号而已,它可以对任何具有静态机构和动态行为的系统进行建模,所以我很喜欢适用uml,在今后的学习中,我还会进一步对该模型的学习,因为它方便、简洁、干净、清爽,直观形象,把整个软件系统的开发流程都融入进去。

这次实训过程中,文档方面的编写,遇到了很多的问题,这些问题主要是对基础知识的理解和把握不够,不能融会贯通和学以致用,有时遇到困难的时候真的不知如何着手解决,但是,我始终相信的那句话“读万卷书,不如行万里路,行万里路不如名师指路”。

所以,当遇到自己模糊和自己难以解决的问题时,向指导老师和懂的同学请教,帮助解决我遇到的问题,经过他们的讲解后,我下来自己在分析,在动手,从不理解到理解,从不会到会,从懂到懂,这是一个让我学习愉快的过程,在这个过程中,既可以丰富了自己的知识,还可以和老师和同学进行有效地方沟通。

在这次实训过程中,感触最深的也就是合作精神了。

独木难成林,单枪匹马,那是最错误的思想和做法。

这次我是深有感触了。

对于一个系统的分析,到最终项目的完成,需要分析每个文档,然后在写出纸质的文档,而在每个文档中,内容比较多,分析也要求比较到位,所以单独凭借一个人去完成,似乎有点困难,于是我们小组,将每个文档进行分析,能独立成块就分配给每一个人,这样,每个人都有自己的任务,谁也不会闲着,既学到了知识,也充实了自己。

另外一点,就是我深深体会到了积累知识的重要性。

在实训当中我们遇到了不少难题,但是经过我们大家的讨论和老师细心的一一指导,问题得到了解决。

两个月的实训结束了,收获颇丰,同时也更深刻的认识到要做一个合格的程序员并非我以前想像的那么容易,最重要的还是细致严谨。

社会是不会要一个一无是处的人的,所以我们要更多更快地从一个学生向工作者转变,总的来说我对这次实习还是比较满意的,它使我学到了很多东西,为我以后的学习做了引导,点明了方向。

实训的日子即将结束,回想这一个过程,有过痛苦,有过烦恼,有过喜悦和有过成功。

痛苦烦恼的是自己对所学书本知识掌握得不是很扎实,面对着从书本上学到的知识与实际联系不起来,总结起来就是自己的动手练习的时间太少。

而喜悦的是,在做的过程中遇到了困难和问题,主动向老师和会的同学请教,然后再做,直至做正确做成功后的那种喜悦。

团队的力量是无穷的,通过组员的共同努力,完成了实训项目。

虽然,我们这组的项目存在着诸多的不足和缺点,但这正是以后学习和工作需要弥补的。

这次实训将为我以后进入社会提过了一笔宝贵的财富,是对我能力的一个见证。

最后,不得不感谢指导教师熊飞老师的辛勤指导,和小组成员的共同努力!篇四:uml实验报告学生实验报告书实验课程名称uml建模技术开课学院指导老师姓名学生姓名学生专业班级2009 — 2010学年第一学期实验课程名称: uml建模技术实验课程名称:uml建模技术篇五:uml实验——状态图实验报告南京信息工程大学实验(实习)报告实验名称状态图实验(实习)日期 2014.04.26 得分指导老师系专业班级一、实验目的1.熟悉活动图的基本功能和使用方法。

2.掌握如何使用建模工具绘制活动图方法。

二、实验器材1.计算机一台。

2.rational rose 工具软件。

三、实验内容通过前面内容的学习,完成了对图书馆的图书馆管理系统的需求的初步分析,得出系统的用例图和相应的活动态。

通过这两类图我们可以初步了解系统的业务处理过程,但对业务处理过程的处理状态间转换了解仍不够,这不利于设计人员对系统业务的进一步理解,而状态图能从对象的动态行为的角度去描述系统的业务活动。

相关文档
最新文档