uml实验心得体会docWord文档下载推荐.docx
《uml实验心得体会docWord文档下载推荐.docx》由会员分享，可在线阅读，更多相关《uml实验心得体会docWord文档下载推荐.docx（9页珍藏版）》请在冰豆网上搜索。
实验二：
类对象模型的成立
小结实验心得体会：
类图是面向对象系统建模最经常使用的图，描述了类图、接口集、协作和它们之间的关系。
类图描述了系统的静态设计视，该视要紧表现系统的功能需求，即系统应该提供给用户的服务。
通过本次实验，加深了我对类图语义的明白得和功能的应用，把握了类之间的联系，关联、依托、聚合等，同时大体把握了在RationalRose中绘制类的关联、依托、泛化关系。
选中一个模型对象，点击鼠标右键，比较快捷菜单项“Edit——Delete”与“Edit——DeletefromModel”，它们二者之间区别在哪里？
“Edit——Delete”只是在画图窗口中删除模型对象，而“Edit——DeletefromModel”那么是完全的删除模型对象。
实验三：
顺序图、协作图
顺序图：
归还图书
2.借出图书
协作图：
1.归还图书
2.借出图书
小结实验心得体会：
顺序图描述了对象之间的动态合作关系，它强调对象之间消息发送的时刻顺序，同时显示对象之间的交互。
协作图与顺序图是同构的，Rose可自动转换。
顺序图是强调消息的交互作用图，协作图描述了对象间的关系，是强调发送和接收消息的对象的组织结构的交互作用图。
通过本次实验，把握了对图书治理功能中的借书用例、还书用例进行动态建模。
实验进程中由于对Rational
Rose工具软件的不熟识，致使显现了不该显现的错误。
在设计时期，顺序图中需要引入边界类和操纵类，在识别对象职责的基础上，需要将消息转换为类的方式，为方式概念参数、返回值类型，便于运算机的实现。
其中，为方式概念参数、返回值类型的时候，仍是不能够快速准确的作出判定。
实验四：
活动图
实验一
1．源代码生成，在逻辑视图中绘制以下图，生成JAVA源文件生成代码步骤：
“Tools”-〉“Java”-〉“GenenateCodes”。
publicclassMeeting{
privateStringUserName;
privateStringScheduled_User;
privateDateStart_Time;
privateDateEnd_Time;
privateStringLabel;
publicStringgetUser（） {
returnnull;
}
publicStringgetOther（） {
publicDategetStart（）
{
publicDategetEnd（） {
publicStringgetLabel（） {
publicStringtoString（） {
publicVoidmain（Stringargs） {
}}
2．进行逆向工程，自行找到一个项目软件源代码，进行逆向工程。
逆向工程的实现
“Tools”->
“Java”-〉“ReverseEngineerJava…”。
publicclassStudent{
privateStringname;
publicStudent（） { }
publicvoidtest（） { }}
实验二
依照下属需求，分析参与者和用例，并成立网络教学系统的用例图。
网络教学系统的功能需求要紧包括以下几个方面：
①学生能够登录网站阅读信息、查找信息和下载文件。
②教师能够登录网站输入课程简介、上传课件文件、发布消息、修改和更新消息。
③系统治理员能够对页面保护和批准用户的注册申请。
录入课程简介
下载文件
查找信息
修改消息
注册信息处置
实验三
一、已知借书的活动图如图3所示，假设要求欠费的读者需结清欠款才能借书，请完善该活动图，并在Rose内绘制出来。
图3借书处置活动图
二、图4为图书“借书”活动图，文字描述此活动图包括哪些活动，活动依照如何的顺序发生？
图4“借书处置”活动图
读者查找所需的图书，假设找到图书，将所需的图书带到借阅台；
工作人员输入读者信息，检查读者身份是不是合法，若是读者身份合法，
进入；
录入图书信息，并检查图书是不是许诺借阅，若是许诺，那么记录借阅信
息，不然直接进入；
检查是不是还有图书需要录入，若是还需录入，进入，不然提借阅信息。
3、绘制“删除读者信息”用例的活动图。
删除读者信息一样依照以下步骤进行：
治理员在录入界面，输入待删除的读者名；
“业务逻辑”组件在数据库中，查找待删除的读者名；
若是不存在，那么显示犯错信息，返回步骤，若是存在那么继续；
“业务逻辑”组件判定“待删除的读者”是不是能够删除；
若是不能够，那么显示犯错信息，返回步骤，若是能够那么继续；
在数据库中，删除相关信息；
显示删除成功信息；
终止。
实训总结
通过一个学期的Uml学习，我从书本上获取了大体的理论知识，而真正的学以致用，将书本理论知识运用到实际的进程，是这次UML实训的表现。
三个周的UML实训，主若是围绕着一个实训题目“基于UML系统需求分析与设计--合倍利业务流治理系统”进行的，以小组为单位进行文档的编写，其中还对各类流程图、类图、用例图等的绘制，整个进程设计了知识的方方面面。
从中让我熟悉到UML的作用和运作模式和方式，它是一种统一建模的标准语言，此刻关于大多数软件开发来讲，都利用Uml作为建模语言，形成了统一的标准。
它是图形化的的语言，能够很直观的描述一个事物的状态、行为与特点，专门好的说明与表达了“合贝利任务治理”那个系统。
总之，在我眼里，UML是一种概念良好、易于表达、功能壮大且普遍适用建模语言。
融入软件工程领域的心思想、新方式和新技术，作用域不限于支持面向对象的分析和设计，也不单纯是一种方式，仅仅是一组符号罢了，它能够对任何具有静态机构和动态行为的系统进行建模，因此我很喜爱适用UML，在尔后的学习中，我还会进一步对该模型的学习，因为它方便、简练、干净、清爽，直观形象，把整个软件系统的开发流程都融入进去。
这次实训进程中，文档方面的编写，碰到了很多的问题，这些问题主若是对基础知识的明白得和把握不够，不能融会贯通和学以致用，有时碰到困难的时候真的不知如何着手解决，可是，我始终相信的那句话“读万卷书，不如行万里路，行万里路不如名师指路”。
因此，当碰到自己模糊和自己难以解决的问题时，向指导教师和懂的同窗请教，帮忙解决我碰到的问题，通过他们的讲解后，我下来自己在分析，在动手，从不睬解到明白得，从可不能到会，从懂到懂，这是一个让我学习愉快的进程，在那个进程中，既能够丰硕了自己的知识，还能够和教师和同窗进行有效地址沟通。
在这次实训进程中，感触最深的也确实是合作精神了。
独木难成林，单枪匹马，那是最错误的思想和做法。
这次我是深有感触了。
关于一个系统的分析，到最终项目的完成，需要分析每一个文档，然后在写出纸质的文档，而在每一个文档中，内容比较多，分析也要求比较到位，因此单独凭借一个人去完成，似乎有点困难，
于是咱们小组，将每一个文档进行分析，能独立成块就分派给每一个人，如此，每一个人都有自己的任务，谁也可不能闲着，既学到了知识，也充实了自己。
另外一点，确实是我深深体会到了积存知识的重要性。
在实训当中咱们碰到了很多难题，可是通过咱们大伙儿的讨论和教师细心的一一指导，问题取得了解决。
两个月的实训终止了，收成颇丰，同时也更深刻的熟悉到要做一个合格的程序员并非我以前想像的那么容易，最重要的仍是细致严谨。
社会是可不能要一个一无是处的人的，因此咱们要更多更快地从一个学生向工作者转变，总的来讲我对这次实习仍是比较中意的，它使我学到了很多东西，为我以后的学习做了引导，点明了方向。
实训的日子即将终止，回忆这一个进程，有过痛楚，有过苦恼，有过喜悦和有过成功。
痛楚苦恼的是自己对所学书本知识把握得不是很扎实，面对着从书本上学到的知识与实际联系不起来，总结起来确实是自己的动手练习的时刻太少。
而喜悦的是，在做的进程中碰到了困难和问题，主动向教师和会的同窗请教，然后再做，直至做正确做成功后的那种喜悦。
团队的力量是无穷的，通过组员的一起尽力，完成了实训项目。
尽管，咱们这组的项目存在着诸多的不足和缺点，但这正是以后学习和工作需要弥补的。
这次实训将为我以后进入社会提过了一笔宝贵的财富，是对我能力的一个见证。
最后，不能不感激指导教师熊飞教师的辛勤指导，和小组成员的一起尽力！
学生实验报告书
实验课程名称 UML建模技术 开课学院 指导教师姓名 学生姓名 学生专业班级
XX—XX学年第一学期
实验课程名称：
UML建模技术
实验课程名称：
UML学习心得
（一）UML是一组用于描述OOAD进程的图形化表达方式。
UML为交流面向对象的设计中的需求，行为、体系结构的实现提供了一套综合的表示法。
（二）UML由9个不同类型的图组成：
用例图：
显示了系统的外部可视行为。
用例图描述了系统外的人员和系统的交互动作，和系统的响应，该类型的图能够用于描述系统的功能需求。
活动图：
显示系统行为的峡谷纳西描述。
活动图描述了单个功能需求内部的细节行为，包括大体的场景和一些可选的场景。
组件图：
显示了系统的体系结构。
组件图描述了系统的可部署单元和一些借口，可部署单元通过这些接口进行交互，该图能够用于研究系统的体系结构。
显示了对象随着时刻的交互。
顺序图描述了某个功能需求的途径或场景内相对时刻的详细行为，该图可用于明白得系统元素之间的消息流程。
协作图：
显示了对象的交互，强调对象之间的关系。
类图：
显示了类的概念和关系。
类图描述了系统设计中的类和接口，和他们之间的关系。
该图可用于概念内部的，面向对象的代码结构。
状态图：
显示了响应时刻的状态改变。
状态图描述了系统如何改变状态以相应内部的和外部的事件，确保每一个事件都被适当的处置。
部署图：
显示了系统的物理体系结构。
部署图描述了系统的可部署单元如何被给予不同的节点，这些节点如何交互通信，用于系统映射和负载的研究。
包图：
显示了设计的层次结构。
包图描述了设计的相关元素如何按组结合在一路，和他们之间的关系。
（三）各类图的作用
1.用例图
它是UML中最简单也是最复杂的一种图。
说它简单是因为它采纳了面向对象的思想，又是基于用户视角的，绘制超级容易，简单的图形表示让人一看就懂。
说它复杂是因为用例图往往不容易操纵，要么过于复杂，要么过于简单。
用例图表示了角色和用例和它们之间的关系。
2.类图
UML面向对象中是最经常使用的一种图，类图能够帮忙咱们更直观的了解一个系统的体系结构。
通过关系和类表示的类图，能够图形化的方式描述一个系统的设计部份。
3.对象图
UML面向对象中对象图是类图的实例，几乎利用与类图完全相同的标识。
它们的不同点在于对象图显示类的多个对象实例，而不是实例的类。
一个对象图是类图的一个实例。
由于对象存在生命周期，因此对象图只能在系统某一时刻段存在。
4.状态图
描述一个实体基于事件反映的动态行为，显示了该实体如何依照当前所处的状态对不同的时刻做出反映的。
通常创建一个UML状态图是为了以下的研究目的：
研究类、角色、子系统、或组件的复杂行为。
5.时序图
又称顺序图，描述了对象之间动态的交互关系，着重表现对象间消息传递的时刻顺序。
顺序图由一组对象组成，每一个对象别离带有一条竖线，称作对象的生命线，它代表时刻轴，时刻沿竖线向下延伸。
UML面向对象中顺序图描述了这些对象随着时刻的推移彼此之间互换消息的进程。
消息用从一务垂直的对象生命线指向另一个对象的生命线的水平箭头表示。
图中还能够依照需要增加有关时刻的说明和其他注释。
6.协作图
UML面向对象中协作图用于显示组件及其交互关系的空间组织结构，它并非偏重于交互的顺序。
协作图显示了交互中各个对象之间的组织交互关系和对象彼此之间的链接。
与序列图不同，协作图显示的是对象之间的关系。
另一方面，协作图没有将时刻作为一个单独的维度，因此序列号就决定了消息及并发线程的顺序。
协作图是一个介于符号图和序列图之间的交叉产物，它用带有编号的箭头来描述特定的方案，以显示在整个方案进程中消息的移动情形。
协作图用途：
通过刻画对象之间消息的移动情形来反映具体的方案。
显示对象及其交互关系的空间组织结构，而非交互的顺序。
7.活动图
UML面向对象中UML活动图记录了单个操作或方式的逻辑，单个用户案例，或单个业务流程的逻辑。
描述系统中各类活动的执行顺序，通经常使用于描述一个操作中所要进行的各项活动的执行流程。
同时，它也常被用来描述一个用例的处置流程，或某种交互流程。
活动图由一些活动组成，图中同时包括了对这些活动的说明。
当一个活动执行完毕以后，操纵将沿着操纵转移箭头转向下一个活动。
活动图中还能够方便地描述操纵转移的条件和并行执行等要求。
8.组件图
组件图是用来反映代码的物理结构。
从组件图中，能够了解各软件组件之间的编译器和运行时依托关系。
利用组件图能够将系统划分为内聚组件并显示代码自身的结构。
组件图的要紧目的是显示系统组件间的结构关系。
9.配置图
UML面向对象中配置图描述系统中硬件和软件的物理配置情形和系统体系结构。
在配置图中，用结点表示实际的物理设备，如运算机和各类外部设备等，并依照它们之间的连接关系，将相应的结点连接起来，并说明其连接方式。
在结点里面，说明分派给该结点上运行的可执行构件或对象，从而说明哪些软件单元被分派在哪些结点上运行。
UML是一种软件建模语言，能够对任何具有静态结构和动态行为的系统进行建模。
在关注它建模特性的同时更要关注它的进程特性--在什么时刻做什么工作，用什么模型，让哪些人来做。
对系统用户而言，软件的开发模型向他们描述了软件开发者对软件系统需求的
明白得。
让系统用户查看软件对象模型而且找到其中的问题，能够使开发者不至于从一开始就发生错误。
对软件开发而言，软件的对象模型有助于他们对软件的需求和系统的架构和功能进行沟通。
对软件的保护和技术支持者而言，在软件系统开始运行后的相当长的一段时刻内，软件的对象模型能够帮忙他们明白得程序的架构和功能，迅速地对软件所显现的问题进行修复。
建模并非是仅对大型的软件系统，乃至一个小型的留言本也能从建模的进程中受益。
利用UML能够有效地解决软件设计和分析进程中的沟通和交流问题，能够高效的了解整个系统结构，而且在设计之初就将软件的设计结构和思想固化在纸上有利于规避项目实施进程中程序员离开的风险。
UML能够贯穿软件开发周期中的没一个时期，在开发时期，他能够用于说明、可视化、构建和书写面向对象软件制品的设计语言。
UML能贯穿整个软件开发进程是因为在每一个时期都能够提供相应相应的图形来对应，使得改变需求，设计代码，测试分析能变得相对简单。
在需求分析进程中，应该分为两个进程：
1需求的获取
二、需求的分析。
需求的获取，往往不受到重视，在网上常常看到有人说，专门是国内目前的情形，项目工期紧，公司往往想方设法先把项目拿下来，然后就拿自己公司以往做过的项目做蓝本，然后再依照顾客的需求改动，再次开发，测试，交付就完工了。
但如果是需求的获取，做不行，往往对后面的步骤流程造成专门大的阻碍，造成太多的改动和损失。
因此为了取得更好的需求，利用UML建模能变得相对简单。
例如需求的用例图对系统的功能模型的搭建。
用例间的关系有包括、扩展、泛化三类。
用例图包括角色、用例和关系。
角色能够有角色的描述，用例能够有效例的描述，这些描述在交流或评审中会超级有效。
用例能够泛化，泛化用例具有大体用例的功能，还能够做得更多。
角色也能够泛化，泛化角色能执行原角色能执行的所有效例，还能够执行更多的用例。
除大体用例，角色不能与包括用例、扩展用例和泛化用例有联系。
一个用例能够对应一个类图。
增、删、改、查一样来讲关于大多数应用做为一个简单的操作即可，没必要要作为一个用例来分析。
升级会员 