uml心得体会
第1篇：UML实验心得体会
uml实验报告
学院
班级 学号 姓名
uml实验报告
实验一：用例图
实验结果：
小结实验心得体会：
用例模型用于需求分析阶段，它描述了待开发系统的功能需求，并驱动了需求分析之后各阶段的开发工作。用例图是uml中用来对系统的动态方面进行建模的7种图之一。用例图描述了用例、参与者以及它们之间的关系。用例图从用户角度描述系统功能，并指出各功能的操作者。通过本次实验，我熟悉rational rose建模环境，更加清楚的了解了用例图的语义和功能，如何清晰明了的识别参与者、用例，学会了如何使用事件流描述用例。同时掌握了用例间的类属关系、include关系和extend关系的语义、功能和应用。最后通过本次实验学习了如何使用用例图为系统的上下文以及系统的需求建模。
思考题：
1.如果要删除参与者、用例，请问是在导航窗口删除，还是在绘图窗口删除？
答：都可以删除，但在绘图窗口中有两种删除方式：一种是只删除参与者、用例，而不改变 其在导航窗口中的存在，另一种是从建模中完全删除。
2.如果要删除参与者和用例的联系，用例和用例的联系，请问是在绘图中删除，还是 在参与者或用例的设置对话框中删除？
答：都可以删除。
实验二：类对象模型的建立
实验结果：
小结实验心得体会：
类图是面向对象系统建模最常用的图，描述了类图、接口集、协作以及它们之间的关系。类图描述了系统的静态设计视，该视主要体现系统的功能需求，即系统应该提供给用户的服
务。通过本次实验，加深了我对类图语义的理解和功能的应用，掌握了类之间的联系，关联、依赖、聚合等，同时基本掌握了在rational rose中绘制类的关联、依赖、泛化关系。
思考题：选中一个模型对象，点击鼠标右键，比较快捷菜单项“edit——delete”与“edit——delete from model”，它们二者之间区别在哪里？
答：“edit——delete”只是在绘图窗口中删除了模型对象，而“edit——delete from model”则是彻底的删除了模型对象。
实验三：顺序图、协作图
实验结果：
顺序图：
1.归还图书
2.借出图书
协作图：
1.归还图书
2.借出图书
小结实验心得体会：
顺序图描述了对象之间的动态合作关系，它强调对象之间消息发送的时间顺序，同时显示对象之间的交互。协作图与顺序图是同构的，rose可自动转换。顺序图是强调消息的交互作用图，协作图描述了对象间的关系，是强调发送和接收消息的对象的组织结构的交互作用图。通过本次实验，掌握了对图书管理功能中的借书用例、还书用例进行动态建模。实验过程中由于对rational rose工具软件的不熟识，导致出现了不该出现的错误。在设计阶段，顺序图中需要引入边界类和控制类，在识别对象职责的基础上，需要将消息转换为类的方法，为方法定义参数、返回值类型，便于计算机的实现。其中，为方法定义参数、返回值类型的时候，还是不能够快速准确的作出判断。
实验四：活动图
实验结果：
篇2：uml实验总结
实验一
1．源代码生成，在逻辑视图中绘制下图，生成java源文件 生成代码步骤：
“tools”-〉“java”-〉“genenate codes”。
public cla meeting { private string username;private string scheduled_user;private date start_time;private date end_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 cla 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）结束。
篇3：uml实训总结
实训总结（收获与体会）
通过一个学期的uml学习，我从书本上获取了基本的理论知识，而真正的学以致用，将书本理论知识运用到实际的过程，是这次uml实训的体现。
三个周的uml实训，主要是围绕着一个实训题目“基于uml系统需求分析与设计--合倍利业务流管理系统”进行的，以小组为单位进行文档的编写，其中还对各种流程图、类图、用例图等的绘制，整个过程设计了知识的方方面面。从中让我认识到uml的作用和运作模式以及方法，它是一种统一建模的标准语言，现在对于大多数软件开发来说，都使用uml作为建模语言，形成了统一的标准。它是图形化的的语言，可以很直观的描述一个事物的状态、行为与特征，很好的说明与表达了“合贝利任务管理”这个系统。
总之，在我看来，uml是一种定义良好、易于表达、功能强大且普遍适用建模语言。融入软件工程领域的心思想、新方法和新技术，作用域不限于支持面向对象的分析和设计，也不单纯是一种方法，仅仅是一组符号而已，它可以对任何具有静态机构和动态行为的系统进行建模，所以我很喜欢适用uml，在今后的学习中，我还会进一步对该模型的学习，因为它方便、简洁、干净、清爽，直观形象，把整个软件系统的开发流程都融入进去。
这次实训过程中，文档方面的编写，遇到了很多的问题，这些问题主要是对基础知识的理解和把握不够，不能融会贯通和学以致用，有时遇到困难的时候真的不知如何着手解决，但是，我始终相信的那句话“读万卷书，不如行万里路，行万里路不如名师指路”。所以，当遇到自己模糊和自己难以解决的问题时，向指导老师和懂的同学请教，帮助解决我遇到的问题，经过他们的讲解后，我下来自己在分析，在动手，从不理解到理解，从不会到会，从懂到懂，这是一个让我学习愉快的过程，在这个过程中，既可以丰富了自己的知识，还可以和老师和同学进行有效地方沟通。
在这次实训过程中，感触最深的也就是合作精神了。独木难成林，单枪匹马，那是最错误的思想和做法。这次我是深有感触了。对于一个系统的分析，到最终项目的完成，需要分析每个文档，然后在写出纸质的文档，而在每个文档中，内容比较多，分析也要求比较到位，所以单独凭借一个人去完成，似乎有点困难，于是我们小组，将每个文档进行分析，能独立成块就分配给每一个人，这样，每个人都有自己的任务，谁也不会闲着，既学到了知识，也充实了自己。另外一点，就是我深深体会到了积累知识的重要性。在实训当中我们遇到了不少难题，但是经过我们大家的讨论和老师细心的一一指导，问题得到了解决。两个月的实训结束了，收获颇丰，同时也更深刻的认识到要做一个合格的程序员并非我以前想像的那么容易，最重要的还是细致严谨。社会是不会要一个一无是处的人的，所以我们要更多更快地从一个学生向工作者转变，总的来说我对这次实习还是比较满意的，它使我学到了很多东西，为我以后的学习做了引导，点明了方向。
实训的日子即将结束，回想这一个过程，有过痛苦，有过烦恼，有过喜悦和有过成功。痛苦烦恼的是自己对所学书本知识掌握得不是很扎实，面对着从书本上学到的知识与实际联系不起来，总结起来就是自己的动手练习的时间太少。而喜悦的是，在做的过程中遇到了困难和问题，主动向老师和会的同学请教，然后再做，直至做正确做成功后的那种喜悦。
团队的力量是无穷的，通过组员的共同努力，完成了实训项目。虽然，我们这组的项目存在着诸多的不足和缺点，但这正是以后学习和工作需要弥补的。这次实训将为我以后进入社会提过了一笔宝贵的财富，是对我能力的一个见证。最后，不得不感谢指导教师熊飞老师的辛勤指导，和小组成员的共同努力！篇4：uml实验报告
学 生 实 验 报 告 书
实验课程名称
uml建模技术
开 课 学 院
指导老师姓名
学 生 姓 名
学生专业班级
2009—2010学年 第 一 学期
实验课程名称： uml建模技术
实验课程名称：
uml建模技术
篇5：uml实验——状态图 实验报告
南京信息工程大学实验(实习)报告
实验名称 状态图 实验(实习)日期 2014.04.26 得分 指导老师
系专业 班级
一、实验目的1．熟悉活动图的基本功能和使用方法。
2．掌握如何使用建模工具绘制活动图方法。
二、实验器材
1．计算机一台。
2．rational rose 工具软件。
三、实验内容
通过前面内容的学习，完成了对图书馆的图书馆管理系统的需求的初步分析，得出系统的用例图和相应的活动态。通过这两类图我们可以初步了解系统的业务处理过程，但对业务处理过程的处理状态间转换了解仍不够，这不利于设计人员对系统业务的进一步理解，而状态图能从对象的动态行为的角度去描述系统的业务活动。因此，指派你运用本节所学的状态图，完成如下任务：
1.完成图书业务模块中还书用例的状态图。
四、实验步骤 1．业务分析：由前面章节对图书馆管理系统中的还书主要业务的描述和分析可知，还书业务的动态行为是由：空闲（idle）、图书查找（finding）、还书（reversion）、失败（failure）、归还成功（succe）5种状态及激活相互转换的事件。
2．绘制状态图：请您根据分析运用uml绘制还书用例的状态图。
分析：
还书的状态图，还书的主要业务都是由管理员来完成，首先管理员必须先登录系统，并通过验证后，便可以进行下一步的操作，查找该书的相关信息，如存在，则进行还书操作，如不存在该信息，则给出提示信息；
绘图步骤：
（1）在用例图中的还书（revesion）用例，单击右键，如图3.1所示，新建一个状态图，命名为revesion状态图。
（2）双击“receivesion”状态图，展开后，在左边的工具栏上选取一个实心圆点，此结点为开始结点；当还书的时候，操作者先要询问系统的状态，如果系统忙，操作者则必需等待，因此，得到系统的两种状态。
（3）操作者在询问系统和状态后，得到两种状态，如果系统忙，操作者必需要等待、结束，重返步骤（1）。
（4）如系统空闲，则进行对还书的信息进行查询操作；查询也有两种结果，一是查询得到该书的相关信息，二查询不到该书的相关信息；则此时有两种状态，需要建立两种状态。
（5）最后，操作者进行了操作后，系统会给出操作的结果给操作者；操作成功或失败，都会有提示信息给出。整个的还书的过程便完成。
（7）根据分析设计情况，进一步添加或细化状态图。
五、实验报告要求
1．整理实验结果。
2．小结实验心得体会。
通过本次试验学习到了项目中状态图的绘制，了解了他们之间的关系以及关系处理的方法，熟悉了对rational rose 工具软件的使用，在以后做软件项目设计有很大的帮助。
第2篇：UML学习心得体会
——uml学习体会
养成良好的绘制uml序列图的习惯 在学习uml的过程中，你可能会遇到绘制uml序列图的问题，这里就讨论一下怎样才能养成良好的绘制uml序列图的习惯。
有一些方法可以帮助您提高uml序列图的质量和效力。它们包括：和主题问题专家一起验证决策；使解决方案尽量简单；为绘制消息和返回值选择一种一
致且有效的风格；将序列图分层；遵循一致的逻辑风格；牢记序列图是动态的。一：验证决策
绘制uml序列图时，我做了一些对其它模型可能有潜在影响的决策。例如，在对第10步建模时，假设（大致上是个设计决策）费用显示屏幕同时也处理学生对费用是否可接受所进行的验证。该决策应该由用户界面原型反映出来，并由主题问题专家(sme)进行验证。您应该和sme（特别是那些对于如何开发类似模型有着深刻见解的富有经验的人）一起执行序列图的绘制工作。
二：保持简单
在对第2和第3步建模时，我忽然意识到学生可能应该使用口令进入系统。在向sme提出了这个概念后发觉我错了：姓名和学号组合对于我们的目的来说已经足够唯一，并且学校也不希望增加复杂的口令管理。这是个很有意思的决策，因为这是学校的一个运作策略，所以可以作为一条商业规则记载到增补规范中。通过与sme一起检验这个想法，而不是假定我比他们知道得更多，我避免了“镀金”的机会，因而减少了我们小组开发这一系统所需的工作。
三：绘制消息和返回值
绘制uml序列图时我更喜欢从左至右地绘制消息，从右至左地绘制返回值，尽管这样对于复杂的对象／类来说不总是非常合适。我将消息上的标签和返回值对齐到离箭头最近的位置。我不喜欢在序列图上标出返回值，为的是使图尽可能地简化。不过，始终标出返回值也同样有效，特别是在序列图用于设计而不是分析目的时。（我希望我的分析图尽量简单，而设计图尽量全面。）在分析期间，我的目标是理解逻辑和确保逻辑的正确性。而在设计期间，则要赋予消息精确的细节。
四：将序列图分层 绘制uml序列图时我喜欢将序列图从左至右地分层。先标出参与者，然后是控制器类，然后是用户界面类，最后是商业类。在设计期间，可能需要添加系统类和持久类，我通常将它们放在序列图的最右侧。以这种方式将序列图分层往往使它们更易于阅读，并且更容易找出分层逻辑问题，例如用户界面类直接访问持久类。
五：遵循一致的逻辑风格
请注意，在图1序列图所示的过程中，逻辑风格做了部分更改。一开始，特别是在登录时，用户界面处理一些基本逻辑--而在选择研习班，以及稍后的验证时，则是控制器类进行处理。这实际上是个设计问题。我不会在这个问题上纠缠太久，但和往常一样，我建议选择一种适合于您的建模风格，然后始终如一地贯彻在所有序列图中。
六：牢记序列图是动态的绘制uml序列图时您可能听说过诸如动态建模和静态建模这样的术语，其他一些熟悉面向对象建模技术的开发人员常常会提到它们。您甚至可能听到过有关每种风格的优点的争论。动态建模技术主要集中在标识系统中的行为，包括序列图的绘制和活动图的绘制（请参阅“如何绘制uml活动图”）以及uml协作图的绘制。而静态建模则集中在系统的静态方面，包括类、它们的属性，以及类之间的关联。类模型和持久／数据模型一样，都是静态建模的主要产物。uml学习心得(一)uml（unified modeling language，统一建模语言）是一组用于描述ooad过程的图形化表达方式。uml为交流面向对象的设计中的需求，行为、体系结构的实现提供了一套综合的表示法。(二)uml由9个不同类型的图组成：
用例图：显示了系统的外部可视行为。
用例图描述了系统外的人员和系统的交互动作，以及系统的响应，该类型的图可以用于描述系统的功能需求。
活动图：显示系统行为的峡谷纳西描述。
活动图描述了单个功能需求内部的细节行为，包括基本的场景和一些可选的场景。
组件图：显示了系统的体系结构。
组件图描述了系统的可部署单元（可执行文件，组件，数据存储和其他一些内容）以及一些借口，可部署单元通过这些接口进行交互，该图可以用于研究系统的体系结构。
顺序图：显示了对象随着时间的交互。
顺序图描述了某个功能需求的路径或场景内相对时间的详细行为，该图可用于理解系统元素之间的消息流程。
协作图：显示了对象的交互，强调对象之间的关系。（在uml2.0里面找不到了）
类图：显示了类的定义和关系。
类图描述了系统设计中的类和接口，以及他们之间的关系。该图可用于定义内部的，面向对象的代码结构。
状态图：显示了响应时间的状态改变。
状态图描述了系统如何改变状态以相应内部的和外部的事件，确保每个事件都被适当的处理。
部署图：显示了系统的物理体系结构。
部署图描述了系统的可部署单元（应用，组件，数据存储等）如何被赋予不同的节点，这些节点如何交互通信，用于系统映射和负载的研究。
包图：显示了设计的层次结构。
包图描述了设计的相关元素如何按组结合在一起，以及他们之间的关系。(三)各种图的作用
1.用例图（usecasediagram）
它是uml中最简单也是最复杂的一种图。说它简单是因为它采用了面向对象的思想，又是基于用户视角的，绘制非常容易，简单的图形表示让人一看就懂。说它复杂是因为用例图往往不容易控制，要么过于复杂，要么过于简单。用例图表示了角色和用例以及它们之间的关系。
2.类图（cladiagram）uml面向对象中是最常用的一种图，类图可以帮助我们更直观的了解一个系统的体系结构。通过关系和类表示的类图，可以图形化的方式描述一个系统的设计部分。3.对象图 uml面向对象中对象图是类图的实例，几乎使用与类图完全相同的标识。它们的不同点在于对象图显示类的多个对象实例，而不是实例的类。一个对象图是类图的一个实例。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。4.状态图
描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。通常创建一个uml状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。5.时序图
又称顺序图，描述了对象之间动态的交互关系，着重体现对象间消息传递的时间顺序。顺序图由一组对象构成，每个对象分别带有一条竖线，称作对象的生命线，它代表时间轴，时间沿竖线向下延伸。uml面向对象中顺序图描述了这些对象随着时间 的推移相互之间交换消息的过程。消息用从一务垂直的对象生命线指向另一个对象的生命线的水平箭头表示。图中还可以根据需要增加有关时间的说明和其他注释。6.协作图 uml面向对象中协作图用于显示组件及其交互关系的空间组织结构，它并不侧重于交互的顺序。协作图显示了交互中各个对象之间的组织交互关系以及对象 彼此之间的链接。与序列图不同，协作图显示的是对象之间的关系。另一方面，协作图没有将时间作为一个单独的维度，因此序列号就决定了消息及并发线程的顺 序。协作图是一个介于符号图和序列图之间的交叉产物，它用带有编号的箭头来描述特定的方案，以显示在整个方案过程中消息的移动情况。
协作图用途：
通过描绘对象之间消息的移动情况来反映具体的方案。
显示对象及其交互关系的空间组织结构，而非交互的顺序。7.活动图（activitydiagram）uml面向对象中uml活动图记录了单个操作或方法的逻辑，单个用户案例，或者单个业务流程的逻辑。描述系统中各种活动的执行顺序，通常用于描述一个操作中所要进行的各项活动的执行流程。同时，它也常被用来描述一个用例的处理流程，或者某种交互流程。
活动图由一些活动组成，图中同时包括了对这些活动的说明。当一个活动执行完毕之后，控制将沿着控制转移箭头转向下一个活动。活动图中还可以方便地描述控制转移的条件以及并行执行等要求。
组件图是用来反映代码的物理结构。从组件图中，可以了解各软件组件（如源代码文件或动态链接库）之间的编译器和运行时依赖关系。使用组件图可以将系统划分为内聚组件并显示代码自身的结构。
组件图的主要目的是显示系统组件间的结构关系。9.配置图
uml面向对象中配置图描述系统中硬件和软件的物理配置情况和系统体系结构。
在配置图中，用结点表示实际的物理设备，如计算机和各种外部设备等，并根据它们之间的连接关系，将相应的结点连接起来，并说明其连接方式。在结点里面，说明分配给该结点上运行的可执行构件或对象，从而说明哪些软件单元被分配在哪些结点上运行。uml是一种软件建模语言，可以对任何具有静态结构和动态行为的系统进行建模。在关注它建模特性的同时更要关注它的过程特性--在什么时间做什么工作，用什么模型，让哪些人来做。对系统用户而言，软件的开发模型向他们描述了软件开发者对软件系统需求的理解。让系统用户查看软件对象模型并且找到其中的问题，可以使开发者不至于从一开始就发生错误。对软件开发而言，软件的对象模型有助于他们对软件的需求以及系统的架构和功能进行沟通。对软件的维护和技术支持者而言，在软件系统开始运行后的相当长的一段时间内，软件的对象模型能够帮助他们理解程序的架构和功能，迅速地对软件所出现的问题进行修复。建模并不是仅对大型的软件系统，甚至一个小型的留言本也能从建模的过程中受益。利用uml可以有效地解决软件设计和分析过程中的沟通和交流问题，可以高效的了解整个系统结构，并且在设计之初就将软件的设计结构和思想固化在纸上有利于规避项目实施 过程中程序员离开的风险。uml可以贯穿软件开发周期中的没一个阶段，在开发阶段，他可以用于说明、可视化、构建和书写面向对象软件制品的设计语言。uml能贯穿整个软件开发过程是因为在每个阶段都能够提供相应相应的图形来对应，使得改变需求，设计代码，测试分析能变得相对简单。在需求分析过程中，应该分为两个过程：1 需求的获取
2、需求的分析。需求的获取，往往不受到重视，在网上经常看到有人说，特别是国内目前的情况，项目工期紧，公司往往想方设法先把项目拿下来，然后就拿自己公司 以往做过的项目做蓝本，然后再根据顾客的需求改动，再次开发，测试，交付就完工了。但如果需求的获取，做不好，往往对后面的步骤流程造成很大的影响，造成 太多的改动和损失。所以为了得到更好的需求，使用uml建模能变得相对简单。例如需求的用例图对系统的功能模型的搭建。用例间的关系有包含、扩展、泛化三类。用例图包括角色、用例和关 系。角色可以有角色的描述，用例可以有用例的描述，这些描述在交流或评审中会非常有用。用例可以泛化，泛化用例具有基本用例的功能，还可以做得更多。角色 也可以泛化，泛化角色能执行原角色能执行的所有用例，还可以执行更多的用例。除了基本用例，角色不能与包含用例、扩展用例和泛化用例有联系。一个用例可以 对应一个类图。增、删、改、查一般来说对于大多数应用做为一个简单的操作即可，不必要作为一个用例来分析。篇三：uml实训总结 实训总结（收获与体会）
通过一个学期的uml学习，我从书本上获取了基本的理论知识，而真正的学以致用，将书本理论知识运用到实际的过程，是这次uml实训的体现。
三个周的uml实训，主要是围绕着一个实训题目“基于uml系统需求分析与设计--合倍利业务流管理系统”进行的，以小组为单位进行文档的编写，其中还对各种流程图、类图、用例图等的绘制，整个过程设计了知识的方方面面。从中让我认识到uml的作用和运作模式以及方法，它是一种统一建模的标准语言，现在对于大多数软件开发来说，都使用uml作为建模语言，形成了统一的标准。它是图形化的的语言，可以很直观的描述一个事物的状态、行为与特征，很好的说明与表达了“合贝利任务管理”这个系统。总之，在我看来，uml是一种定义良好、易于表达、功能强大且普遍适用建模语言。融入软件工程领域的心思想、新方法和新技术，作用域不限于支持面向对象的分析和设计，也不单纯是一种方法，仅仅是一组符号而已，它可以对任何具有静态机构和动态行为的系统进行建模，所以我很喜欢适用uml，在今后的学习中，我还会进一步对该模型的学习，因为它方便、简洁、干净、清爽，直观形象，把整个软件系统的开发流程都融入进去。
这次实训过程中，文档方面的编写，遇到了很多的问题，这些问题主要是对基础知识的理解和把握不够，不能融会贯通和学以致用，有时遇到困难的时候真的不知如何着手解决，但是，我始终相信的那句话“读万卷书，不如行万里路，行万里路不如名师指路”。所以，当遇到自己模糊和自己难以解决的问题时，向指导老师和懂的同学请教，帮助解决我遇到的问题，经过他们的讲解后，我下来自己在分析，在动手，从不理解到理解，从不会到会，从懂到懂，这是一个让我学习愉快的过程，在这个过程中，既可以丰富了自己的知识，还可以和老师和同学进行有效地方沟通。
在这次实训过程中，感触最深的也就是合作精神了。独木难成林，单枪匹马，那是最错误的思想和做法。这次我是深有感触了。对于一个系统的分析，到最终项目的完成，需要分析每个文档，然后在写出纸质的文档，而在每个文档中，内容比较多，分析也要求比较到位，所以单独凭借一个人去完成，似乎有点困难，于是我们小组，将每个文档进行分析，能独立成块就分配给每一个人，这样，每个人都有自己的任务，谁也不会闲着，既学到了知识，也充实了自己。另外一点，就是我深深体会到了积累知识的重要性。在实训当中我们遇到了不少难题，但是经过我们大家的讨论和老师细心的一一指导，问题得到了解决。两个月的实训结束了，收获颇丰，同时也更深刻的认识到要做一个合格的程序员并非我以前想像的那么容易，最重要的还是细致严谨。社会是不会要一个一无是处的人的，所以我们要更多更快地从一个学生向工作者转变，总的来说我对这次实习还是比较满意的，它使我学到了很多东西，为我以后的学习做了引导，点明了方向。实训的日子即将结束，回想这一个过程，有过痛苦，有过烦恼，有过喜悦和有过成功。痛苦烦恼的是自己对所学书本知识掌握得不是很扎实，面对着从书本上学到的知识与实际联系不起来，总结起来就是自己的动手练习的时间太少。而喜悦的是，在做的过程中遇到了困难和问题，主动向老师和会的同学请教，然后再做，直至做正确做成功后的那种喜悦。
团队的力量是无穷的，通过组员的共同努力，完成了实训项目。虽然，我们这组的项目存在着诸多的不足和缺点，但这正是以后学习和工作需要弥补的。这次实训将为我以后进入社会提过了一笔宝贵的财富，是对我能力的一个见证。最后，不得不感谢指导教师熊飞老师的辛勤指导，和小组成员的共同努力！篇四：uml课设心得
六月23号至六月27号，是我们班进行uml专用周课程设计的时间，虽然时间并不是很长，只有短短的一个星期而已，但是让我受益匪浅，通过这次的uml课程设计，使我所学的书本知识得到了全面的检验，也让我对这门课程有了更加深厚的体会。
这次课程设计我们没有另外选题，而是在我们之前做过的系统之上加以完善和改进。现在看看之前提交的作品，确实不近人意；但经过在网上的不断查找资料，终于还是将它完成。之前我做的系统状态图和活动图，为了锻炼自己这次选择了交互图（也就是时序图和协作图）。虽然说自己没有这方面的经验，也不是特别熟悉其工作流程，但是有了在网上 查找资料得来的一些基础和课本里的讲解，自己对它也有了一定初步的认识，虽然不是很全面，但还是跌跌撞撞的完成。其中还因为和组员没有沟通好导致用的类不同，费了好大劲才改回来。
最后，这次课设使我们发现考试真的并不是最重要，最重要的是能运用所学的知识。在整个uml课程的学习过程中，我们突破了传统学习模式，把被动接受转变为主动学习。不再是用学到的知识解题，而是在实际运用时遇到什么学什么，重在把知识应用于实际。立体的运用比死板的模仿更有效也更容易接受。下学期就大四了，也就是大学校园里的最后一年，而课设里学到的动手能力和分析问题解决问题的能力也将是我们毕业找工作的一大筹码。篇五：uml学习重点汇总
第一章 oom&软件建模概述 uml（unified modeling language）
通用的标准建模语言,可以对任何具有静态结构和动态行为的系统进行建模。标准建模语言uml适用于以面向对象技术来描述任何类型的系统,而且适用于系统开发的不同阶段,从需求规格描述直至系统完成后的测试和维护。
特点：统一标准，面向对象，可视化、表达能力强，独立于过程，uml很适合于以体系结构中心的、用例驱动的、迭代式和渐增式的软件开发过程 第二章 uml构成 1.uml的“4+1视图”
从某个角度观察系统构成系统的一个视图，每个
数据库
5活动图——泳道图
泳道将活动图中的活动化分为若干组，并把每一视图都是系统描述的一个投影，说明了系统某个侧面的特征。（1）用例视图（2）逻辑视图（3）组件视图（4）进程视图（并发视图）（5）配置视图（部署视图）2.uml的模型图：
模型图是一组uml模型元素构成的有向图表示，它通常由一组节点（uml基本模型元素）, 及节点之间的连线（关系）组成。(1)用例视图：用例图(2)静态模型：类图、对象图、包图、构件图和配置图(3)动态模型：活动图、顺序图、状态图和协作图 3.用例图.用例图是表达用例和参与者及其关系的载体。关系包括：关联关系，依赖关系 实现关系： 3.用例图(续)——用例之间关系1（包含与扩展）.3.用例图(续)——用例之间关系2（泛化）.3.用例图(续)——用例与参与者
用例use case：一组用例的实例（场景），其中每个实例都是系统执行的一系列活动，这些活动产生了对每个参与者而言可观察的返回值。描述了从参与者角度看系统做了什么
用例模型本身不是面向对象建模技术。
参与者actor: 是指在系统外部与系统交互的人或其他系统，以某种方式参与了系统内用例的执行。4.交互式视图图(顺序图、协作图)1）协作图：采用图的形式展示对象间的交互 2）顺序图：采用栅栏格式展示对象间的交互
顺序图与协作图的优缺点： 顺序图
（优点）强调消息的时间顺序及对象生命线（优点）大量详细表示法选项
（缺点）强制在右侧增加新对象，消耗空间大 协作图（优点）强调结构组织，复杂交互表达更容易（优点）空间利用率高，和方便添加新对象（缺点）不宜查询消息的顺序，表示法选项少 5 活动图
活动图用于表示完成一个操作所需要的活动，或者是一个用例实例（场景）的活动。活动图适合描述动作流和并发处理行为。5活动图——实例
组指定给负责这组活动的业务组织即对象。泳道区分了负责活动的对象，明确地表示了哪些活动是由哪些对象进行的。
每个活动只能明确地属于一个泳道。6 状态图（状态机）
状态图(state diagram)一个对象在其生存期间的动态行为，表现对象响应事件所经历的状态序列以及伴随的动作。并不是所有类都有相应的状态图。状态图只适用于：具有若干个确定状态，类的行为在这些状态下 会受到影响且被不同的状态改变。
状态图与活动图的区别与联系（1）相同的图形符号。
（2）描述一个系统或对象在生存周期的状态或行为。（3）描述系统或对象在多进程中同步或异步操作并发行为。
（4）用条件分支来描述系统或对象的行为控制流。联系：
（2）描述多个对象共同完成一个操作的机制不同。活动图置于责任区（泳道）中，责任区将活动按责任目标和组织归属的原则分类。状态图采用状态嵌套方式描述多
对象协作。
7、类图
类图表示系统中类及类和类之间的关系，用于对系统的静态结构进行描述。类用来表示系统中需要处理的事物.类的关系：
（1）关联：关联表示两个类的对象之间存在某种语义上的联系。
（2）聚集：聚集也称为聚合，关联的特例 聚集表示类与类之间的关系是整体与部分的关系。
（3）泛化：uml中的泛化关系就是通常所说的继承关系，它是通用元素和具体元素之间的一种分类关系。（4）依赖和细化。2)类的关系——关联
间具有细化关系。细化用来协调不同阶段模型之间的关系。
构件图由构件、接口及构件之间的关系组成。构件图主要用于系统的静态实现视图模型，通过构件的依赖关系描述系统软件的组织结构，展示系统不同物理构件及其关系。
系统业务模型：业务过程和文档。系统开发管理模型：开发期间产物及关系 系统实现模型：系统实现的构件建模
第六章 从需求到设计 包图（package diagram）概念性的模型管理工具，用于将大型的软件系统中大量的建模元素有序的组织起来。
运用包可以把语义上相近的可能一起变更的模型元素组织在同一个包中，对包中的元素作为一个整体对待，并 2)类的关系——聚集
聚集也称为聚合，是关联的特例。聚集表示类与类之间的关系是整体与部分的关系。
（1.共享聚集 聚合：聚集关系中处于部分方的对象可同时参与多个处于整体方对象的构成.（2.组合聚集.组合：部分类完全隶属于整体类.部分与整体共存.整体不存在部分也随之消失。2)类的关系——泛化 uml中的泛化关系就是通常所说的继承关系（或一般与特殊关系）。2)类的关系——依赖
两个类之间有依赖，表明其中一个类.客户类.依赖于另一个类（供应类）所提供的某些服务。2)类的关系——细化
当对同一个事物在不同抽象层次上描述时，这些描述之
系统物理配置模型：数据文件、日志、安装/卸载等文件且控制它们的可视性和存取。包拥有内容，包括类、接构件建模 口、组件、节点、协同。use case、图，甚至其它包。集成系统模型：对api建模，帮助利用已有组件。第三章 unified proce(1)构件: 系统中遵从并实现一组接口的物理的、可替换up的构成：二维的面向对象开发模型，兼顾技术和管理。的软件模块。构件是软件复用的基本物理实现单元，是工作流:过程工作流(业务建模+需求+分析与设计+实施+逻辑元素模型（类、接口、协同等）的物理包
测试+部署)和3个支持工作流（配置和变更管理+项目管理+环境）4个阶段：初始＋细化＋构造＋交付 up的迭代策略。
up的迭代开发策略:以体系结构为中心，以质量管理和
风险控制为目标，以用例为驱动，采用迭代式以螺旋上
升的模式进行软件开发。(2)构件的接口:一个构件可以定义对其他构件可见的接第四章 初始阶段(inception)口。构件间依赖通过指向所使用的构件接口来表示。接1.初始阶段的目标和任务：
口描述一个构件能提供服务的操作，是一个有操作而无做适当的调研，以形成对新系统的整体目的和可实现的类。包括输入和输出接口。
行性形成一个合理的意见。
建立项目的软件范围和边界条件，包括一个操作“前景”，“接受准则”和产品中包含什么，不包含什么„ 确定核心的用例，这是系统运行的主要场景，它将决定系统设计的方案
针对主要的场景，确定或者演示至少一个备选的系统结9 部署图（deployment diagram）
构
由节点和节点之间的联系组成，描述了处理器、设备和对整个项目估计总成本和计划(更详细的估计将安排在软件构件运行时的体系结构。
细化阶段中)估计可能的风险(不可预计性的来源）为项目准备支持环境 2.初始阶段的制品： 用例模型＋用例描述，词汇表，补充性规格说明，前景，业务规则 9 部署图——结点 3.用例描述
节点是存在于运行时的代表计算资源的物理元素，可摘要：简介描述用例，通常只给出主成功场景。以代表一种物理硬件设备或软件元素。非正式：用若干非正式段落来描述用例，通常给出多个包含：处理器和设备两种类型 不同场景。
详述：详细描述用例，通常给出所有的步骤及场景，并10 部署图——结点间联系
给出前置和后置条件等细节 节点间通过物理连接发生联系，以从硬件方面保证注意：用例描述的方法 系统各节点之间的协同运行。包括通讯关联、依赖联系4.用例的获取过程
等。(1)选择系统边界(2)寻找参与者(3)确定每个参与者的目标(4)定义用例 5.用例的定义:一般为每一个用户目标定义用例
确定用例的经验方法：
(1)老板测试：必须看到可量化的价值(2)ebp：能够增加可量化的业务价值，并且以持久状态留下数据(3)规模测试： 6.rup与用例
(1)意义：记录功能需求；迭代计划的重要部分，预算的关键输入；实现驱动设计；影响用户手册和测试(2)初始阶段：确定系统目标、范围、涉众；绝大部分摘要描述、10～20％详述；确定是否继续开发(3)细化阶段：80～90％被细化描述；分多次迭代(4)构造阶段：多次时间定量迭代；补充次要用例 第五章 细化阶段(elaboration)1.细化阶段的目标和任务: 8.系统顺序图
表述系统是什么，而不解释它是如何做的，将系统作为黑盒子 系统顺序图
它展示了对一个特定的用例，外部的参与者产生的事件，它们的顺序以及系统内的事件
协作与耦合从较高层到较低层进行，避免从较低层到较高层的耦合第七章 模式与对象设计 1 职责和职责驱动设计 类的契约和责任，分为：行为职责和认知职责。在对象设计中，职责被分配给对象，称为rdd。2 设计模式
设计模式：对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。即，对特定问题的描述或解决方案。
目的: 易于理解，维护，扩展和重用 3 grasp模式 控制器（controller），创建者（creator），信息专家 构建核心体系架构，解决高风险问题，完成绝大部分需求的定义，并估计并估计总体计划和资源，保证架构，需求和计划足够稳定，风险被充分规避，确定和解决项目中所有与架构密切相关的风险，从与架构密切相关的场景中确定一个基准体系架构，产生一个达到产品级质量水准的演化性原型，也可以是一个或更多个探索型抛弃型原型，能够展示基准的体系架构以合理的价格和合适的时间支持系统需求，建立一个支持环境 2.核心活动: 尽快定义和验证体系架构，并确定体系架构基线 细化设想（vision）为构造阶段建立详细的迭代计划并建立基线 细化开发用例并将其部署到开发环境中 细化体系架构并选择组件 3.关键思想和实践
实行短时间定量、风险驱动的迭代，及早开始编程，对架构核心和风险部分进行适应性设计，实现和测试，尽早，频繁，实际的测试，基于来自测试，用户，开发者的反馈进行调整，通过一系列讨论会，详细编写大部分用例和其他需求，每个细化迭代举行一次 4.制定迭代计划: 通过风险、覆盖范围和关键程度组织需求和迭代。
风险：技术复杂性；其他因素
覆盖性：在早期迭代中，系统中主要的部分都有所涉及 关键性：具有高业务价值的功能
在每个迭代前将用例和特征进行排序 迭代单位：(1)用例；(2)场景 5.细化阶段的制品: 领域模型，设计模型，软件架构文档，数据模型，用例示意板，用户界面模型 6.领域模型(domain model)领域模型是对真实世界中概念类的表示，而不是软件对象的表示。它不是用来描述软件类、软件架构领域层或有职责软件对象的一组图。
领域模型用一套类图表示，但类没有操作。领域模型可以显示：领域对象或者概念类；概念类之间的关联；概念类的属性
概念类来源：现实（组织、地点、设备等）对象；业务（业务实体和概念）对象；过程（需要记录的时间）对象。9.操作契约
通过领域模型中的对象的状态变换(实例创建或删除;属性修改;关联形成或者打破)，定义了系统操作执行后的详细的系统行为.契约co2: enteritem 操作 : enteritem(itemid: itemid, quantity: integer)前提（preconditions）: there is a sale underway 后置条件（postconditions）: 一个saleslineitem的实例sli被创建；sli与当前的 sale 对象相关联；sli.quantity的数值被赋值，依据itemid的匹配，sli 与productspecification相关联 第六章 从需求到设计 1.软件的逻辑体系结构
逻辑架构（logical architecture）是软件类的宏观组织结构，它将软件类组织成包（命名空间），子系统和层等。
层（layer）：对类、包或子系统的粗粒度的分组，具有对系统主要方面加以内聚的职责。较高的层可以调用较低的层。常见的层：
用户界，应用逻辑和领域对象，技术服务 典型的分层模式 2.软件架构
架构是一组重要决策，其中涉及软件系统的组织，对结构元素及其组成系统的接口的选择，这些元素特定于其相互协作的行为，这些结构和行为元素到规模更大的子系统的组成，以及指导该组织结构的架构风格。3.分层设计模式（模型-视图分离, 如mvc架构）系统的大型逻辑结构组织为独立的，职责相关的离散层，具有清晰内聚的关注分离。较低的层是低级别和一般性服务，较高的层则是与应用相关。（information expert），高度内聚（high cohesion），低耦合（low coupling）4 命令——查询分类原则
执行动作（更新、调整）的命令方法，这种方法通常具有改变对象状态等副作用，并且是 void 的（没有返回值）。向调用者返回数据的查询，这种方法没有副作用，不会永久性的改变任何对象的状态。一个方法不应该同时属于以上两种类型。
第3篇：UML实验心得体会
uml实验报告
学院
班级 学号 姓名
uml实验报告 实验一：用例图 实验结果： 小结实验心得体会：
用例模型用于需求分析阶段，它描述了待开发系统的功能需求，并驱动了需求分析之后各阶段的开发工作。用例图是uml中用来对系统的动态方面进行建模的7种图之一。用例图描述了用例、参与者以及它们之间的关系。用例图从用户角度描述系统功能，并指出各功能的操作者。通过本次实验，我熟悉rational rose建模环境，更加清楚的了解了用例图的语义和功能，如何清晰明了的识别参与者、用例，学会了如何使用事件流描述用例。同时掌握了用例间的类属关系、include关系和extend关系的语义、功能和应用。最后通过本次实验学习了如何使用用例图为系统的上下文以及系统的需求建模。
思考题：
1.如果要删除参与者、用例，请问是在导航窗口删除，还是在绘图窗口删除？ 答：都可以删除，但在绘图窗口中有两种删除方式：一种是只删除参与者、用例，而不改变 其在导航窗口中的存在，另一种是从建模中完全删除。
2.如果要删除参与者和用例的联系，用例和用例的联系，请问是在绘图中删除，还是
在参与者或用例的设置对话框中删除？ 答：都可以删除。实验二：类对象模型的建立 实验结果： 小结实验心得体会：
类图是面向对象系统建模最常用的图，描述了类图、接口集、协作以及它们之间的关系。类图描述了系统的静态设计视，该视主要体现系统的功能需求，即系统应该提供给用户的服 务。通过本次实验，加深了我对类图语义的理解和功能的应用，掌握了类之间的联系，关联、依赖、聚合等，同时基本掌握了在rational rose中绘制类的关联、依赖、泛化关系。
思考题：选中一个模型对象，点击鼠标右键，比较快捷菜单项“edit——delete”与“edit——delete from model”，它们二者之间区别在哪里？
答：“edit——delete”只是在绘图窗口中删除了模型对象，而“edit——delete from model”则是彻底的删除了模型对象。
实验三：顺序图、协作图
精选 实验结果： 顺序图： 1.归还图书 2.借出图书 协作图： 1.归还图书 2.借出图书 小结实验心得体会：
顺序图描述了对象之间的动态合作关系，它强调对象之间消息发送的时间顺序，同时显示对象之间的交互。协作图与顺序图是同构的，rose可自动转换。顺序图是强调消息的交互作用图，协作图描述了对象间的关系，是强调发送和接收消息的对象的组织结构的交互作用图。通过本次实验，掌握了对图书管理功能中的借书用例、还书用例进行动态建模。实验过程中由于对rational rose工具软件的不熟识，导致出现了不该出现的错误。在设计阶段，顺序图中需要引入边界类和控制类，在识别对象职责的基础上，需要将消息转换为类的方法，为方法定义参数、返回值类型，便于计算机的实现。其中，为方法定义参数、返回值类型的时候，还是不能够快速准确的作出判断。
实验四：活动图 篇2：uml实验总结
实验一
1．源代码生成，在逻辑视图中绘制下图，生成java源文件 生成代码步骤： “tools”-〉“java”-〉“genenate codes”。public cla meeting { private string username;private string scheduled_user;private date start_time;private date end_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 cla 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）在数据篇3：uml实训总结
实训总结（收获与体会）
通过一个学期的uml学习，我从书本上获取了基本的理论知识，而真正的学以致用，将书本理论知识运用到实际的过程，是这次uml实训的体现。
三个周的uml实训，主要是围绕着一个实训题目“基于uml系统需求分析与设计--合倍利业务流管理系统”进行的，以小组为单位进行文档的编写，其中还对各种流程图、类图、用例图等的绘制，整个过程设计了知识的方方面面。从中让我认识到uml的作用和运作模式以及方法，它是一种统一建模的标准语言，现在对于大多数软件开发来说，都使用uml作为建模语言，形成了统一的标准。它是图形化的的语言，可以很直观的描述一个事物的状态、行为与特征，很好的说明与表达了“合贝利任务管理”这个系统。
总之，在我看来，uml是一种定义良好、易于表达、功能强大且普遍适用建模语言。融入软件工程领域的心思想、新方法和新技术，作用域不限于支持面向对象的分析和设计，也不单纯是一种方法，仅仅是一组符号而已，它可以对任何具有静态机构和动态行为的系统进行建模，所以我很喜欢适用uml，在今后的学习中，我还会进一步对该模型的学习，因为它方便、简洁、干净、清爽，直观形象，把整个软件系统的开发流程都融入进去。
这次实训过程中，文档方面的编写，遇到了很多的问题，这些问题主要是对基础知识的理解和把握不够，不能融会贯通和学以致用，有时遇到困难的时候真的不知如何着手解决，但是，我始终相信的那句话“读万卷书，不如行万里路，行万里路不如名师指路”。所以，当遇到自己模糊和自己难以解决的问题时，向指导老师和懂的同学请教，帮助解决我遇到的问题，经过他们的讲解后，我下来自己在分析，在动手，从不理解到理解，从不会到会，从懂到懂，这是一个让我学习愉快的过程，在这个过程中，既可以丰富了自己的知识，还可以和老师和同学进行有效地方沟通。
在这次实训过程中，感触最深的也就是合作精神了。独木难成林，单枪匹马，那是最错误的思想和做法。这次我是深有感触了。对于一个系统的分析，到最终项目的完成，需要分析每个文档，然后在写出纸质的文档，而在每个文档中，内容比较多，分析也要求比较到位，所以单独凭借一个人去完成，似乎有点困难，于是我们小组，将每个文档进行分析，能独立成块就分配给每一个人，这样，每个人都有自己的任务，谁也不会闲着，既学到了知识，也充实了自己。另外一点，就是我深深体会到了积累知识的重要性。在实训当中我们遇到了不少难题，但是经过我们大家的讨论和老师细心的一一指导，问题得到了解决。两个月的实训结束了，收获颇丰，同时也更深刻的认识到要做一个合格的程序员并非我以前想像的那么容易，最重要的还是细致严谨。社会是不会要一个一无是处的人的，所以我们要更多更快地从一个学生向工作者转变，总的来说我对这次实习还是比较满意的，它使我学到了很多东西，为我以后的学习做了引导，点明了方向。实库中，删除相关信息；（7）显示删除成功信息；（8）结束。
精选 训的日子即将结束，回想这一个过程，有过痛苦，有过烦恼，有过喜悦和有过成功。痛苦烦恼的是自己对所学书本知识掌握得不是很扎实，面对着从书本上学到的知识与实际联系不起来，总结起来就是自己的动手练习的时间太少。而喜悦的是，在做的过程中遇到了困难和问题，主动向老师和会的同学请教，然后再做，直至做正确做成功后的那种喜悦。
团队的力量是无穷的，通过组员的共同努力，完成了实训项目。虽然，我们这组的项目存在着诸多的不足和缺点，但这正是以后学习和工作需要弥补的。这次实训将为我以后进入社会提过了一笔宝贵的财富，是对我能力的一个见证。最后，不得不感谢指导教师熊飞老师的辛勤指导，和小组成员的共同努力！篇4：uml实验报告
学 生 实 验 报 告 书
实验课程名称 uml建模技术 开 课 学 院 指导老师姓名 学 生 姓 名 学生专业班级
2009—2010学年 第 一 学期 实验课程名称： uml建模技术 篇5：uml实验——状态图 实验报告
南京信息工程大学实验(实习)报告
实验名称 状态图 实验(实习)日期 2014.04.26 得分 指导老师 系专业 班级 一、实验目的1．熟悉活动图的基本功能和使用方法。2．掌握如何使用建模工具绘制活动图方法。二、实验器材 1．计算机一台。
2．rational rose 工具软件。三、实验内容
通过前面内容的学习，完成了对图书馆的图书馆管理系统的需求的初步分析，得出系统的用例图和相应的活动态。通过这两类图我们可以初步了解系统的业务处理过程，但对业务处理过程的处理状态间转换了解仍不够，这不利于设计人员对系统业务的进一步理解，而状态图能从对象的动态行为的角度去描述系统的业务活动。因此，指派你运用本节所学的状态图，完成如下任务：
1.完成图书业务模块中还书用例的状态图。 四、实验步骤
1．业务分析：由前面章节对图书馆管理系统中的还书主要业务的描述和分析可知，还书业务的动态行为是由：空闲（idle）、图书查找（finding）、还书（reversion）、失败（failure）、归还成功（succe）5种状态及激活相互转换的事件。实验课程名称： uml建模技术
精选 2．绘制状态图：请您根据分析运用uml绘制还书用例的状态图。分析：
还书的状态图，还书的主要业务都是由管理员来完成，首先管理员必须先登录系统，并通过验证后，便可以进行下一步的操作，查找该书的相关信息，如存在，则进行还书操作，如不存在该信息，则给出提示信息；
绘图步骤：
（1）在用例图中的还书（revesion）用例，单击右键，如图3.1所示，新建一个状态图，命名为revesion状态图。
（2）双击“receivesion”状态图，展开后，在左边的工具栏上选取一个实心圆点，此结点为开始结点；当还书的时候，操作者先要询问系统的状态，如果系统忙，操作者则必需等待，因此，得到系统的两种状态。
（3）操作者在询问系统和状态后，得到两种状态，如果系统忙，操作者必需要等待、结束，重返步骤（1）。
（4）如系统空闲，则进行对还书的信息进行查询操作；查询也有两种结果，一是查询得到该书的相关信息，二查询不到该书的相关信息；则此时有两种状态，需要建立两种状态。
（5）最后，操作者进行了操作后，系统会给出操作的结果给操作者；操作成功或失败，都会有提示信息给出。整个的还书的过程便完成。
（7）根据分析设计情况，进一步添加或细化状态图。五、实验报告要求 1．整理实验结果。2．小结实验心得体会。
通过本次试验学习到了项目中状态图的绘制，了解了他们之间的关系以及关系处理的方法，熟悉了对rational rose 工具软件的使用，在以后做软件项目设计有很大的帮助。
精选
第4篇：UML JSP课程设计心得体会
在这次课程设计过程中，在这与代码为伴的一个月里，我真的收获了很多。这次软件工程大型课程设计，既巩固了这学期学的UML知识，又复习了关于数据库和java的知识，更是学会了如何将所学知识运用到实际，真正的应用到软件开发、网站开发中来。
这次课程设计还有一个额外收获，就是初步学会了用JSP开发网页。虽然做出来的网页不是特别美观，有些地方还存在一些瑕疵，但是从对网页编程一窍不通到能做出一个功能基本完善的简单的毕业设计选题系统，一步步走来，其中收获的不仅仅是全新的知识，对于自学能力、动手能力、合作能力甚至接受挑战的勇气方面的影响，也都是巨大的。对于我来说，以前只接触过用C语言在DOS界面下编程，用java编写简单的桌面应用程序，最多只是简单的连接数据库，所以一开始听说要编网页的时候，实在是缺乏信心，在编程过程中遇到一些棘手的问题的时候，甚至一度想要逃避，可最终还是坚持下来了。虽然这点小程序对于熟练掌握网页编程语言的人来说不算什么，但对于我来说，没有接触过的东西，就是一个新挑战，任何语言的学习，在入门的时候都是最困难的。现在对于网页编程已经有了一个初步的了解，对于有些概念的理解还不是很准确，不过会努力在以后的学习过程中慢慢理解，在以后的编程过程中慢慢熟悉这些概念。
除了学习新语言的收获外，在编程过程中对于功能的实现、一些异常的处理还有界面的设计，也有着很深的感触。既然要做毕业设计选题系统，那么就要先考虑到用户的功能需求，分析不同的用户都是要通过网站做什么，每个用户都有哪些权限；对于数据库的操作来说，是要向数据库中插入数据，还是更新还是删除。而且要考虑到各个方面异常的处理，比如用户名、密码错误怎么办，输入的信息错误怎么处理，成功更新数据库信息后要弹出什么提示框，要转入那个页面等等。对于异常处理，我做的还不够好，由于时间精力有限，有一些异常情况没有考虑到，功能实现的还不够完美，在以后的编程过程中我会在力所能及的范围内尽量考虑周全，既然要做程序，那就要尽量做的完善。对于界面的设计，由于时间关系，没有采用流行的Dreamweaver，感觉有点遗憾，网页的背景图片都是自己手工合成的，略显简陋了些，唯一值得欣慰的就是实现了我一直想要的布局效果，以后在美工方面也会努力的提高自己的能力。
另外对于实际应用中课程之间的融合也是有了一个初步的概念。一开始总觉得UML没有什么实际的用处，但通过这次课程设计我发现，每门课程都是有它独特的意义的，UML中画出的类图、顺序图、活动图等等都对自己编程过程有着极佳的指导意义，这些图能使编程思路变得更加清晰。
总而言之，这一个月的感受可谓五味杂陈，是三言两语难以说清的，最明显的还是感觉到自己知识的不足，对于一些东西还是缺乏一个系统的准确的理解。java是门很有用的语言，考试范围之外的东西还有很多很多；JSP让我接触到了全新的网页编程，也让我知道，学无止境，想要全面深入的掌握一门语言，还是要付出很大的努力的。
第5篇：uml课设心得
六月23号至六月27号，是我们班进行UML专用周课程设计的时间，虽然时间并不是很长，只有短短的一个星期而已，但是让我受益匪浅，通过这次的UML课程设计，使我所学的书本知识得到了全面的检验，也让我对这门课程有了更加深厚的体会。
这次课程设计我们没有另外选题，而是在我们之前做过的系统之上加以完善和改进。现在看看之前提交的作品，确实不近人意；但经过在网上的不断查找资料，终于还是将它完成。之前我做的系统状态图和活动图，为了锻炼自己这次选择了交互图（也就是时序图和协作图）。虽然说自己没有这方面的经验，也不是特别熟悉其工作流程，但是有了在网上 查找资料得来的一些基础和课本里的讲解，自己对它也有了一定初步的认识，虽然不是很全面，但还是跌跌撞撞的完成。其中还因为和组员没有沟通好导致用的类不同，费了好大劲才改回来。
最后，这次课设使我们发现考试真的并不是最重要，最重要的是能运用所学的知识。在整个UML课程的学习过程中，我们突破了传统学习模式，把被动接受转变为主动学习。不再是用学到的知识解题，而是在实际运用时遇到什么学什么，重在把知识应用于实际。立体的运用比死板的模仿更有效也更容易接受。下学期就大四了，也就是大学校园里的最后一年，而课设里学到的动手能力和分析问题解决问题的能力也将是我们毕业找工作的一大筹码。
第6篇：Uml用例图心得
Uml用例图心得
序言：用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。
【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。
用例图所包含的元素如下：
1.参与者(Actor)
表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
2.用例(Use Case)
用例就是外部可见的系统功能，对系统提供的服务进行描述。用椭圆表示。
3.子系统(Subsystem)
用来展示系统的一部分功能，这部分功能联系紧密。
4.关系
用例图中涉及的关系有：关联、泛化、包含、扩展。
如下表所示：
a.关联(Aociation)
表示参与者与用例之间的通信，任何一方都可发送或接受消息。
【箭头指向】：指向消息接收方
b.泛化(Inheritance)
就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。
【箭头指向】：指向父用例
c.包含(Include)
包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。
【箭头指向】：指向分解出来的功能用例
d.扩展(Extend)
扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。
【箭头指向】：指向基础用例
e.依赖(Dependency)
以上4种关系，是UML定义的标准关系。但VS2010的用例模型图中，添加了依赖关系，用带箭头的虚线表示，表示源用例依赖于目标用例。
【箭头指向】：指向被依赖项
5.项目(Artifact)
用例图虽然是用来帮助人们形象地理解功能需求，但却没多少人能够通看懂它。很多时候跟用户交流甚至用Excel都比用例图强，VS2010中引入了“项目”这样一个元素，以便让开发人员能够在用例图中链接一个普通文档。
用依赖关系把某个用例依赖到项目上：
然后把项目-》属性 的Hyperlink设置到你的文档上；
这样当你在用例图上双击项目时，就会打开相关联的文档。
6.注释(Comment)
包含(include)、扩展(extend)、泛化(Inheritance)的区别：
条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的；
直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提供间接服务。
对extend而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。
对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系；
一个用例图示例：
第7篇：UML实验指导
UML实验指导书
实验一 UML建模基础...................................................................................................1 实验二 类......................................................................................................................2 实验三 类的关系..........................................................................................................8 实验四 用例图及进度安排........................................................................................12 实验五 交互图............................................................................................................17 实验六 活动图............................................................................................................26 实验七 状态图............................................................................................................34 实验八 组件图和部署图............................................................................................41
2010-9-1
实验一 UML建模基础
一、实验目的和要求
1．熟悉UML建模工具Visual Paradigm和Rational Rose的基本菜单及操作。2．掌握UML的三大组成部分及各部分作用。3．掌握UML规则和相关机制。
4．掌握UML的可见性规则和构造型的作用。
二、实验器材
1．计算机一台。
2．Rational Rose 工具软件。
三、实验内容和步骤
1．练习使用建模工具建立各种UML图形，并对图形进行相应编辑和修改。2．认识各种UML关系及可见性符号，并用工具表示出来。
四、分析与讨论
总结UML在软件工程中的作用以及使用UML建模的必要性。
五、实验报告要求
1．整理实验结果。2．小结实验心得体会。
实验二 类
一、实验目的1．理解类的基本概念。
2．掌握如何从需求分析中抽象出类的方法。3．掌握在Rational Rose中绘制类的操作方法。
二、实验器材
1．计算机一台。
2．Rational Rose 工具软件。
三、实验内容
运用本节所学的有关如何抽象出类的知识，寻找和抽象出图书馆管理系统中书籍管理功能中的类。
四、实验步骤
1．分析：图书馆管理系统中的书籍管理功能模块是由书籍信息类、书目类、新增书籍界面类、修改书籍界面类、删除书籍界面类和书籍管理类6个类组成。2．绘制类的步骤：
（1）打开前面初步构建的UML模型文件;（2）打开Rose中的逻辑视图（Logical View），选择分析模型（analysis model）目录。并在其下创建一个子目录并命名为：“图书馆业务功能”。
（3）用鼠标右击“图书馆业务功能”在弹出来的菜单中选择“New→Cla diagram”项，创建类图，如图2.1所示。
（4）双击新建的类图，并点右边控件集中选中的类的图标，并用鼠标在图中分别拖出一个类图，并命名为Book，如图2.2所示。
图2.1
图2.2（5）接下来的一步为设置类的属性，在新的类中双击该类，在打开属性面板中，可以看到在此可以设置类的属性和方法等其他的信息，图2.3所示；后撞击Attributes这个栏目，此栏目为设置类的属性的选项，在图中间的单击右键，可以看到有一个“Insert”的选项，选中这个选项，图2.4所示，后在出现的对话框中输入相关信息如图2.5所示；如书本的ISBN号，在Type这个方框内输入此属性的类型值，同时可以看到一栏可以设置此属性的访问权限，一般这些属性都设置Private这个权限，如图2.6所示。这个类的其他属性也可以按照以上的做法设置，最后得到的结果是图2.7所示。
图2.3 图2.4
图2.5 图2.6（6）设置好类的属性，现在来设置类的方法（也是操作），双击类后在弹出的菜单上选operations这个选项，可以看到图2.8所示，在图中的空白地方，单击右键，在弹出的菜单中选insert这个选项，也就只有这个选项可用，见图2.9，接着输入方法名，同时可以设置该方法的返回类型，也可以在Documentations的方框内填写一些相关的方法说明，如图2.12所示，设置好该方法的访问权限，见图2.13。类的其他方法也可以按上面来设置好，最后，得到该类的其他方法见类2.14。
图2.7
图2.9
图2.8
图2.10
图2.11 图2.12
图2.13 图2.14（7）至此，类的方法和属性都设置好了，如图2.15所示。
图2.15（8）接下来为书目类设置，按照上面的步骤可以设置好该类的属性和方法，如图2.16和图2.17所示。
图2.16 图2.17（9）最后，绘制出由分析得出的各个类，如图2.18所示，此时，类图便完成。（10）根据分析情况，进一步细化添加相关的类。
图2.18
五、实验报告要求
1．整理实验结果。2．小结实验心得体会。
实验三 类的关系
一、实验目的1．理解类间关系的基本概念。2．掌握描绘类间关系的方法。
3．掌握在Rational Rose中绘制类关系的操作方法。
二、实验器材
1．计算机一台。
2．Rational Rose 工具软件。
三、实验内容
我们知道类通常是不会单独存在，而是由关联、泛化、依赖等关系相互协作来静态描述业务系的。因此，我们在找出系统中所存在的类的前提下，需要进一步对业务对象间如何联系进行建模。现指派你运用本节所学的相关知识，完成如下任务：
1．对书籍管理功能中的类的关系建模。
四、实验步骤
1．分析：由前面章节对图书馆管理系统中的书籍管理业务分析和对该业务的抽象出来的类可知，图书馆的主要静态模型类图是由书籍管理类、书类、书目类、管理员类、用户类和各种界面操作类组成。其中用户类与管理员类是泛化的关系，而其它类之间均是关联关系。
2．请在Rational Rose中绘制类间的关系。绘图步骤：
（1）打开上面做好的类图，添加管理员类，用户类，界面类。首先，添加一人管理员类，图3.1，并按照上面所说方法添加类的各种属性和方法，见图3.2、图3.3。
（2）可以依照上面的操作来添加其他的类，如：用户类（Reader类）、界面类(ActionForm),添加完后结果如图3.4 和图3.5所示；
（3）其他的类添加完后，就可以为各个类添加关系了，由关联、泛化、依赖等关系相互协作来静态描述业务系，所以，各个类的关系也由这几个关系来完成。如图3.6所示：Person类是administrator类和reader类两个类的父类，他们之间为泛化关系。administrator类和reader类是继承Person类。BoobItem类是继承Book类的，其他的类为一般的依赖关系，最后，连接完线条便得到图3.6。
（4）根据分析设计情况，进一步细化各类之间的关系。
图3.1
图3.2
图3.3
图 3.4
图3.5
图3.6
五、实验报告要求
1．整理实验结果。2．小结实验心得体会。
实验四 用例图及进度安排
一、实验目的1．熟悉用例图的基本功能和使用方法。
2．掌握如何使用Rational Rose 建模工具绘制用例图方法。
二、实验器材
1．计算机一台。
2．Rational Rose 工具软件。
三、实验内容
根据图书管理系统开发进度，在完成对系统的需求建模，得到用例模型后，应针对每个用例进行业务分析，说明其具体的业务流程，现系统分析部指派您完成该项任务。要求：
对其中主要功能的用例书写书面用例。
四、实验步骤
书写“删除读者信息”用例的书面用例。一般应包含以下信息：（1）管理员在录入界面，输入待删除的读者名；（2）“业务逻辑”组件在数据库中，查找待删除的读者名；
（3）如果不存在，则显示出错信息，返回步骤（1），如果存在则继续；（4）“业务逻辑”组件判断“待删除的读者”是否可以删除；
（5）如果不可以，则显示出错信息，返回步骤（8），如果可以则继续；（6）在数据库中，删除相关信息；（7）显示删除成功信息；（8）结束。分析: 在图书管理系统中,管理员首先登录系统,系统验证通过后,管理方可向系统查询数据,在查询后,系统会给出提示,有没有找到相关的数据,管理员根据系统查询的返回结果,进行下一步的操作,就是删除读者,在删除的过程中,系统会对查询得到的结果判断该记录是否可以删除,若可以删除,则给删除提示,若不能删除,也给相关的提示信息。
绘图步骤:(1)在用例图上双击main,出现如图4.1所示,为绘制用例图做好准备。
(2)在图中的工具栏选取Actor图标，在右边的图中添加一个Actor，并输入名称:administrator，如图4.2所示。
(3)在左边的工具栏中，选取用例的图标，在右边的图中画出一个用例，并输入用例的名称：login，如图4.3所示。
图4.1
图4.2（4）按照步骤（3），绘制出如图4.4和图4.5的两个用例。
图4.3
图4.4
图4.5（5）在绘出了用例后，接下来的是绘制参与者与用例的关联，如图4.6所示。
图4.6
（6）根据步骤（5），同时完成如图4.7和图4.8。此时，删除读者用例图就到此完成。其系统查询读者信息等其他的功能会在时序图和活动图中描绘。
（7）根据分析情况，进一步添加或细化用例图。
图4.7
图4.8
五、实验报告要求
1． 整理实验结果。2． 小结实验心得体会。
实验五 交互图
一、实验目的1．理解顺序图的基本概念。2．理解协作图的基本概念。
3．掌握在Rational Rose中绘制交互图的操作方法。
二、实验器材
1．计算机一台。
2．Rational Rose 工具软件。
三、实验内容
通过对教学内容的学习，使我们完成了图书馆的管理系统的需求分析，并从业务对象中抽象出了类。现在需要对前面所给出的用例进行实现，而用例的实现主要由交互图来指定和描述系统的动态特性。现指派你运用本节所学的相关知识，完成如下任务：
1．对书籍管理功能中的用例进行动态建模。
四、实验步骤
1．分析：根据演示部分对图书业务功能模块中的交互操作进行动态建模的操作步骤和方法，请你对书籍管理模块中的交互操作进行动态建模。该模块中主要存在新增书籍、修改书籍信息和删除书籍三种交互操作。
2．请根据教材中示例部分在Rational Rose中绘制上述的交互图。绘图步骤：
（1）在Rose软件的左边栏目上的Logicl View单击右键，新建一个时序图，时序图是交互图一种表示，可以用时序来表示，如图5.1；在此，先单间介绍一下用法：图中的直线箭头是发送消息；虚线箭头是返回消息；曲折线是对象自己给自己发送消息并调用。
（2）接下来的是添加类，系统中的类是其他的方法的边界，在上面做好的类找到可以直接拖拉来图中，见图5.2 和图5.3所示。
图5.1
图5.2
图5.3（3）添加类后，便可以添加方法了，开始是必需是外面的实体向系统发送消息，如图5.4所示，是管理员登录时向系统发送的消息；
图5.4（5）可以按上一步的方法来完成其他的方法，如viladate（验证）,返回验证结果，当用户收到结果后，可以正常登录后便能进行增加图书见图5.5到图5.9。最后得到的时序图如图5.10所示。
图5.5 : administrator1: login : ActionFormSystem2: login3: validate
图5.6 : administrator1: login : ActionFormSystem2: login3: validate4: result5: result
图5.7 : administrator1: login : ActionFormSystem2: login3: validate4: result5: result6: add7: add
图5.8 : administrator1: login : ActionFormSystem2: login3: validate4: result5: result6: add7: add8: addbook
图5.9
: administrator1: login : ActionFormSystem2: login3: validate4: result5: result6: add7: add8: addbook9: addruselt10: addresult
图5.10
(6)完成了时序图后，可以按F5键便得到增加图书的协作图，见图5.11所示。
1: login6: add : administrator5: result10: addresult : ActionForm3: validate8: addbook4: result9: addruselt2: login7: addSystem
图6.11
（7）剩下的更新图书信息和删除图书信息的交互图在此不再一一详细的介绍，其绘图方法跟绘制增加图书的方法一样，最后得到见图5.12 到图5.15 : administrator : ActionForm1: login2: loginupdate : System3: validate4: result5: result6: updatebook7: updatebook8: updatebook9: updateresult10: updateresult
图5.12
1: login6: updatebook : administrator5: result10: updateresult4: result9: updateresult2: login7: updatebook : ActionForm3: validate8: updatebookupdate : System
图5.13
: administrator : ActionForm : System1: login2: login3: viladate4: viladateresult5: viladateresult6: delete7: delete8: delete9: deleteresult10: deleteresult
图5.14
1: login6: delete : administrator5: viladateresult10: deleteresult : ActionForm3: viladate8: delete4: viladateresult9: deleteresult2: login7: delete : System
图5.15
五、实验报告要求
1．整理实验结果。2．小结实验心得体会。
实验六 活动图
一、实验目的1．熟悉活动图的基本功能和使用方法。
2．掌握如何使用Rational Rose建模工具绘制活动图方法。
二、实验器材
1．计算机一台。
2．Rational Rose 工具软件。
三、实验内容
根据图书管理系统开发进度，在完成对系统的需求建模，得到用例模型后，应针对每个用例进行业务分析，说明其具体的业务流程，现系统分析部指派您完成该项任务。要求：
用活动图来描述系统中已知用例的业务过程： 1．描述删除读者用例。
四、实验步骤
绘制“删除读者信息”用例的活动图。删除读者信息一般按照以下步骤进行：（1）管理员在录入界面，输入待删除的读者名；（2）“业务逻辑”组件在数据库中，查找待删除的读者名；
（3）如果不存在，则显示出错信息，返回步骤（1），如果存在则继续；（4）“业务逻辑”组件判断“待删除的读者”是否可以删除；
（5）如果不可以，则显示出错信息，返回步骤（8），如果可以则继续；（6）在数据库中，删除相关信息；（7）显示删除成功信息；（8）结束。绘图步骤：
（1）在用例图中，找到删除的用例，如图6.1所示，在删除用例上单击右键，在弹出的快捷菜单中选“New”，Rose工具也会弹出一个菜单，选”Activity Diagram”，选中后单击，便可以新建好一个活动图。如图6.2所示。
图 6.1
图6.2(2)新建好活动图后，双击删除的活动图，得到如图6.3所示，然后把在左边的工具栏内点击“Swinlane“，在右边的图添加一个泳道，如图6.4所示，并命名为administrator.按照此步骤，再添加另一个泳道，并命名为SystemTool，得到图6.5。
图6.3（3）接着在左边的工具上选取开始点，并在administrator的泳道上添加，如图6.6所示；添加完开始结点后，再来为此活动图添加活动，图6.7所示，在左边的工具栏上选中Activity这个图标，在administrator这边的泳道上添加一个活动，命名为登录（login），再在开始结点和活动登录（login）之间添加活动关系，如图6.8所示。
图6.4
图6.5
图6.6
图6.7
图6.8
（3）完成步骤（2）后，登录输入需要对输入的信息进行验证，则在图中添加一个验证框，如图6.9所示：添加验证框后，验证的内容，如果通过，则允许管理员进行查询操作，如图6.10所示；如不能通过，则结束，如图6.11所示。
图6.9
图6.10
图6.11
（4）验证后，下一步的操作是查询需要删除的记录，添加一个活动，命名为delete，如图6.12和图6.13所示。
图6.12
图6.13（5）最后，在删除后，系统会返回操作结果给操作者，图6.14所示；删除成功或删除失败系统都会有信息返回给操作者。
（7）根据分析设计情况，进一步添加或细化活动图。
图6.14
五、实验报告要求
1． 整理实验结果。2． 小结实验心得体会。
实验七 状态图
一、实验目的1．熟悉状态图的基本功能和使用方法。
2．掌握如何使用Rational Rose建模工具绘制状态图方法。
二、实验器材
1．计算机一台。
2．Rational Rose 工具软件。
三、实验内容
通过前面内容的学习，完成了对图书馆管理系统的需求的初步分析，得出系统的用例图和相应的活动图。通过这两类图我们可以初步了解系统的业务处理过程，但对业务处理过程的处理状态间转换了解仍不够，这不利于设计人员对系统业务的进一步理解，而状态图能从对象的动态行为的角度去描述系统的业务活动。因此，指派你运用本节所学的状态图，完成如下任务： 1.完成图书业务模块中还书用例的状态图。
四、实验步骤
1．业务分析：由前面章节对图书馆管理系统中的还书主要业务的描述和分析可知，还书业务的动态行为是由：空闲（idle）、图书查找（finding）、还书（reversion）、失败（Failure）、归还成功（Succe）5种状态及激活相互转换的事件。
2．绘制状态图：请您根据分析运用UML绘制还书用例的状态图。分析：
还书的状态图，还书的主要业务都是由管理员来完成，首先管理员必须先登录系统，并通过验证后，便可以进行下一步的操作，查找该书的相关信息，如存在，则进行还书操作，如不存在该信息，则给出提示信息；
绘图步骤：
（1）在用例图中的还书（revesion）用例，单击右键，如图7.1所示，新建一个状态图，命名为revesion状态图，图7.2所示。
图7.1
图7.2（2）双击“receivesion”状态图，展开后，在左边的工具栏上选取一个实心圆点，此结点为开始结点，图7.3所示；当还书的时候，操作者先要询问系统的状态，如果系统忙，操作者则必需等待，因此，得到系统的两种状态，如图7.5所示。
图7.3
图7.4
图7.5（3）操作者在询问系统和状态后，得到的图7.6所示两种状态，如果系统忙，操作者必需要等待、结束，如图7.7和图7.8所示，重返步骤（1）。
图7.6
图7.7
图7.8（4）如系统空闲，则进行对还书的信息进行查询操作，图7.9所示；查询也有两种结果，一是查询得到该书的相关信息，二查询不到该书的相关信息；则此时有两种状态，需要建立两种状态，如图7.10所示。
图7.9
图7.10（5）最后，操作者进行了操作后，系统会给出操作的结果给操作者；操作成功或失败，都会有提示信息给出。整个的还书的过程便完成；图7.11所示。
（7）根据分析设计情况，进一步添加或细化状态图。
图7.11
五、实验报告要求
1．整理实验结果。2．小结实验心得体会。
实验八 组件图和部署图
一、实验目的1．理解组件图的基本概念。2．理解组件图的应用：逻辑部署。3．理解部署图的基本概念。4．理解部署图的应用：物理部署。5．掌握组件图和部署图绘制的方法。
二、实验器材
1．计算机一台。
2．Rational Rose 工具软件。
三、实验内容
图书管理系统的分析和设计已按计划完成类图和交互图的分析与设计，下一步将完成系统的组件图和部署图，现系统分析部指派您完成如下任务：
1． 完成系统的组件图。
四、实验步骤
1.绘制组件图 分析：
在图书馆管理系统中，通过分析可以发现类图中的类应分为4个部分：
1．用户接口模块（UI），主要负责系统和用户的交互，包括Frame类，Dialog类等。2．业务对象模块（BO），主要负责处理系统中的业务计算，如借书，还书等功能的具体操作。
3．数据存储模块（DB），主要负责处理对数据的存储。4．通用工具模块（UTIL），包括系统中通用函数。
通过一个主程序StartCla来启动。由于系统中的类较多，这里以业务对象模块（BO）为例来讲解如何创建组件图，BO模块中包括
Item类：书目类，表示一本实际存在的书籍或杂志
Loan类：借书业务类，将借阅者和图书馆关联起来，一个Loan对象表示借出的一本书 BorrowerInfomation类：借阅者信息类，表示一个借阅者。
Title类：表示一种书或一种杂志。如《C++编程思想》就是一种书，用1个title表示，如果有2本这样的书，则需要用2个Item表示。
Reservation类：预定信息类，表示一个预定信息。Item类和Loan类之间互相依赖，Loan类和BorrowerInfomation类之间互相依赖，BorrowerInfomation类和Reservation类之间互相依赖，Reservation类和Title之间互相依赖，Title和Item类之间互相依赖。绘图步骤：
（1）在组件视图中双击Main图，出现图8.1，为编辑组件图做好准备，这时绘图工具栏中的图标如图中椭圆所示，其中具体含义可参看本节“补充图标”一段的介绍。
图8.1（2）在组件视图中，从工具栏中选择MainProgram图标，在右边的绘图区中添加一个新组件，并取名StartCla.java表明新增一个主程序。
图8.2（3）选择新创建的组件，点击鼠标右键，在弹出的菜单中选择“Open Sepcification”,弹出图8.3对话框。
（4）在对话框中，可以修改组件的名称，设置组件的类型，指定实现的语言。这里新组件的名称定为“StartCla.java”，组件构型为Main Program（Rose中提供了多种构型，大部分在补充图标一段中均有简单的介绍），实现语言为JAVA（Rose中默认的是分析语言Analysis），修改结果如图8.4所示。
图8.3
图8.4（5）组件图描述的是系统的实现视图，因此要指定实现组件功能的文件。点击File选项卡，在列表框中点击鼠标右键，在弹出的菜单中选择“Insert File”，弹出文件对话框。在对话框中，键入StartCla.java，点击“打开”按键，这时对话框如图8.5所示。
图8.5（6）双击StartCla.java，弹出是否创建对话框，询问是否创建文件，选择“YES”,弹出记事本，这时可输入相应的源程序（注意：如果这里选择的文件已经存在，则不会弹出创建文件对话框，而是直接显示相应文件内容）。
（7）创建相应的包。选择包图标，在右图中创建。这里同样需要对每个组件打开“Open Specification”对话框，设置具体的属性，对“包”组件来说需要在Files选项卡中指明与其对应的目录。创建完毕的组件图如图8.6所示。
图8.6（8）选择业务对象包（BO），双击，打开业务对象包的详细组件图，这里根据分析的结果分别创建Title.java,Item.java，Loan.java，BorrowerInfomation.java，Reservation.java组件，并设置好每个组件的构型和对应的文件。创建好的BO包组件图如图8.7。
图8.7（9）创建依赖关系。在本节“关系”一段中，已经描述过依赖关系使用虚线表示，因此根据分析中的结果，在图中将相互依赖的组件连接即可。完成后的组件图如图10.8。
图8.8 2.绘制部署图 分析：
TJKD的图书管理系统目前开发的是一个单机版系统，其中所有的运算均在一台机器上完成，但是由于打印报表的需要，系统还应配备一台打印机。因此得出系统中存在2个节点：
① 一台主机，其类型是Proceor。② 一台打印机，其类型是Device。绘图步骤：（1）浏览窗口中选择“Deployment View”,弹出如图8.9所示窗口。
图8.9（2）在图中添加分别添加一个Proceer和Device，并分别命名为“computer with java support”和“Printer”，添加完毕后，其结果如图8.10所示。
图8.10（3）为节点添加连接关系。全图如图8.11。
图8.11
五、实验报告要求
1．整理实验结果。2．小结实验心得体会。
