推荐第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 JSP课程设计心得体会
在这次课程设计过程中，在这与代码为伴的一个月里，我真的收获了很多。这次软件工程大型课程设计，既巩固了这学期学的UML知识，又复习了关于数据库和java的知识，更是学会了如何将所学知识运用到实际，真正的应用到软件开发、网站开发中来。
这次课程设计还有一个额外收获，就是初步学会了用JSP开发网页。虽然做出来的网页不是特别美观，有些地方还存在一些瑕疵，但是从对网页编程一窍不通到能做出一个功能基本完善的简单的毕业设计选题系统，一步步走来，其中收获的不仅仅是全新的知识，对于自学能力、动手能力、合作能力甚至接受挑战的勇气方面的影响，也都是巨大的。对于我来说，以前只接触过用C语言在DOS界面下编程，用java编写简单的桌面应用程序，最多只是简单的连接数据库，所以一开始听说要编网页的时候，实在是缺乏信心，在编程过程中遇到一些棘手的问题的时候，甚至一度想要逃避，可最终还是坚持下来了。虽然这点小程序对于熟练掌握网页编程语言的人来说不算什么，但对于我来说，没有接触过的东西，就是一个新挑战，任何语言的学习，在入门的时候都是最困难的。现在对于网页编程已经有了一个初步的了解，对于有些概念的理解还不是很准确，不过会努力在以后的学习过程中慢慢理解，在以后的编程过程中慢慢熟悉这些概念。
除了学习新语言的收获外，在编程过程中对于功能的实现、一些异常的处理还有界面的设计，也有着很深的感触。既然要做毕业设计选题系统，那么就要先考虑到用户的功能需求，分析不同的用户都是要通过网站做什么，每个用户都有哪些权限；对于数据库的操作来说，是要向数据库中插入数据，还是更新还是删除。而且要考虑到各个方面异常的处理，比如用户名、密码错误怎么办，输入的信息错误怎么处理，成功更新数据库信息后要弹出什么提示框，要转入那个页面等等。对于异常处理，我做的还不够好，由于时间精力有限，有一些异常情况没有考虑到，功能实现的还不够完美，在以后的编程过程中我会在力所能及的范围内尽量考虑周全，既然要做程序，那就要尽量做的完善。对于界面的设计，由于时间关系，没有采用流行的Dreamweaver，感觉有点遗憾，网页的背景图片都是自己手工合成的，略显简陋了些，唯一值得欣慰的就是实现了我一直想要的布局效果，以后在美工方面也会努力的提高自己的能力。
另外对于实际应用中课程之间的融合也是有了一个初步的概念。一开始总觉得UML没有什么实际的用处，但通过这次课程设计我发现，每门课程都是有它独特的意义的，UML中画出的类图、顺序图、活动图等等都对自己编程过程有着极佳的指导意义，这些图能使编程思路变得更加清晰。
总而言之，这一个月的感受可谓五味杂陈，是三言两语难以说清的，最明显的还是感觉到自己知识的不足，对于一些东西还是缺乏一个系统的准确的理解。java是门很有用的语言，考试范围之外的东西还有很多很多；JSP让我接触到了全新的网页编程，也让我知道，学无止境，想要全面深入的掌握一门语言，还是要付出很大的努力的。
推荐第4篇：UML实验报告
一：需求分析
在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。我们在日常生活中也经常和ATM打交道。本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。 二：银行ATM机系统UML建模设计 1.用例图
参与者\"银行储户\"和ATM机。简化后的ATM机仅有取款、存款及其余功能。其余功能不做详细说明。
银行储户在ATM机上完成取款、存款及其他业务。 2.类图
整个银行系统包括了帐户库、银行储户库及ATM系统。
许多单个的帐户组成了帐户库。帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。
setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。 getType获取帐户类型，返回类型为char，无参数。
setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。 getAccountNumbe获取帐户号，返回类型为int，无参数。
caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。 getBalance获取帐户余额，返回类型为double，无参数。
许多银行储户组成了储户库。ATM系统包含了许多ATM机。银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。更多的属性及操作都可以一一加上，使这个类图更详细更完整，从而使参与项目的每个成员都能无歧义的明了整个设计的类的结构。同样对于一个真正的银行系统，这个类图过于简单。比如帐户类型我们可以先定义一个abstract cla，它包含一个帐户最基本的属性及操作。而有些操作先定义为abstract，如余额的计算。然后再继承这个abstract cla，我们可以有saving account 和checking account等等。不同的帐户有不同的余额计算方法，我们可以加上具体的算法。对于不同的帐户可能还有一些它特有的操作，我们也可以加上，比如saving account在存款达到多少时可以享受机票打折的优惠。通过类图不仅可以使设计者明确的表达自己的设计意图，也能帮组自己整理思路，充实及优化自己的设计。
3.顺序图
描述顾客在ATM机上取款时信息的流动情况。以时间为顺序。因为是示例图，所以整个过程是没有出现任何故障时的流程，并且只画到了取款结束。通过这个图，我们可以看出消息是如何在系统中不同对象之间进行交互。
通过流程图我们可以很清楚地看到系统是如何工作的，系统各部分之间的信息及控制是如何发送的，整个流程是否合理。流程图对我们的设计起到了很好的帮助作用。注意在本图没有一个生命线终端有一个\"X\"，这是因为这个流程中还未遇到有对象生命结束。当有对象生命结束时需在对应的生命线终端画\"X\"，表明这个对象在这时被销毁。
首先银行储户将ATM卡插入读卡机，读卡机将信息传给客户管理，客户管理提出查询密码，显示部分将输入密码请求显示出来….银行储户读卡机显示输入设备客户管理点钞机事务管理1: 插入ATM卡2: 接受ATM卡3: 查询密码4: 显示输入密码请求5: 输入密码6: 密码传递7: 请求确认密码的合法性8: 确认密码的合法性9: 询问服务类别10: 显示输入服务类别请求11: 输入取款请求12: 取消请求13: 询问取款数额14: 显示输入数额请求15: 输入取款数额16: 传递取款数额17: 询问取款数额确认18: 显示确认数额请求19: 输入确认20: 传递确认信息21: 数额合法性确认请求22: 确认数额的合法性23: 计算储户余额24: 出钞请求25: 出钞26: 取钞27: 传递余额并询问是否需要其它服务28: 显示储户余额并显示其它服务
推荐第5篇：UML实验报告
UML 实 验 报 告
实验一
用例图
一、实验结果
1、整理实验结果
2、小结实验心得体会
用例模型用于需求分析阶段，它描述了待开发系统的功能需求，并驱动了需求分析之后各阶段的开发工作。用例图是UML中用来对系统的动态方面进行建模的7种图之一。用例图描述了用例、参与者以及它们之间的关系。用例图从用户角度描述系统功能，并指出各功能的操作者。
通过本次实验，我熟悉 Rational Rose 建模环境，更加清楚的了解了用例图的语义和功能，如何清晰明了的识别参与者、用例，学会了如何使用事件流描述用例。同时掌握了用例间的类属关系、Include关系和Extend关系的语义、功能和应用。最后通过本次实验学习了如何使用用例图为系统的上下文以及系统的需求建模。
二、思考题
1、如果要删除参与者、用例，请问是在导航窗口删除，还是在绘图窗口删除？
答：都可以删除，但在绘图窗口中有两种删除方式：一种是只删除参与者、用例，而不改变其在导航窗口中的存在，另一种是从建模中完全删除。
2、如果要删除参与者和用例的联系，用例和用例的联系，请问是在绘图中删除，还是在参与者或用例的设置对话框中删除？ 答：都可以删除。
实验二
类对象模型的建立
一、实验结果 1．整理实验结果。
2．小结实验心得体会。
类图是面向对象系统建模最常用的图，描述了类图、接口集、协作以及它们之间的关系。类图描述了系统的静态设计视，该视主要体现系统的功能需求，即系统应该提供给用户的服务。
通过本次实验，加深了我对类图语义的理解和功能的应用，掌握了类之间的联系，关联、依赖、聚合等，同时基本掌握了在 Rational Rose中绘制类的关联、依赖、泛化关系。
二、思考题
选中一个模型对象，点击鼠标右键，比较快捷菜单项“Edit——Delete”与“Edit——Delete from Model” ，它们二者之间区别在哪里？
答：“Edit——Delete”只删除绘图窗口中的图形，而不改变其在导航窗口中的存在；“Edit——Delete from Model” 是从建模中完全删除。
实验三
顺序图、协作图
一、实验结果 1.整理实验结果。
2.小结实验心得体会
顺序图描述了对象之间的动态合作关系，它强调对象之间消息发送的时间顺序，同时显示对象之间的交互。协作图与顺序图是同构的，Rose 可自动转换。顺序图是强调消息的交互作用图，协作图描述了对象间的关系，是强调发送和接收消息的对象的组织结构的交互作用图。
通过本次实验，掌握了对图书管理功能中的借书用例、还书用例进行动态建模。实验过程中由于对Rational Rose工具软件的不熟识，导致出现了不该出现的错误。在设计阶段，顺序图中需要引入边界类和控制类，在识别对象职责的基础上，需要将消息转换为类的方法，为方法定义参数、返回值类型，便于计算机的实现。其中，为方法定义参数、返回值类型的时候，还是不能够快速准确的作出判断。
实验四
活动图
一、实验结果 1．整理实验结果。
2．小结实验心得体会
在UML中，活动图是为系统的动态方面建模的7个图之一。活动图主要是一个流图，它描述了从活动到活动的控制流，它还可以用来描述对象在控制流的不同点从一个状态转移到另一个状态时的对象流。
通过本次实验，我对活动图的语义和功能有了更深层次的理解和应用，并对活动图的组成部分，包括动作状态、活动状态、分支、分叉和泳道、对象流，逐一进行了学习。同时基本掌握了用活动图来描述系统中“借出图书”用例的业务过程。实验过后本应该有完整的截图，由于自己的粗心马虎，造成截图的不完整性。
实验五
状态图
一、实验结果 1．整理实验结果。
2.小结实验心得体会。
状态图描述了一个特定对象的所有可能状态，以及引起状态跃迁的事件。状态图用来模拟系统的动态方面，这些动态方面指系统对象按事件发生顺序排序的行为。状态图可以用来描述整个系统、子系统或类的动态方面，还可以用来描述用力的一个脚本。
通过本次实验，我熟悉了状态图的基本功能和使用方法。掌握了如何使用建模工具绘制状态图方法。同时完成了图书管理业务中，资源项“ResourceItem”的状态图。
实验六
组件图和部署图
一、实验结果 1．整理实验结果。
2．小结实验心得体会。
组件图和部署图是用来为面向对象系统的物理实现建模的两种图。组件图描述了组件、组件间的关系，表示了组件之间的组织和依赖关系，它用来为系统的静态实现视建模。部署图描述了节点和运行其上的组件的配置，它用来模拟系统的静态部署视。
通过本次实验，我理解了组件图的基本概念及组件图的应用：逻辑部署。 理解了部署图的基本概念。 及部署图的应用：物理部署。掌握了组件图和部署图绘制的方法。完成了系统的组件图和系统的部署图。
二、思考题
1.为什么要求相对应的类名、组件名和实现组件的文件名相同？
答：相应的名字中能够找到相应的类的信息。如果组件名、类名和 Java 文件名不相同，会出现实体类的语法错误。
实验七
正向工程
一、实验报告要求 1．整理实验结果。
2．小结实验心得体会。
正向工程是对一个系统物理结构实现的高层抽象性、逻辑性及独立性设计的传统处理过程。通过本次试验，学会了利用 Rose 工具生成代码框架及生成数据库脚本 ，同时在实现过程中使用转换后的代码和数据库脚本。了解了Java 编程综合练习。
二、思考题
1．在本案例中，并未对实体类 ResourceTitle 设置主键，系统在生成数据库脚本时是如何处理的？
答：（1）设置类的持久化特性和主键：在导航窗口右击类，如“Loan”，选择快捷菜单“Open Standard Specification”菜单项，打开类设置对话框。选中“Detail”选项卡中的“Persistent”特性。点击 OK按钮，关闭设置对话框。然后，在导航窗口中展开类的属性，鼠标右击类的某个属性，如类“Loan”的属性“LoanID”，选中快捷菜单中的“Data Modeler”的“Part of Object Identity”属性，这样，在生成数据模型时，该属性就成为表 Loan 的主键。（2）创建数据库组件。（3）在导航窗口中选择所生成的数据库模式 S_0，单击鼠标右键，选择快捷菜单项“Data Modeler——Forward Engineer”，出现生成数据库脚本的导航界面，鼠标单击“Next”按钮，在导航界面输入脚本文件的保存路径，注意 SQL Server2000 的脚本文件扩展名用.sql。单击“Next”直至完成脚本文件的生成。
2.本案例中，ResourceTitle 与BookTitle、DiscTitle的继承关系，SQL Server 2000 关系型数据库的转换合理吗？如不合理，请问该如何修改？ 答：不合理。
推荐第6篇：UML实验报告[推荐]
UML实验报告
班 级：软件0841
姓 名：张文成 学 号：081842173
实验内容：
用例建模、分析建模、设计建模（1）、设计建模（2）
实验一：用例建模
[实验目的] 〃掌握客户需求分析的方法和步骤
〃了解以用例驱动的软件开发方法 〃识别并编写用例
〃掌握用Rose 进行用例建模的具体方法和步骤
[实验内容] 要求学生根据周围的实际情况，自选一个小型应用项目，分析业务需求，识别并编写用例、绘制用例图以理解系统需求。亦可采用教师指定的“企业综合信息管理系统”中的“进销存管理子系统”
[实验原理和步骤] 建模原理：
(1) 需求获取。以任务和客户为中心，通过会议、面谈等手段对客户需求进行调研，获得系统目标、范围和功能要求的初步说明。 (2) 用例分析。确定用例，同时采用分层思想，对用例的层次级别进行划分（高层用例、子系统级、用户目标级）
（3）用例描述。分层绘制用例图，撰写用例的文字描述（采用单栏格式）。
步骤：
（1）需求获取。自选题目，与相关客户、领域专家等反复商讨，获得系统目标、范围和功能要求的初步说明。（也可采用教师指定的题目：“企业综合信息管理系统”中的“进销存管理子系统”，但要仔细研读“企业现状”、“系统目标、范围和功能要求”等文字说明）。 （2）用例分析。确定系统范围和边界、确定参与者、确定用例。 （3）用例描述。分层绘制用例图、描述用例。
画图原理：
采用Rose 软件进行用例建模必须建立在完好的系统用例分析基础之上．只有做好系统用例分析，系统用例建模才能这到预期的效果。 步骤：
（1）分层绘制用例图，每层采用“包”进行管理。
（2）以“企业综合信息管理系统” ->“进销存管理”子系统->“销售管理” ->“合同管理” ->“收款单处理”为主线，完成附录2 中的操作过程（亦可选择“企业综合信息管理系统” ->“进销存管理”子系统->“库存管理” ->“原材料出库” ->“领料单处理”主线）
[ 实验结果]
实验2 分析建模
[ 实验目的] (1) 理解面向对象系统分析和对象类建模(概念建模)的概念 (2)了解和掌握面向对象系统分析的方法和步骤 (3)了解和掌握寻找待开发系统中类(概念)的方法和技巧 (4) 掌握使用ROSE 绘制概念模型的方法
[ 实验内容] 在用例分析的基础上，选择第一个迭代周期打算开发的用例，建立相关的概念模型。
[ 实验原理和步骤] 建模原理：
(1) 使用概念目录列表（见下图）和非正式分析法（识别出问题域的文本描述中的名词短语，然后将其作为概念或属性的候选对象。）相结合的方法识别概念。因此，待开发用例的文字描述中，名词可能成为概念或属性的候选对象；表示行为的动词词组有可能成为事务型或过程型对象；形容词词组有可能对应抽象的名词型概念。
采用的技术基本上就是：ER 图+纯行为+OO 的聚合、泛化。 （2）最终关联的数量介于“需要知道”型关联与【“需要知道”型关联+“需要理解”型（从通用关联列表中派生出 的，见下图）】之间。
步骤：
（1） 识别关键用例作为第一个迭代周期的开发目标（一般是在用例图中被依赖得比较多的用例）。可以选“企业综合信息管理系统” ->“进销存管理”子系统->“库存管理” ->“原材料出库” ->“领料单处理”主线中的“领料单处理”用例；也可以选“企业综合信息管理系统” ->“进销存管理”子系统->“销售管理” ->“合同管理” ->“收款单处理”主线中的“增加销售合同”或“收款单处理”用例。（其实，选“库存管理”主线更合适；当然，如果要实现产销一体化，以销售订单指导生产和采购，并实现零库存目标，那么一切工作就以销售管理为中心。即便如此，首选“增加合同”用例也更为合适。）
（2）识别概念和重要属性。
（3）建立概念间的关联。
画图原理：
（1） 可以采用“逻辑视图”下的类图描述概念模型，只不过每个类中只有类名和属性，没有方法。在概念建模 阶段也没有必要确定属性的类型和访问属性。
（2） 概念间的关联可以采用一般关联（无方向实线），当然，对于聚合和泛化，应采用相应的连线（组合：实心菱形+实线；聚合：空心菱形+实线；泛化：空三角形+实线）
步骤：
（0）前提条件：第一个迭代周期可以选“企业综合信息管理系统”
->“进销存管理”子系统->“库存管理” ->“原材料出库” ->“领料单处理”主线中的“领料单处理”用例；也可以选“企业综合信息管理系统” ->“进销存管理”子系统->“销售管理” ->“合同管理” ->“收款单处理”主线中的“增加销售合同”或“收款单处理”用例。做好与此用例相关的概念模型
（1）建立相关的概念模型的基础上，在“逻辑视图”下的类图中描述概念模型，可以直接在类图main 中绘制，也可采用类似用例图中用过的分包机制
(2）绘制概念和重要属性。 （3）绘制概念间的关联。
[ 实验结果]
[ 实验总结] ① 对重点实验结果进行分析；
② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。
③ 收获与体会：筛选概念的要点；区分概念与属性的要点；关联取舍的要点；画图时如何防止关联重名。
实验3 设计建模（1）
[ 实验日期]2011年5月20日 [ 实验目的] (1) 理解顺序图的基本概念
（2）了解和掌握软件工程中用例逻辑时序的分析方法 （3）掌握使用ROSE 创建顺序图的方法
[ 实验内容] 在用例模型和概念模型的基础上，对首选的用例进行事件分解，识别出系统事件（系统操作），（并写出契约的后置条件）；为每个系统事件画顺序图，为对象分配职责。
[ 实验原理和步骤] 原理：
(1) 在系统顺序图中，所有的系统都被当成黑盒子看待，顺序图的重点是参与者发起的跨越系统边界的事件。
(2) 系统事件是由某参与者发起的指向系统的输入事件。一个事件的发生能够触发一个响应操作的执行。
(3) 请仔细研究下图,考察它是如何从左边的\"购买商品\"用例的文字描述中分解出3 个系统事件的。
（4）参照用例模型和概念模型，为每个系统操作估计后置条件。（实例创建、形成关联、属性修改） （5）按照设计模式为对象分配职责。
步骤：
（1） 分析首选用例的文字描述，按事件进行分解，识别出系统事件。（下面以“企业综合信息管理系统” ->“进销存管理”子系统->“销售管理” ->“合同管理” ->“收款单处理”主线中的“收款单处理”用例为例）。
我们暂不考虑批处理。第一个核对，因为要将“货款金额填写到合同中”。后置条件显然有“销售合同”的属性修改。此合同显然已经存在，不需要创建，但需要根据合同编号find，然后形成关联。第二个核对需要根据合同明细到仓库的“存货明细”（概念模型中还没有）中去查。此核对发生前虽然敲了一下键盘，但随后并没有新的消息穿越系统边界，因此这仍然是同一个系统事件。先考虑成功场景，应该向库存系统发提货单（概念模型中还没有）就结束了。后续的削减库存（核销）、预警显然不是销售管理员的职权，并且真正的核销必须由仓库的发货人执行，才能保证货帐一致。并且“生产厂家”与“邮购公司”的运作方式不同，后者是自己的员工取货并邮寄，而前者还有可能是来人来车取货，这时仓库收到取货单后并不能立即自动处理（开发货单），必须等取货人到达才能处理。
根据题意，本项目应该是“生产厂家”模式。这又存在一个问题，如
果在开出提货单后不修改库存，可能影响并发用户和后续付款单的处理。所以有必要设计一个“临时存货明细”（概念模型中还没有）（不是真实的“存货明细”）供修改，何时按存货明细”进行刷新应该是库存管理系统的事（比如每天夜里刷新，但因为雨雪天气，取货 人迟迟不提货，是提货单作废（相当于退回销售系统，付款单变为未处理）还是就强行刷新（此时有冲突危险）？）失败场景。向“生产调度部门”发送“产品生产申请单”。如果是专门为此单进行生产，那么还应该有库存系统发来的“产品入库通知处理”用例来调用本用例进行发货。本题显然一概根据付款单运作，因此如果失败，就不处 理付款单，但按日期把它排在待处理付款单的前面。从前面的分析来看，就一个系统事件，我们就命名为“付款单处理(pb:付款单)” （2） 为每个系统事件估计后置条件。(以上已做了部分分析) （3） 按设计模式进行设计。
首先考虑控制者,领域控制者选参与者角色，即“销售人员”。为了避免使用FORM,窗口等表示层对象,我们人造一 个类”应用协调者”向控制者发送消息。
[ 实验结果]
① 对重点实验结果进行分析；
② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。
③ 收获与体会：事件分解的要点；控制者选择的要点；绘制顺序图的要点。
[ 实验总结] ① 对重点实验结果进行分析；
② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。
③ 收获与体会：事件分解的要点；控制者选择的要点；绘制顺序图的要点。
实验4 设计建模（2）
[ 实验日期] 2011年5月27日 [ 实验目的] (1)理解面向对象类之间关联关系的概念 (2)了解和掌握分析类之间的关联关系的方法
(3)了解和掌握待开发系统中类之间关联关系的分析方法 (4)完善设计类图，掌握使用ROSE 对关联进行建模的过程
[ 实验内容] 根据设计建模（1）中的交互分析，进一步设计关联和对象可见性（补
上遗漏的关联）,完善设计类图。
[ 实验原理和步骤] 建模原理：
（1）关联关系描绘了给定类的对象个体之间的语义连接，是类与类之间的连接。关联可以分为一般关联、聚合关 联、组合关联和依赖关联等。
（2）一般关联包括一对类的二元关联及多个类之间的多元关联。
（3）聚合(Aggregation)表示整体和部分之间较强的关联关系，聚合关系的多重性大于1，则称为共享聚合。
（4）组合(Composition)关系表示整体和部分之间有比聚合关系更强的关系，它们之间是一对一的关系，即同生死共存亡，组合关系不能共享。
（5）依赖关系是一种使用关系，表现为一个对象仅仅调用了另一个对象的服务。可以使用下列的指导方针列出暂时性的关系：
(1)存在两个或两个以上的类相互之间就可能有关联。 (2)类的操怍(成员函数)的参数列表里出现其他类的对象。 (3)一个类包含另一个类的对象(对象成员)。 (4)根据一般常识可能会出现的关联。 步骤：
（1） 分析已建立的设计类图和交互图，进一步设计关联和
对象可见性（补上遗漏的关联）。（下面以“企业综合 信息管理系统” ->“进销存管理”子系统->“销售管理” ->“合同管理” ->“收款单处理”主线中 的“收款单处理”用例为例）。
在销售管理子系统中，定义的各个类之间一般都有关系发生。销售人员和客户(大客户)共同签署销售合同，
销售合同中涉及到多种可以销售的产品，合同经公司经理审查并签字后该合同才能生效，付款单需要客户付款， 销售人员签发催款单向客户催缴欠款，销售人员制定销售计划，销售人员要检查督促执行期合同按合同执行、履 约，履约后的合同转到履约合同数据库存档备查等等。 例如：
（a） 销售人员与客户：一般关联，多对多
（b） 销售合同与合同明细，销售计划与计划明细：组合。 （c） 付款单与客户：依赖关系。《如果付款单类中有“统计付款金额(客户类客户对象)”操作的话，付款 单类就依赖客户类》 （2）完善设计类图 画图原理：
（1）关联关系描绘了给定类的对象个体之间的语义连接，是类与类之间的连接。关联可以分为一般关联、聚合关 联、组合关联和依赖关联等。
（2）一般关联包括一对类的二元关联及多个类之间的多元关联。
（3）聚合(Aggregation)表示整体和部分之间较强的关联关系，聚合关系的多重性大于1，则称为共享聚合。
（4）组合(Composition)关系表示整体和部分之间有比聚合关系更强的关系，它们之间是一对一的关系，即同生死共存亡，组合关系不能共享。
（5）依赖关系是一种使用关系，表现为一个对象仅仅调用了另一个对象的服务。 步骤：
（1） 在关联和对象可见性分析的基础上，补充一般关联、组合，泛化、依赖
（a）一般关联关系要注意关联的命名以及哪个是role A 哪个是role B。
(b)一般关联选中role B detail 中的aggregate，就变成聚合；再选中by value 就变成组合。 (c)依赖画虚线箭头。 （2）完善设计类图
[实验结果] ① 对重点实验结果进行分析；
② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。
③ 收获与体会：分析依赖关系的要点，绘制关联的要点。 通过实验了解UML的建模的步骤和方法，了解用例图和类图等的画法，了解系统的分析和建模方法。增加动手和思维能力，使自己更加的了解软件系统前期开发的软件定义和分析方法。
推荐第7篇：UML复习总结
1.UML(unified modeling language): 统一建模语言是创建描绘软件系统结构和设计蓝图的标准语言。它用于指定、构造、记录软件系统的工件并使之可视化。~ 的基本组成部分：包括 UML 的静态、动态、包和注释等部分。~ 的构建块包含基本的成分、关系和关系图。基本成分包括结构、行为、分组和注释成分。
2.RUP(rational unified proce): 统一开发过程是一种过程框架，有助于使用创建和部署用UML设计的软件。~生命周期分为四个阶段：起始阶段、细化阶段、构造阶段、转换 3.软件开发生命周期(SDLC)是一个规范的、系统的软件开发方法。可分为六个阶段：可行性分析、需求分析和规范说明、设计、编码、测试、维护。软件的开发方法：瀑布方法、原型方法、螺旋方法、双赢螺旋方法、增量方法。在设计阶段，有两种~：①面向功能方法以模块为中心，注重软件的功能。②面向对象（OO）方法支持重用、数据封装、以及继承、抽象和多态性等概念。
4.面向对象分析和设计（OOAD）是指根据对象、类、封装、继承、多态、抽象和动态邦定来分析需求以及设计软件系统。
5.软件系统的各个视图：①用例视图：表示系统为客户提供的功能②设计~：侧重于系统的静态和动态表示③实施~：表示软件系统中组成系统所需的各个文件和组件④部署~：表示将执行软件系统和硬件的组合关系。
6.四种建模技术：①需求建模：包括使用用例关系图描述需求。②静态~：包括使用类、对象和复合结构关系图来描述软件系统的静态成分③动态~：包括使用以下关系图来描述动态成分的行为：活动关系图、状态机关系图、通信关系图、序列关系图、交互概览图、时序关系图④架构~： 描述软件系统的内部结构如何构成：包关系图、主件关系图、部署关系图 7.需求管理是一种持续的系统化方法。~的四个阶段： 需求收集 、~分析与协商、~规格化、~验证。需求分析指将需求分类和组织为功能性需求和非功能性需求的过程。功能需求指软件系统需要实现的功能和特性。非功能性需求指软件系统需要达到的性能指标。需求验证是在指定需求规范化后对需求进行验证的活动。需求验证包括：①确定所有的模糊需求②确定每条需求的来源③说明需求数量④确定需求之间的依赖关系⑤验证需求是否简明、可测试并且可跟踪⑥验证需求与软件系统中的约束是否有冲突
8.软件需求规格化（SRS）是详细分析任务后产生的文档。~必须提供信息：软件系统定义、SRS文档的用途、软件系统的范围、功能性需求、非功能性需求、目标软件系统的运行条件 9.角色有关的关系：泛化~： 存在于有类似的行为和特性的角色之间继承关系。关联~： 显示用例与角色之间通信关系。
10.用例关系图：①显示目标软件系统的用例和角色之间的交互关系②显示用例之间或角色之间的关系（如关联和泛化等）。用例可以（文本方式，事件流方式）描述外部角色与软件系统之间的交互过程。用例之间的关系：①扩展：指通过获取其它用例的某些功能来建立当前用例的方式扩展关系的箭头方向指向要被扩展的用例②包含：指一个用例的功能包含在另一个用例的功能中。包含关系里箭头指向被包含在另一个用例中的用例。 11.类关系图表示类、接口、以及它们之间的关系。对象关系图表示类的特定实例的属性值以及对象之间的关系。类的属性和操作的可见性是：+ :表示属性或操作对于其它类可见。-：表示属性或操作对其它类不可见。#：表示基类的属性或操作仅对它的派生类可见。~:表示属性或操作只对同一个包里的类是可见的。类和对象之间的关系：①关联：表示两个类的对象之间一般上的逻辑意义上的联系。②聚合：表示两个类之间的整体与局部的关系③组合：表示两个类之间的整体与局部的关系④依赖性：表示两个类的对象之间一般上的动态功能上的联系⑤泛化：表示父类与子类之间派生关系⑥实现：表示类关系图里两个元素之间的语义关系，其中一个元素定义一个协议，另一个元素实现这个协议。 12．抽象类是没有任何直接实例的类， 继承于抽象类的类可以有直接实例，用于定义一组子类的公共特征和公共行为。接口是一组用于表示由类或组件提供的服务的操作集合，只能提供公共方法的声明，而不能提供这些公共方法的实现，不可以创建接口的对象。两者的相同处：①抽象类和接口都提供方法的规范，但是都不允许您直接创建实例。②抽象类和接口中指定的方法实现都在派生类中提供。不同处：①接口使您能实现多继承，因为一个类可以实现多个接口。但是，抽象类不支持多继承。一个类无法继承多个抽象类②抽象类包含的属性和方法可以是公共的、私有的或受保护的。接口只包含方法③抽象类可提供一部分方法的定义但接口不提供任何定义④抽象类在同一个包内使用，而接口可以跨多个包里实现。接口继承与抽象类继承的区别：①接口继承可多继承，而抽象类继承不行②接口继承中全是抽象方法，不提供定义，而抽象类继承中可有方法定义。
13.交互关系图：描述软件系统的成分如何彼此交互以实现系统用例的功能。~有两个部分：①协作者：描述交互关系图中参与交换的系统静态部分②交互：描述交互关系图中静态部分是怎样参与动态协作的。常用的交互关系图有：①序列关系图：以一组按时间顺序排序的消息的形式表示对象之间的交互②通信关系图：以消息的形式表示对象间的交互
14.包关系图用于描述软件系统的各个包以及包之间的关系。使用包来建模软件系统成分的好处有：①以可视化的方式显示功能组以及它们之间的关系②使得大型软件系统易于管理。 用例分包规则：①以可视化的方式显示功能组以及它们之间的关系② 使得大型软件系统易于管理。类分包~：①具有相同继承层次结构的类分组在一个包里②具有复合关系的类分组在一个包里③将相互协作、彼此交互的类分组在一个包里。
15.组件:实现一组规定接口功能的可执行部件。组件实现了一组接口。 组件类型：①部署组件：描述可执行系统最终可部署部件②工作产品~：描述工程软件有哪些文件组成③执行~：描述可执行软件有哪些可执行部件组成
16.框架和模式是使软件构件可重用的标准。框架：特定领域中类似应用程序的通用功能的模板，增加可重用性和减少应用程序开发时间。其特性：①类或组件的集合，具有执行一些特定或通用的功能②包含一些预定义规范的抽象和具体类接口③可以可通过子类化来扩展和实现这些抽象类和接口④定义一些抽象方法，这些方法接收系统中预定义的消息。模式：
新建的系统能满足可重用的要求，有助于软件组件之间更好的通信。~类型：通用职责分配软件模式（GRASP）、四人组模式(GoF) 单例模式：允许创建它自身的唯一一个实例的类。对于有些类只应许创建一个实例对象。 用静态数据成员来定义单件模式，以跟踪所创建对象的生命期。设计模式好处：①可让你创建能满足新需求的可重用的解决方案而无需修改现有系统。②有助于软件组件之间更好的通信。③有助于设计的重用、提供最有效的问题解决方案、给类分配职责。
17.实施质量流程的目的是为了在软件开发过程中检查所开发的软件模型和产品的质量。质量流程包括：①用于开发软件系统的软件开发过程的质量②软件开发过程中使用的软件模型的质量③软件开发过程结束时获得的软件产品的质量④质量流程自身的质量。生产质量过硬的产品时需要考虑的维度是：①技术：描述软件开发过程所需的工具以及生成的输出② 方法：描述软件开发过程期间需要执行以生成输出的操作顺序③社会学：描述软件开发过程所需的人力资源、环境条件和技能。质量保证技术检查：语法：确保软件模型使用正确的语法。 语义：确保软件模型表达出目标意图并确保软件模型的表示在项目中一致。 美观：确保软件模型对称并且完整。UML提供的三种扩展元素为：构造型：扩展 UML 词汇表约束：扩展 UML 构造块的语义关系。标记值：扩展 UML 构造块的属性
18静态建模：它表示软件系统的静态或结构成分。它包括类关系图和对象关系图。它有助于描绘系统成分之间的关联和依赖性。动态建模：它表示软件系统静态成分的行为过程。它包含交互、活动和状态关系图。它有助于表达系统在一段时间内的行为流程。
推荐第8篇：UML实验报告[推荐]
《OO & UML》实验报告
班级：
学号：
姓名：
1
实验一
业务建模
一、实验目的
二、实验内容
三、实验过程和结果分析
四、总结
1． 实验内容总结 2． 心得体会
推荐第9篇：uml报告总结
UML课程设计总结
这几周的课程设计，是对课本知识的总结和巩固，使我对UML的几种图有了更深刻的理解，明白了这些图分别表达的意思以及各图的优缺点，还有它们对于程序设计的作用。 熟悉了VS中建模，熟悉了VS中控件的意义，对UML有了更深刻的了解。下面是我在每一个图的学习中的一些心得和体会
在项目设计阶段，我觉得顺序图，活动图，状态图比较重要。顺序图在这些图例里比较直观，用户能很快参与到讨论中，活动图和传统的流程图类似，也是一个补充。状态图在对关键对象是一定要做状态分析的，经常会在做分析的时候发现一些容易被忽视的问题。类图在设计阶段可以用。
深刻体会了UML在建模中关系和作用。UML可以为面向对象的开发系统进行说明，是的复杂的系统和功能，逻辑关系，类之间的关系可视化。用例图帮助我们从宏观上认识了学生选导师系统的软件结构。状态图，时序图，类图帮助我们从微观上认识了这个系统的结构和关系。
画用例图是我第一次使用VS建模，对VS中的一些工具还很生硬，仅仅知道跟着指导书来进行建模。但经过一定的练习，也有了一定的收获和体会，使我了解了用例图的组成，作用以及使用场合；掌握了用例之间的各种关系；知道了用例建模主要要了解各个图形所代表的意义，用例还可以进行下一集的描述，进行下一步的深化。
对于建模过程中遇到的问题通过上网查资料，问同学并和他们进行讨论，得到了比较满意的解决，避免了自己眼高手低，从实践中发现自己的不足，并及时改正。更让我明白，UML的知识是十分丰富的，我现在的认识还不够，我将会在以后的学习中，不断提高自己的UML知识，更好地让UML为将来的编程设计服务。
进一步加强和提高了文档的编写能力
增强了写作能力和团队精神
推荐第10篇：UML练习题1
1．UML的系统分析进一步要确立的三个系统模型是（对象静态模型）、对象动态模型和系统功能模型。
2．UML的的客户需求分析、系统分析和系统设计阶段产生的模型，其描述图符（完全相同 ）。
3．类和对象都有属性，它们的差别是：类描述了属性的类型，而对象的属性必须有（ 具体值 ）。
4．UML系统分析阶段产生的包图描述了系统的（系统体系层次结构）。
1．在UML软件开发过程系统分析阶段产生的对象模型有三种模型。它们是：对象的静态 模型、对象的 动态模型和对象的 系统功能 模型。 2．在UML的对象类图中，类之间的关系有 泛化、实现、聚集、依赖和关联 5种。
3．共享聚集的“部分”对象可以是任意“整体”对象的一部分，表示事物的整体/部分关系较弱的情况，“整体”端的重数应该是n。 4．在UML软件开发过程的需求分析和系统分析阶段，建立对象类模型的步骤分为 寻找确定对象类、定义类的接口、定义类之间的关系、建立对象类图 和 建立系统包图 。
5．组合聚集是指“整体”拥有它的“部分”，它具有强的物主身份，表示事物的整体/部分关系较强的情况。“部分”生存在“整体”中，不可分离，它们与“整体”一起存在或消亡。“整体”的重数必须是1。
1．封装是指把对象的（属性和操作）结合在一起，组成一个独立的对象。
2．封装是一种（ 信息隐蔽）技术，目的是使对象的生产者和使用者分离，使对象的定义和实现分开。
3．面向对象方法中的（继承）机制使子类可以自动地拥有（复制）父类全部属性和操作。
4．使得在多个类中能够定义同一个操作或属性名，并在每一个类中有不同的实现的一种方法是（接口）。
5．UML的软件以（ 类）为中心，以系统体系结构为主线，采用循环、迭代、渐增的方式进行开发。
6．UML的（静态）模型图由类图、对象图、包图、构件图和配置图组成。
7．UML的（动态）模型图由活动图、顺序图、状态图和合作图组成。
8．UML的最终产物就是最后提交的可执行的软件系统和（相应的软件文档资料）。
9．在UML的需求分析建模中，（用例）模型图必须与用户反复交流并加以确认。
1．软件开发模型有 瀑布模型、螺旋模型 和增量模型 等3种主要模型。 2．UML分析和设计模型由三类模型图表示。三类模型图是：模型图和 3．UML开发过程是一种二维结构软件开发过程，软件项目开发过程流包括的核心工作内容是： 分析、设计、实现、测试 和 配置 4．UML视图和构建视图。
5．UML中有10种基本图可以完整地描述出所建造的系统，这10种图是 类图、用力 图、协作 图、顺序 图、状态 图、活动图、构件 图、部署 图、包 图和对象 图。
1．可行性研究分析包括经济可行性分析、技术可行性分析和（法律可行性分析。
2．UML的客户需求分析模型包括（用例）模型、类图、对象图和活动图组成。
3．UML客户需求分析使用的CRC卡上“责任”一栏的内容主要描述类的（属性）和操作。
4．UML客户需求分析产生的用例模型描述了系统的（功能要求 ）。
5．在UML的需求分析建模中，用例模型必须与（用户）反复交流并加以确认。
6．在UML的需求分析建模中，对用例模型中的用例进行细化说明应使用（活动图。 7．活动图中分劈和同步接合图符是用来描述（多进程的并发处理行为。
1．软件项目的可行性研究分析中，技术可行性研究包括 经济、技术、法律 3部分组成。 2．在UML软件开发过程的需求分析阶段，建立用例模型的步骤分为确定系统的边界和范围、确定系统的执行者和用例、对用例进行描述、定义用例之间的关系 和审核用例模型 。
3．用例图中以实线方框表示系统的范围和边界，在系统边界内描述的是 用例 ，在边界外描述的是执行者 。
4．用例模型中的执行者可以是 人 也可以是 外部系统 。
5．用例模型中的用例之间的关联有关联、关联、关联和关联。
第11篇：UML实验报告总结
实验一 熟悉Rational Rose及建立用例模型 实验
二、时序图和协作图建模
实习三 UML类图与包图建模（2学时） 实验四 状态图和活动图建模 实验五
组件与部署图
实验一 熟悉Rational Rose及建立用例模型
（2学时）
一、实验名称：熟悉（2学时）
二、实验目的与要求：
了解和掌握Rose建模工具的使用 掌握怎样进行案例需求分析； 掌握UML用例图建模技术
三、实验内容：
1、熟悉rose上机环境及设置
2、根据以下谈话设计出用例图
Rational Rose及建立用例模型
四、实验步骤：
见实验说明书
实习二 （2学时）
一、实验名称：
时序图和协作图建模（2学时）
二、实验目的与要求：
了解和掌握Rose或Visio建模工具的使用
掌握怎样进行系统分析，并进行UML静态建模分析； 掌握UML时序图和协作图建模技术
三、实验内容：
根据以下谈话设计出时序图和协作图建模。
四、实验步骤：
、
UML类图与包图建模（2学时）
一、实验名称：UML类图与包图建模（2学时）
二、实验目的与要求：
了解和掌握Rose或Visio建模工具的使用
掌握怎样进行系统分析，并进行UML动态建模分析；
三、实验内容：
四、实验步骤：
实习四 （2学时）
一、实验名称：
状态图和活动图建模（2学时）
二、实验目的与要求：
了解和掌握Rose或Visio建模工具的使用
掌握怎样进行系统分析，并进行UML动态建模分析； 掌握UML状态图和活动图建模技术
三、实验内容：
四、实验步骤：
实习五
组件与部署图与代码生成 （2学时）
一、实验名称：
组件与部署图（2学时）
二、实验目的与要求：
三、实验内容：
四、实验步骤：
第12篇：UML实验指导书
UML实验指导书
前言
UML技术是一门实践性很强的课程，必须十分重视加强实验教学。UML技术实验课的目的是进一步巩固和加强理论知识，培养基本应用和建模工具操作技能，提高解决实际问题的能力。
为了达到上述目的，根据我系UML技术的教学大纲及实际情况编写了该实验指导书。全书共分7个实验，每个实验包括有：实验目的、实验器材、实验内容和步骤、实验报告要求
等项目。
１
UML实验指导书
目录
实验一 用例图 ...............................................................................................................................３ 实验二 交互图 ...............................................................................................................................４ 实验三 类图 ...................................................................................................................................５ 实验四 数据建模 ...........................................................................................................................６ 实验五 活动图 ...............................................................................................................................７ 实验六 状态图 ...............................................................................................................................８ 实验七 组件图和部署图 ...............................................................................................................９
２
UML实验指导书
实验一 用例图
一、实验目的
1． 熟悉用例图的基本功能和使用方法。 2． 掌握如何使用建模工具绘制用例图方法。
二、实验器材
1.计算机一台；
2.Rational Rose 工具软件；
三、实验内容
根据以下需求设计一个图书馆管理系统的用例图。 基本功能要求：
图书管理：新书登记，图书查询，图书注销； 借阅管理：借书，还书，查询今日到期读者；
读者管理：增加读者、删除读者、查询读者、读者类别管理（可以设置不同类的读者，并使不同类读者对应不同类的图书流通参数，如可借册数，可借天数，可续借次数，可续借天数等）；
报表管理：包括图书借阅统计报表，被注销图书统计报表等；报表可以有多种格式可供选择；可以把报表输出到文件中，可以预览报表、打印报表等。
系统管理：系统管理员使用，包括用户权限管理（增加用户，删除用户，密码修改等），数据管理（提供数据修改、备份、恢复等多种数据维护工具），系统运行日志，系统设置等功能。
四、实验步骤
详细分析系统需求，使用Rose工具完成系统用例图。 （1）分析系统活动者 （2）分析系统活动者的用例
（3）分析活动者之间、用例之间的关系 （5）绘制用例图
五、实验报告要求
1． 整理实验结果。 2． 小结实验心得体会。
３
UML实验指导书
实验二 交互图
一、实验目的
1．理解顺序图的基本概念； 2.理解协作图的基本概念；
3.掌握在Rational Rose中绘制交互图的操作方法。
二、实验器材
1.计算机一台；
2.Rational Rose 工具软件；
三、实验内容
根据图书馆管理系统的需求分析和用例图，完成系统的交互图，对用例进行动态建模。
四、实验步骤
1.分析：根据图书馆管理系统的需求分析和用例图，对系统中的用例进行动态建模。2.请根据教材中示例部分在Rational Rose中绘制上述的交互图。
五、实验报告要求
1． 整理实验结果。 2． 小结实验心得体会。
４
UML实验指导书
实验三 类图
一、实验目的
1．理解类的基本概念；
2.掌握如何从需求分析中抽象出类的方法；3.掌握在Rational Rose中绘制类的操作方法。
二、实验器材
1.计算机一台；
2.Rational Rose 工具软件；
三、实验内容
根据图书馆管理系统需求分析、用例图、交互图，对系统进行静态建模，寻找和发现类，分析类之间的关系。
四、实验步骤
1．打开前面初步构建的UML模型文件; 2．打开Rose中的逻辑视图（Logical View），选择分析模型（analysis model）目录。并在其下创建一个子目录并命名为：“图书馆业务功能”。
3．用鼠标右击“图书馆业务功能”在弹出来的菜单中选择“New→Cla diagram”项，创建类图。
4．双击新建的类图，并点右边控件集中选中的类并用鼠标在图中分别拖出上述类图。 5．设定上述抽象出来各类的属性和操作。 6．分析、设定以上各类之间的关系。
7．请根据教材中示例部分在Rational Rose中绘制类间的关系。
五、实验报告要求
1． 整理实验结果。 2． 小结实验心得体会。
５
UML实验指导书
实验四 数据建模
一、实验目的
1．数据建模的基本概念
2．掌握在Rational Rose中进行数据建模。
二、实验器材
1.计算机一台；
2.Rational Rose 工具软件；
三、实验内容
根据图书馆管理系统需求分析、类图系统进行数据建模。
四、实验步骤
1.创建 Database，Database建模元素在component view中创建。 2.创建 Schema，在logical view中创建schema，并选定目标数据库。
3.创建 Domain Package和Domain，在logical view中创建，先创建Domain Package，再创建Domain。
4.创建 Data Model Diagram，在schema下创建。 5.创建 Table，在Data Model Diagram中建表。 6.创建 Column，在表上建立列。
7.创建 Relationship，在表与表之间建立关系,，有两种关系，即non-identifying (非确定性)关系和 identifying (确定性)关系
8.Normalizing the Data Model，创建了数据模型后，还要将模型规范化，如转换为3NF。
9.Optimizing the Data Model，如创建索引，视图，存储过程，denormalization，使用domain等。
10.Implementing the Data Model，利用Rose产生DDL或直接在数据库中建立表。
五、实验报告要求
1． 整理实验结果。 2． 小结实验心得体会。
６
UML实验指导书
实验五 活动图
一、实验目的
1． 熟悉活动图的基本功能和使用方法。 2． 掌握如何使用建模工具绘制活动图方法。
二、实验器材
1.计算机一台；
2.Rational Rose 工具软件；
三、实验内容
根据图书馆管理需求分析、用例图、类图等，应针对每个用例进行业务分析，说明其具体的业务流程，完成系统活动图活动图。
四、实验步骤
以“删除读者信息”用例为例，说明绘制活动图的步骤。 1．管理员在录入界面，输入待删除的读者名；
2．“业务逻辑”组件在数据库中，查找待删除的读者名；
3．如果不存在，则显示出错信息，返回步骤（1），如果存在则继续； 4．“业务逻辑”组件判断“待删除的读者”是否可以删除；
5．如果不可以，则显示出错信息，返回步骤（8），如果可以则继续； 6．在数据库中，删除相关信息； 7．显示删除成功信息； 8．结束。
五、实验报告要求
1． 整理实验结果。 2． 小结实验心得体会。
７
UML实验指导书
实验六 状态图
一、实验目的
1．理解什么状态和状态图； 2.学会使用UML绘制状态图；
二、实验器材
1.计算机一台；
2.Rational Rose 工具软件；
三、实验内容
根据图书馆管理系统的需求分析、用例图和相应的活动图，从对象的动态行为的角度去描述系统的业务活动，完成系统的状态图。
四、实验步骤
1.业务分析：由前面章节对图书馆管理系统中的还书业务的描述和分析可知，还书业务的动态行为是由：空闲（idle）、图书查找（finding）、还书（reversion）、失败（Failure）、归还成功（Succe）5种状态及激活相互转换的事件。
2.绘制状态图：请您根据分析运用UML绘制还书用例的状态图。
五、实验报告要求
1．整理实验结果。
2．小结实验心得体会。
８
UML实验指导书
实验七 组件图和部署图
一、实验目的
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类之间互相依赖，
９
UML实验指导书
BorrowerInfomation类和Reservation类之间互相依赖，Reservation类和Title之间互相依赖，Title和Item类之间互相依赖。 绘图步骤：
（1）在组件视图中双击Main图，出现图7.1，为编辑组件图做好准备，这时绘图工具栏中的图标如图中椭圆所示，其中具体含义可参看本节“补充图标”一段的介绍。
图7.1 （2）在组件视图中，从工具栏中选择MainProgram图标，在右边的绘图区中添加一个新组件，并取名StartCla.java表明新增一个主程序。
图7.2 （3）选择新创建的组件，点击鼠标右键，在弹出的菜单中选择“Open Sepcification”,弹出图7.3对话框。
１０
UML实验指导书
（4）在对话框中，可以修改组件的名称，设置组件的类型，指定实现的语言。这里新组件的名称定为“StartCla.java”，组件构型为Main Program（Rose中提供了多种构型，大部分在补充图标一段中均有简单的介绍），实现语言为JAVA（Rose中默认的是分析语言Analysis），修改结果如图7.4所示。
图7.3
图7.4 （5）组件图描述的是系统的实现视图，因此要指定实现组件功能的文件。点击File
１１
UML实验指导书
选项卡，在列表框中点击鼠标右键，在弹出的菜单中选择“Insert File”，弹出文件对话框。在对话框中，键入StartCla.java，点击“打开”按键，这时对话框如图7.5所示。
图7.5 （6）双击StartCla.java，弹出是否创建对话框，询问是否创建文件，选择“YES”,弹出记事本，这时可输入相应的源程序（注意：如果这里选择的文件已经存在，则不会弹出创建文件对话框，而是直接显示相应文件内容）。
（7）创建相应的包。选择包图标，在右图中创建。这里同样需要对每个组件打开“Open Specification”对话框，设置具体的属性，对“包”组件来说需要在Files选项卡中指明与其对应的目录。创建完毕的组件图如图7.6所示。
图7.6 （8）选择业务对象包（BO），双击，打开业务对象包的详细组件图，这里根据分析的结
１２
UML实验指导书
果分别创建Title.java,Item.java，Loan.java，BorrowerInfomation.java，Reservation.java组件，并设置好每个组件的构型和对应的文件。创建好的BO包组件图如图7.7。
图7.7 （9）创建依赖关系。在本节“关系”一段中，已经描述过依赖关系使用虚线表示，因此根据分析中的结果，在图中将相互依赖的组件连接即可。完成后的组件图如图7.8。
图7.8 2.绘制部署图 分析：
HNS的图书管理系统目前开发的是一个单机版系统，其中所有的运算均在一台机器上完
１３
UML实验指导书
成，但是由于打印报表的需要，系统还应配备一台打印机。因此得出系统中存在2个节点：
① 一台主机，其类型是Proceor。 ② 一台打印机，其类型是Device。 绘图步骤：
（1）浏览窗口中选择“Deployment View”,弹出如图7.9所示窗口：
图7.9 （2）在图中添加分别添加一个Proceer和Device，并分别命名为“computer with java support”和“Printer”，添加完毕后，其结果如图7.10所示：
１４
UML实验指导书
图7.10 （3）为节点添加连接关系。全图如图7.11。
图7.11
五、实验报告要求
1． 整理实验结果。 2． 小结实验心得体会。
１５
第13篇：UML综合实例
统一建模语言UML轻松入门之综合实例
在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。我们在日常生活中也经常和ATM打交道。本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。
5.1用例图
参与者\"银行储户\"和ATM机。简化后的ATM机仅有取款、存款及其余功能。其余功能不做详细说明。
图5.1 自动取款机（ATM）系统用例图
银行储户在ATM机上完成取款、存款及其他业务。
5.2类图
图5.2所示的银行系统类图和图3.5是类似的，只是将工作人员换成了ATM。整个银行系统包括了帐户库、银行储户库及ATM系统。
许多单个的帐户组成了帐户库。帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。
setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。
getType获取帐户类型，返回类型为char，无参数。
setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。
getAccountNumbe获取帐户号，返回类型为int，无参数。
caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。
getBalance获取帐户余额，返回类型为double，无参数。
许多银行储户组成了储户库。ATM系统包含了许多ATM机。银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。更多的属性及操作都可以一一加上，使这个类图更详细更完整，从而使参与项目的每个成员都能无歧义的明了整个设计的类的结构。同样对于一个真正的银行系统，这个类图过于简单。比如帐户类型我们可以先定义一个abstract cla，它包含一个帐户最基本的属性及操作。而有些操作先定义为abstract，如余额的计算。然后再继承这个abstract cla，我们可以有saving account 和checking account等等。不同的帐户有不同的余额计算方法，我们可以加上具体的算法。对于不同的帐户可能还有一些它特有的操作，我们也可以加上，比如saving account在存款达到多少时可以享受机票打折的优惠。通过类图不仅可以使设计者明确的表达自己的设计意图，也能帮组自己整理思路，充实及优化自己的设计。
图5.2 银行系统类图
5.3顺序图
图5.3描述了顾客在ATM机上取款时信息的流动情况。以时间为顺序。因为仅是示例，所以整个过程是没有出现任何故障时的流程，并且只画到了取款结束。通过这个图，我们可以看出消息是如何在系统中不同对象之间进行交互。
通过流程图我们可以很清楚地看到系统是如何工作的，系统各部分之间的信息及控制是如何发送的，整个流程是否合理。流程图对我们的设计起到了很好的帮助作用。注意在本图没有一个生命线终端有一个\"X\"，这是因为这个流程中还未遇到有对象生命结束。当有对象生命结束时需在对应的生命线终端画\"X\"，表明这个对象在这时被销毁。
首先银行储户将ATM卡插入读卡机，读卡机将信息传给客户管理，客户管理提出查询密码，显示部分将输入密码请求显示出来…..因为这个顺序图较长，且很清晰，即便是初学者也很容易读懂，在此就不对本图做过多的解释。
图5.3 ATM取款顺序图
5.4状态图
图5.4描述了顾客在ATM机上进行操作会经历的几种状态，及各种状态之间转换的条件。因为是简
化了的例子，所以除了等待顾客插入磁卡的起始状态和结束服务的终止状态，顾客会处于输入密码、选择服务类型、存款及取款四种状态。
图5.4 ATM状态图
插入磁卡后进入输密码状态，当密码输入正确时进入选择服务类型状态，当输入密码不正确时，停留在原状态，但如果三次不正确，服务结束。进入选择服务类型后根据选择的不同，顾客可进入存款和取款状态。存、取款结束后，顾客既可以选择结束服务到最终状态，也可以选择继续服务回到选择服务类型状态。
通过状态图我们可以无歧义的了解各个活动角色是如何在不同状况下转换的，转换的条件是什么，是否会出现死锁现象，是否有条件没考虑周全，是否有状态无法达到。状态图可以帮助我们发现问题，并及时改正。
5.5活动图
图5.5参考了Randy Miller的《A Hands-On Introduction for Developers》一文，5.3图中的客户管理和事物管理对应于5.5图中的Bank，图5.3中的读卡机、显示、输入设备及点钞机对应于5.5图中的ATM Machina，银行储户就是Customer。初看活动图和顺序图表达的意义很接近。但我们可以注意到顺序图着重时间的顺序，而活动图侧重于各部分之间的相互制约，对于一些并行的活动能够有效的表示出来。例如5.5图中fork和join处，我们可以很清楚的看到一些并行活动的存在。
这个活动图以顾客插入卡为开始，以顾客取卡结束。我们可以看到活动图的重点虽然不在时间顺序，但我们同样可以得到时间的信息。
图5.5 ATM银行系统活动图
5.6协作图
在第四章中我们知道协作图和顺序图是可以无信息损失的相互转换，只是它们的侧重点是不一样的。顺序图着重于对象间消息传递的时间顺序，协作图着重于表达对象之间的静态连接关系。图5.6将5.3图转换为协作图。
1．插入ATM卡
2．接受ATM卡
3．查询密码
4．显示输入密码请求
5．输入密码
6．密码传递
7．请求确认密码合法性
8．确认密码合法性
9．询问服务类别
10．显示输入服务服务类别请求
11．输入取款请求
12．取款请求
13．询问取款数额
14．显示输入数额请求
15．输入取款数额
16．传递取款数额
17．询问取款数额确认
18．显示确认数额请求
19．输入确认
20．传递确认信息
21．数额合法性确认请求
22．确认数额和法性
23．出钞请求
24．计算帐户余额
25．出钞
26．取钞
27．传递余额并询问是否还需要其他服务
28．显示帐户余额并提示选择下面的服务
图5.6 ATM系统协作图
从图上我们可以看出协作图的角色和顺序图的对象是一一对应的，而协作图上的各对象上的协作关系和顺序图上的消息传递是一一对应的。
销售管理系统的UML分析与设计
系统约定：用UML描述工作流管理 基于UML的系统分析方法研究
UML结合车载GPS终端系统的设计在嵌入式系统设计中的应用
http://www.daodoc.com/TZGTWHXCla_1_4.aspx
第14篇：UML建模优缺点
1.UML的优点：
UML语言使系统建模过程标准化，统一化，规范化。
UML在整个软件开发过程中采用相同的概念和表示方法，在不同的开发阶段，不必转换概念和表示方法，避免了传统软件开发方法的两个鸿沟。
UML采用图形化的表现形式。产生的模型易于理解，易于开发人员与用户之间的沟通，从而能够及时得到用户的反馈信息。
用UML进行系统建模所得到的建模制品不仅仅包括各种模型框图，还有大量丰富的文档，这些文档给系统后期的维护工作带来了便捷。 UML不是一门程序设计语言，但可以使用代码生成工具将UML模型转换为多种程序设计语言代码，或使用反向生成工具将程序源代码转换为UML模型。 2.UML的缺点：
任何事物都有正反两个方面，UML这种新兴的建模工具也存在它本身的一些不足，总结如下：
无法从语法上建立状态图与顺序图的关系。
无法从语法上建立活动图与顺序图在流程描述中的关系。 协作图和顺序图中与消息相伴的参数不能与类图建立关系。
第15篇：UML实验二
实验2 用例图
一、实验目的
1.学会分析系统中的参与者和用例 2.掌握用例图的绘制方法 3.掌握需求分析阶段的用例建模
二、实验器材
1. 计算机一台；2. StarUML工具软件。
三、实验内容
1.画出ATM系统的用例图 2.完成ATM系统用例的事件流描述 3.完成网络教学系统的用例建模 4.完成学生课程注册系统的用例建模
四、ATM系统的用例建摸
1.分析
ATM自动取款机：客户可以取钱，存钱，查询余额，转帐，修改密码。 通过分析可找出如下几个参与者： （1）ATM （2）客户
通过分析得到如下用例：
（1）存款 （2）取款 （3）查询余额 （4）转帐 （5）修改密码 （6）打印收据 2．绘图步骤：
下面介绍在StarUML中创建用例图的过程：
（1）在“Use Case View”中双击Main图，双击图标，出现图1，为编辑用例图做准备。
图1 （2）在用例视图中，从工具栏中选择Actor图标，在右边的绘图区中添加一个新元素，并取名客户表明新增一个参与者，如图2所示。
图2 （3）同样的方法添加参与者“ATM”,如图3所示。
图3 (4)在工具栏上选择用例的图标，依次添加存款、取款、查询余额、转帐、修改密码、打印收据，如图4所示。
图4 （5）添加参与者和用例间的关联关系，如图5所示。
图5 依照个人理解，增加一些功能或修改该用例图。 （增加的功能或修改的用例图放在此处）
参照如下的取款用例的事件流描述，给出ATM系统的其它用例的事件流描述。
1） 通过读卡机，储户插入ATM卡
2） ATM系统从卡上读取银行ID、帐号、并验证帐号。 3） 储户键入密码，系统检验密码。 4） 储户按确认键，输入取款金额。
5） ATM把帐号和取款金额传递给银行系统，取回帐户余额。 6） ATM输出现金，并显示帐户余额。 7） ATM记录事务到日志文件。
（ATM系统的其它用例的事件流描述放在此处） 登录用例的事件流：
1） 通过读卡机，储户插入ATM卡
2） ATM系统从卡上读取银行ID、帐号、并验证帐号。 3） 储户键入密码，ATM系统检验密码。 4） 储户进入ATM系统 存款用例的事件流：
1） 通过读卡机，储户插入ATM卡
2） ATM系统从卡上读取银行ID、帐号、并验证帐号。 3） 储户键入密码，系统检验密码。 4） 储户选择存款事务 5） 储户添加存款金额 6） ATM系统验证钞票
7） ATM系统显示储户存款金额 8） 储户确定储户存款金额
9） ATM把帐号和存款金额传递给银行系统，更新账户金额 10） ATM记录事务到日志文件。 查询余额用例的事件流：
1） 通过读卡机，储户插入ATM卡
2） ATM系统从卡上读取银行ID、帐号、并验证帐号。 3） 储户键入密码，系统检验密码。 4） 储户选择查询事务
5） ATM系统显示账户余额 转账的事件流：
1） 通过读卡机，储户插入ATM卡
2） ATM系统从卡上读取银行ID、帐号、并验证帐号。 3） 储户键入密码，系统检验密码。 4） 选择转账事务 5） 储户输入转账账号
6） ATM系统验证转账账号 7） 储户输入转账金额
8） ATM系统验证输入金额是否符合输入要求 9） ATM系统验证储户账户余额 10） ATM系统显示储户转账账户及转账金额 11） ATM记录事务到日志文件。 修改密码用例的事件流：
1） 通过读卡机，储户插入ATM卡
2） ATM系统从卡上读取银行ID、帐号、并验证帐号。 3） 储户键入密码，系统检验密码。 4） 选择修改密码事务
5） 储户输入旧密码，ATM系统验证账户旧密码 6） 储户输入2次新密码，确认输入密码 7） ATM系统更新储户的密码为新密码 8） 储户修改密码成功 查询历史记录用例的事件流：
1） 通过读卡机，储户插入ATM卡
2） ATM系统从卡上读取银行ID、帐号、并验证帐号。 3） 储户键入密码，系统检验密码。 4） 选择查询历史事务记录用例
5） ATM系统查询并显示相关的信息 打印数据用例的事件流：
1） 通过读卡机，储户插入ATM卡
2） ATM系统从卡上读取银行ID、帐号、并验证帐号。 3） 储户键入密码，系统检验密码。 4） ATM系统核实操作 5） 系统提示是否打印数据 6） 储户确认打印数据 7） 返回主界面
五、根据下属需求，分析参与者和用例，并建立网络教学系统的用例图，给出各用例的事件流描述。
网络教学系统的功能需求主要包括以下几个方面：
① 学生可以登录网站浏览信息、查找信息和下载文件。
② 教师可以登录网站输入课程简介、上传课件文件、发布消息、修改和更新消息。 ③ 系统管理员可以对页面维护以及批准用户的注册申请。 （建立的网络教学系统的用例图放在此处）
（各用例的事件流描述放在此处） 学生浏览信息用例的事件流：
1） 学生输入账号、密码
2） 网络教学系统验证账号、密码是否正确 3） 进入网站主页界面 4） 浏览到相关的信息 学生查找信息用例的事件流：
1） 学生输入账号、密码
2） 网络教学系统验证账号、密码是否正确 3） 进入网站搜索界面 4） 输入关键词进行搜索 5） 找到自己所需要的信息 学生下载文件用例的事件流：
1） 学生输入账号、密码
2） 网络教学系统验证账号、密码是否正确 3） 进入下载文件界面 4） 查找到相关信息 5） 保存在指定的硬盘 6） 确定下载
教师输入课程简介用例的事件流：
1） 教师输入账号、密码
2） 网络教学系统验证账号、密码是否正确 3） 进入课程简介界面 4） 增加课程简介 5） 保存课程简介 6） 确定输入成功
教师上传课件用例的事件流：
1） 教师输入账号、密码
2） 网络教学系统验证账号、密码是否正确 3） 进入上传课件界面 4） 选择上传的课件 5） 确定上传课件
教师发布、修改、更新消息用例的事件流：
1） 教师输入账号、密码
2） 网络教学系统验证账号、密码是否正确 3） 进入发布、修改、更新的消息界面 4） 填写好要发布、修改、更新的消息 5） 保存要发布、修改、更新的消息 6） 确定消息
系统管理员页面维护用例的事件流：
1） 系统管理员输入账号、密码
2） 网络教学系统验证账号、密码是否正确 3） 系统管理员进入页面维护界面 4） 修改相关页面
5） 保存修改过的相关页面 6） 确定修改相关页面
系统管理员批准用户的注册申请用例的事件流：
1） 系统管理员输入账号、密码
2） 网络教学系统验证账号、密码是否正确 3） 进入用户的注册申请界面 4） 审核相关用户注册的信息 5） 保存相关用户注册的信息 6） 确定用户的注册申请通过
六、请根据以下需求画出学生课程注册系统的用例图。
某大学准备开发一个学生课程注册系统，学生可以使用该系统查询新学期将开设的课程和讲课教师情况，选择自己要学习的课程进行登记注册，并可以查询成绩单；教师可以使用该系统查询新学期将开设的课程和选课学生情况，并可以登记成绩单；注册管理员使用该系统进行注册管理，包括维护教师信息、学生信息和课程信息等。
在每个学期的开始，学生可以获得该学期的课程目录表，课程目录表列出每门课程的所有信息，诸如基本信息、教师、开课系和选课条件等。
新学期开始前两周为选课注册时间，在此期间学生可以选课注册，并且允许改变或取消注册申请，开学两周后注册管理员负责关闭课程注册。每个学生可以选择不超过4门课程，同时指定2门侯选课程以备主选课程未选上。每门课程最多不能超过10人，最少不能低于3人，低于3人选课的课程将被取消。一旦学生的注册过程完毕，注册系统将有关信息提交收费系统以便学生付费。如果在实际注册过程中名额已满，系统将通知学生在提交课程表之前予以更改。
在学期结束时，学生可以存取系统查看电子成绩单。由于学生成绩属于敏感信息，系统必须提供必要的安全措施以防非法存取。 （将画出的用例图放在此处）
第16篇：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．小结实验心得体会。
第17篇：个人博客UML建模
图书管理系统的分析及设计---应用UML建模
2010 —— 2011 学 年 第 一 学 期
信息技术学院
《软件系统建模与UML》综合设计实验
***系统的UML建模
班
级 学
号 姓
名 任课教师
日
期
2010年12月30日
0 图书管理系统的分析及设计---应用UML建模
目 录
第1章 系统需求 ..............................................2 第2章 需求分析 ..............................................4
2.1 识别参与者 ...........................................4 2.2 识别用例 .............................................5 2.3 用例的事件流描述 ....................................11 第3章 静态结构模型 .........................................16 3.1 定义系统对象 ........................................16 3.2 定义用户界面类 ......................................16 3.3 建立类图 ............................................16 第4章 动态行为模型 .........................................19 4.1 创建系统顺序图（协作图） ............................19 4.2 创建系统的状态图 ....................................19 4.3 创建系统的活动图 ....................................29 第5章 数据库模型 ...........................................31 第6章 物理模型 .............................................32 6.1 创建系统组件图 ......................................32 6.2 创建系统部署图 ......................................33
1 图书管理系统的分析及设计---应用UML建模
第1章 系统需求
系统概述
Blog是一种让编写者可以表达自己意见、发表自己的看法以及见闻的方式。系统目标是使好友之间有一个交流沟通的平台，通过博客可以互相了解彼此的生活状况，系统拥有发布日志，心情，照片，留言评论等功能。
系统功能分析
本Blog系统将完成以下功能：
网站首页功能
用户的注册、登录和登出 个人消息中心管理功能 照片管理功能 相册分类管理功能 文章管理功能 文章分组管理功能 心情管理功能
日志，照片，心情评论管理功能 留言板留言，回复功能 装扮空间功能
2 图书管理系统的分析及设计---应用UML建模
根据以上分析，画出系统功能图（PPT原版）：
3 图书管理系统的分析及设计---应用UML建模
第2章 需求分析
2.1 识别参与者
参与者关系图如图2-1所示：
游客其他会员博主
图2-1 参与者关系图
游客：未注册的用户，只拥有普通浏览功能
注册会员：已注册成为会员，与游客是泛化关系，拥有查看，评论，留言，回复留言评论的功能
博主：博客的拥有者，与会员是泛化关系，拥有查看，评论，回复评论，对自己博客的所有的文章，心情，照片，评论留言具有管理的权限。
4 图书管理系统的分析及设计---应用UML建模
2.2 识别用例
主用例图如图2-2所示：
看文章看相册看心情看留言板日志评论看主人资料图片评论游客看评论回复心情评论留言板留言会员评论文章，照片，心情文章博主修改博客内容照片相册回复、删除留言评论心情管理好友更改装扮
图2-2 主用例图
5 图书管理系统的分析及设计---应用UML建模
管理留言板用例图如图2-3所示：
查看留言游客添加新留言会员回复留言博主删除留言
图2-3 管理留言板用例图
6 图书管理系统的分析及设计---应用UML建模
管理文章用例图如图2-4所示：
查看文章评论查看文章游客添加新评论会员回复评论添加文章博主删除文章修改文章删除评论
图2-4 管理文章用例图
7 图书管理系统的分析及设计---应用UML建模
管理相册用例图如图2-5所示：
查看评论游客查看照片添加新评论会员回复评论上传照片删除照片/修改博主创建相册删除/修改相册删除评论回复评论
图2-5管理相册用例图
8 图书管理系统的分析及设计---应用UML建模
管理心情用例图如图2-6所示：
查看评论游客查看照片添加新评论会员回复评论上传照片删除照片/修改博主创建相册删除/修改相册删除评论回复评论
图2-6 管理心情用例图
9 图书管理系统的分析及设计---应用UML建模
注册登录用例图如图2-7所示：
浏览博客游客注册进入自己博客会员登录访问别人博客
图2-7 注册登录用例图
管理好友用例图如图2-8所示：
添加好友博主删除好友
图2-7 管理好友用例图
更改装扮用例图如图2-9所示：
博主更改装扮
图2-9 更改装扮用例图
10 图书管理系统的分析及设计---应用UML建模
2.3 用例的事件流描述
2.3.1浏览博客用例描述
用例名称：浏览博客用例
用例描述：用户进入自己或者其他会员的博客 参与者：博主，其他会员，游客 前置条件：进入博客 后置条件：退出博客
假设条件：用户已进入网上博客 基本操作流程：
1、进入网上博客
2、查看信息中心，文章，好友心情，相册，留言板等
3、退出网上博客 备选流程：
点击“进入自己博客”可以进入自己博客
2.3.2管理留言板用例描述
用例名称：管理留言板用例
用例描述：博主可以通过此用例添加、删除留言，回复留言
会员可以留言，游客只能浏览 参与者：博主，其他会员，游客 前置条件：成功进入到留言板模块 后置条件：退出留言板模块 假设条件：用户已经进入网上博客 基本操作流程：
1、进入留言板模块
2、博主：添加，删除，修改留言，回复留言
3、会员：添加留言，游客只能查看
3、退出留言板模块
11 图书管理系统的分析及设计---应用UML建模
备选流程：
点击导航超链接可以直接进入其他模块
2.3.3管理文章用例描述
用例名称：管理文章用例
用例描述：博主可以通过此用例添加、删除、修改文章及评论、回复评论
会员可以浏览文章以及进行评论，游客只能浏览 参与者：博主，其他会员，游客 前置条件：成功进入到文章模块 后置条件：退出文章模块 假设条件：用户已经进入网上博客 基本操作流程：
1、进入文章模块
2、博主：添加，删除，修改文章，评论及回复评论
3、会员：浏览文章，添加评论和回复评论，游客只能查看
3、退出文章模块 备选流程：
点击导航超链接可以直接进入其他模块
2.3.4管理相册用例描述
用例名称：管理相册
用例描述：博主可以通过此模块添加、删除、修改相册；添加、删除照片
会员可以浏览相册，照片，以及对照片进行评论；游客只能浏览 参与者：博主，其他会员，游客 前置条件：进入相册模块 后置条件：退出相册模块 假设条件：用户已进入网上博客 基本操作流程： 进入相册模块
游客：查看相册照片，评论，回复
12 图书管理系统的分析及设计---应用UML建模
3、会员：查看相册照片，评论照片，回复评论
4、博主：查看、添加、删除、修改相册、照片、回复评论
5、退出相册模块 备选流程：
点击导航超链接可以直接进入其他模块
2.3.5管理心情用例描述
用例名称：管理心情
用例描述：博主可以通过此用例添加、删除、修改心情，及添加、删除评论、回复评论；
会员可以浏览心情，以及进行评论，回复评论，游客只进行查看 参与者：博主，其他会员，游客 前置条件：成功进入到心情界面 后置条件：退出心情界面 假设条件：用户已进入网上博客 基本操作流程：
1、进入心情界面
2、博主添加，删除，修改心情，添加、删除评论及回复评论
3、会员为心情评论或者回复评论，游客只能查看
4、退出心情界面 备选流程：
点击导航超链接可以直接进入其他模块
2.3.6管理好友用例描述
用例名称：管理好友
用例描述：博主可以通过此模块添加好友 参与者：博主
前置条件：博主已登陆自己博客 后置条件：退出添加好友模块 假设条件：用户已登录自己博客
13 图书管理系统的分析及设计---应用UML建模
基本操作流程：
1、进入管理好友模块
2、选择要添加或者删除的好友的会员名称
3、点击添加或者删除
4、添加或者删除成功
4、退出管理好友模块 备选流程：
点击导航超链接可以直接进入其他模块
2.3.7查看信息中心用例描述
用例名称：查看信息中心
用例描述：博主可以通过此模块更改个人信息
所有用户都可以通过此模块浏览博主信息 参与者：博主，其他会员，游客 前置条件：成功登录到个人信息模块 后置条件：退出个人信息模块 假设条件：用户已进入网上博客 基本操作流程：
1、进入个人信息模块
2、所有会员：查看博主信息
3、博主：更改个人信息
4、退出个人信息模块 备选流程：
点击导航超链接可以直接进入其他模块
14 图书管理系统的分析及设计---应用UML建模
2.3.8装扮博客用例描述
用例名称：装扮博客
用例描述：博主可以通过此模块更改皮肤装扮 参与者：博主
前置条件：博主已登陆自己博客 后置条件：退出装扮模块 假设条件：用户已登录自己博客 基本操作流程：
1、进入装扮模块
2、选择喜欢的皮肤
3、点击装扮，装扮成功
4、退出装扮模块 备选流程：
点击导航超链接可以直接进入其他模块
15 图书管理系统的分析及设计---应用UML建模
第3章 静态结构模型
进一步分析系统需求，发现类以及类之间的关系，确定它们的静态结构和动态行为，是面向对象[7]分析的基本任务。系统的静态结构模型主要用类图和对象图描述。
3.1 定义系统对象
博主：博客的拥有者，拥有博客的所有权限，也可理解为后台管理员或者系统管理员；
前台用户：分为会员和游客
会员：可以查看和评论博主的文章，心情，相册，以及在留言板留言；
游客：只具有查看博主的博客的权限；
3.2 定义用户界面类
通过对系统的不断分析和细化，可识别出下述界面类、类的操作和属性。
16 图书管理系统的分析及设计---应用UML建模
边界类如图3-1所示：
图3-1 边界类图
17 图书管理系统的分析及设计---应用UML建模
3.3 建立类图
实体类图如图3-2所示：
图3-1 实体类图
18 图书管理系统的分析及设计---应用UML建模
第4章 动态行为模型
4.1 创建系统顺序图
文章、心情、照片的添加顺序图如图4-1所示：
: 博主 : 日志管理界面1: 添加日志2: 添加文章信息3: 添加修改成功 : 文章 : 照片管理界面 : 照片 : 心情管理界面 : 心情4: 返回添加成功5: 添加照片信息6: 添加照片7: 添加修改成功8: 返回添加成功9: 添加心情10: 添加心情信息11: 添加修改成功12: 返回添加成功
图4-1 文章、心情、照片的添加顺序图
19 图书管理系统的分析及设计---应用UML建模
文章、心情、照片的删除顺序图如图4-2所示：
: 博主 : 日志管理界面1: 删除日志2: 删除文章信息3: 返回删除成功 : 文章 : 照片管理界面 : 照片 : 心情管理界面 : 心情4: 显示删除成功5: 删除照片信息6: 删除照片7: 返回删除成功8: 显示删除成功9: 删除心情10: 删除心情信息11: 返回删除成功12: 显示删除成功图4-2 文章、心情、照片的删除顺序图
20 图书管理系统的分析及设计---应用UML建模
文章、心情的修改顺序图如图4-3所示：
: 博主1: 修改日志 : 日志管理界面 : 文章 : 心情管理界面 : 心情2: 修改文章信息3: 返回修改成功4: 显示修改成功5: 修改心情6: 修改心情信息7: 返回修改成功8: 显示修改成功
图4-3 文章、心情的修改顺序图
21 图书管理系统的分析及设计---应用UML建模
文章、心情、照片的查看顺序图如图4-4所示：
: 游客1: 查看文章( ) : 未登录浏览页面 : 文章 : 心情 : 照片 : 留言板2: 选择符合添加文章3: 返回要查看的文章4: 返回文章信息5: 查看心情( )6: 选择符合添加心情7: 返回要查看的心情8: 返回心情信息9: 查看照片( )10: 选择符合添加照片11: 返回要查看的照片12: 返回照片信息13: 查看留言板( )14: 选择留言15: 返回留言板16: 返回留言板信息图4-4 文章、心情、照片的查看顺序图
22 图书管理系统的分析及设计---应用UML建模
留言添加、回复顺序图如图4-5所示：
: 会员1: 添加留言 : 留言管理界面 : 留言板 : 留言板回复2: 添加留言3: 返回添加成功4: 显示添加成功5: 继续添加6: 回复留言7: 添加回复8: 添加回复信息9: 返回添加回复信息成功10: 返回添加回复成功11: 显示添加成功12: 继续回复
图4-5留言添加、回复顺序图
23 图书管理系统的分析及设计---应用UML建模
留言删除顺序图如图4-6所示：
: 博主 : 留言管理界面1: 删除留言2: 删除留言信息( ) : 留言板3: 返回删除成功( )4: 显示删除成功5: 继续删除留言( )
图4-6留言删除顺序图如
24 图书管理系统的分析及设计---应用UML建模
登录注册顺序图如图4-7所示：
: 游客1: 登录( ) : 登录界面 : 会员 : 注册界面2: 验证( )3: 返回登陆成功4: 验证( )5: 注册( )6: 返回注册成功7: 再次登录( )8: 验证( )9: 返回登录通过
图4-7登录注册顺序图
25 图书管理系统的分析及设计---应用UML建模
管理好友顺序图如图4-8所示：
: 博主 : 好友管理界面 : 好友1: 添加好友( )2: 添加好友信息3: 返回添加成功4: 显示添加成功5: 删除好友( )6: 删除好友信息7: 返回删除成功8: 显示删除成功
图4-8 管理好友顺序图
26 图书管理系统的分析及设计---应用UML建模
4.2 创建系统的状态图
好友状态图如图4-8所示：
未成好友状态添加好友删除好友成功添加未成功添加好友状态未成功关闭状态
图4-8好友状态图
27 图书管理系统的分析及设计---应用UML建模
会员状态图如图4-9所示：
其他会员游客注册博客会员查看别人博客退出状态查看别人博客登陆自己博客登陆自己博客博主
图4-9会员状态图
文章状态图如图4-10所示：
查看状态关闭不是会员评论回复评论不是博主是会员删除文章评论是博主可编辑状态可修改文章回复文章评论删除文章修改文章添加新文章
图4-9文章状态图
28 图书管理系统的分析及设计---应用UML建模
4.3 创建系统的活动图
管理文章活动图如图4-10所示：
登录自己博客验证密码，用户名是否匹配验证通过删除文章验证未通过失败返回失败结果成功返回成功登录失败退出图4-10管理文章活动图
29 图书管理系统的分析及设计---应用UML建模
登录注册活动图如图4-11所示：
登录验证用户名密码密码错误退出用户名不存在注册不注册注册注册成功用户名不存在输入用户名密码用户名已存在继续注册放弃注册注册失败
图4-11登录注册活动图
30 图书管理系统的分析及设计---应用UML建模
第5章 数据库模型
数据库模型如图5-1所示：
图5-1 数据库模型图
31 图书管理系统的分析及设计---应用UML建模
第6章 物理模型
6.1 创建系统组件图
网上博客组件图如图6-1所示：
会员登陆、注册文章分组文章评论回复心情主程序照片相册留言板好友留言板回复个人消息中心
图6-1 网上博客组件图
32 图书管理系统的分析及设计---应用UML建模
6.2 创建系统部署图
网上博客部署图如图6-2所示：
客户端浏览器WEB浏览器
HTTP浏览器TomCat服务器图6.2 网上博客部署图
33
数据库服务器SQL Server 2008
第18篇：UML考试复习总结
1, 统一建模语言（Unified Modeling Language），简称UML，是一种通用的可视建模语言，用于说明、可视化、构造并文档化软件系统的体系结构.2, 控制软件复杂度的方法：
1)分解，对复杂问题进行分解，然后分别解决各个子问题。
2)抽象，指抽取系统中的基本特性而忽略非基本的特性，以便更充分地注意与当前目标有关的方面。
3)模块化，指解决一个复杂问题时自顶向下逐层把系统划分成若干模块的过程，并遵循高内聚低耦合的原则。
4)信息隐藏，即封装，指把模块内的实现细节与外界隔离，用户只需知道模块的功能，而不需了解模块的内部细节。 3，视图
1) 用例视图。
作用：描述系统的功能需求，找出用例和执行者；描述使用的图：用例图和活动图。 2) 逻辑视图。
作用：描述如何实现系统内部的功能 ；
描述使用的图：类图和对象图、状态图、顺序图、合作图和活动图 。 3) 构件视图。
作用：描述系统代码构件组织和实现模块，及它们之间的依赖关系 ； 描述使用的图：构件图 。 4) 进程视图。
作用：描述系统的并发性，并处理这些线程间的通信和同步 ；
描述使用的图：状态图、顺序图、合作图、活动图、构件图和配置图 。 5) 配置视图。
作用：描述系统的物理设备配置，如计算机、硬件设备以及它们相互间的连接 ； 描述使用的图：配置图 。 4，基本概念
1) 用例是对一个活动者(actor)使用系统的一项功能时所进行的交互过程的一个文字描述序列，是系统、子系统或类和外部的参与者(actor)交互的动作序列的说明，包括可选的动作序列和会出现异常的动作序列。
2) 参与者(actor)是指系统以外的、需要使用系统或系统交互的东西，包括人、设备、外部系统等。
3) 用例图（use case diagram）以图解的形式概括了系统中的不同参与者和用例，并显示了哪些参与者能够参与哪些用例。
4) 类图(Cla diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。 5) 类间关系
(1) 关联(aociation)是模型元素间的一种语义联系，它是对具有共同的结构特性、行为特性、关系和语义的链(link)的描述。一个关联可以有两个或多个关联端(aociation end)，每个关联端连接到一个类。
(2) 聚集和组合：聚集是一种特殊形式的关联。聚集表示类之间整体与部分的关系。聚集关系的实力是传递的，反对称的。组合表示的也是类之间的整体与部分之间的关系，但组合关系中的整体与部分具有同样的生存周期。
(3) 泛化关系：泛化定义了一般元素和特殊元素之间的分类关系，类和类之间的泛化关系就是类与类之间的继承关系。
(4) 依赖关系：假设有两个元素X和Y，如果修改了X元素的定义可能会导致两一个元素Y的定义的修改，则称元素Y依赖于元素X。 6) 接口类：只有方法没有属性，且所有方法只有声明没有实现的类。 7) 边界类控制类和实体类的画法
8) 对象图表示一组对象及他们之间的联系。对象图是系统的详细状态在某一时刻的快照，常用于表示复杂的类图的一个实例。 9) 包就像一个“容器”，可用于组织模型中的相关元素。
10) 包之间可以存在依赖关系，但这种依赖关系没有传递性。 11) 对包的命名有两种方式，即简单包名和路径包名。
12) 构件是系统中遵从一组接口且提供其实现的物理的、可替换的部分。
13) 构件图则显示一组构件以及它们之间的相互关系，包括编译、链接或执行时构件之间的依赖关系。
14) 部署图也成为配置图、实施图，可以用来显示系统中计算节点的拓扑结构和通信路径与节点上运行的软构件等。 15) 交互图，是用来描述对象之间以及对象与参与者之间协作关系以及动态协作关系以及协作过程中行为次序的图形文档。
16) 交互图包括顺序图和协作图两种形式。顺序图着重描述对象按时间顺序的消息交换，协作图着重描述系统成分如何协同工作。
17) 顺序图也称时序图，是显示对象之间交互的图，这些对象是按时间顺序排列的。顺序图是二维模型，在顺序图中水平方向为对象维，沿水平方向排列的是参与交互的对象；顺序图中垂直方向为时间维，沿垂直向下方向按时间递增顺序列出各对象所发出和接受的消息。 18) 顺序图中的消息
(1) 调用消息：调用消息的发送者把控制传递给消息的接收者，然后停止活动，等待消息接收者放弃或返回控制。
(2) 异步消息：异步消息的发送者通过消息把信号传递该消息的接收者，然后继续自己的活动，不等待接收者返回消息或控制。
(3) 返回消息：返回消息表示从过程调用返回。
(4) 阻止消息和超时消息：阻止消息是指消息发送者发出消息给接收者，如果接收者无法立即接收消息，则发送者放弃这个消息。超时消息是指消息发送者发出消息给接收者并按指定时间等待。如果接收者无法在指定时间内接收消息，则发送者放弃这个消息。 19) 协作图是用于描述系统的行为是如何由系统的成分协作实现的图，协作图中包括的建模元素有对象、消息、链等。
20) 状态图(statechart diagram)主要用于描述一个对象在其生存期间的动态行为，表现一个对象所经历的状态序列，引起状态转移的事件(event)，以及因状态转移而伴随的动作(action)。 21) 活动(activity)表示的是某流程中任务的执行，它可以表示算法过程中语句的执行。 22) 状态图可以表现一个对象在生存期的行为、所经历的状态序列、引起状态转移的事件以及因状态转移引起的动作。活动图用来表示完成一个操作所需要的活动，或者是一个用例实例的活动。实际也是一种流程图，描述活动的序列，即系统由一个活动到另一个活动的控制流。
23) 泳道(swimlane)是活动图中的区域划分，根据每个活动的职责对所有活动进行划分，每个泳道代表一个责任区。泳道和类并不是一一对应的关系，泳道关心的是其代表的职责，一个泳道可能由一个类实现，也可能由多个类实现。
第19篇：安徽工业大学UML实验报告
学 号 姓 名 班 级 指导教师
胡增涛
实验
一、用例建模
【实验目的】
掌握客户需求分析的方法和步骤
了解以用例建模的软件开发方法
识别并编写用例
掌握用Rose进行用例建模的具体方法和步骤 【实验内容】
要求根据周围的实际情况，自选一个小型应用项目，分析业务需要，识别并编写用例、绘制用例图以理解系统需求，亦可老师指定的“企业综合信息管理系统”中的“进销存 管理子系统” 【实验原理与步骤】
建模原理：
1.需求获取，以任务和客户为中心，通过会议、面谈等手段对客户需求进行调研，获得 系统目标、范围和功能要求的初步说明。
2.用例分析，确定用例，同时采用分层思想，对用例的层次级别进行划分（高层用例、子系统级、用户目标级）
3.用例描述。分层绘制用例图，撰写用例的文字描述（采用单栏格式）。 步骤：
1.需求获取。自选题目，与相关客户、领域专家等反复商讨，获得系统目标、范围和功 能要求的初步说明。（也可采用老师指定的题目：“企业综合信息管理系统”中的“进销 存管理子系统”）。
2.用例分析。确定系统范围和边界、确定参与者、确定用例。 3.用例描述。分层绘制用例图，描述用例。 画图原理：
采用Rose软件进行用例建模必须建立在完好的系统用例分析基础之上，只有做好系统 分析，系统用例建模才能达到预期的效果。
步骤：
1.分层绘制用例图，每层采用“包”进行管理。2.以“企业综合信息管理系统”—》“进 销存管理”子系统—》“销售管理”—》“合同管理”—》“收款单处理”为主线，完成 实验。其他主线也可以。 【实验结果】
1.用Rose绘制的“企业综合信息管理系统”的1级用例图如下： 此系统包括“财务管理子系统”、“综合支持管理子系统”、“生产调试管理子系统”和“经 理查询子系统”等，而“进销存管理子系统”又包括“采购管理子系统”、“销售管理子 系统”和“库存管理子系统”。
2.用Rose绘制“进销存管理”的2级用例图如下：
“管理进销存”用例管理企业与客户签订采购／销售合同，并督促合同的执行和履约，提供售后服务。对库存产品和物料进行出／入库的有效管理，及时盘点并提出低于库存预警线而需要采购的物料清单和各种库存统计报表。
3.用Rose绘制“销售管理子系统”的3级用例图如下：
制定销售计划，与客户签订销售合同，井将其详细内容录入管理系统。监控正在履约的合同，检查客户是否按时付款，对付款的客户发货。
4.用Rose绘制“销售合同管理子系统”的4级用例图如下： 销售合同的主要条款是销售合同的重心，它决定了合同签订双方的义务和权利，决定了销售合同是否有效和是否合法，是当事人履行合同的主要依据。这是一份合同的重中之重，营销员在签订合同的过程中，一定要对合同所具备的主要条款逐一审明，详尽规定，使之清楚、明确。
【实验总结】
1.在添加用例之间的关系时应注意，用例之间的关系有：一般关联关系（用无方向实绩 箭头或单向实线箭头）；包含关系；扩展关系（都是一种依赖关系，所以用依赖线【虚 线箭头】）；泛化关系（空心三角实线箭头）。
2.刚进到实验室去做实验的时候，不知道如何下手去做，后来看看文档，然后再做就很 容易上手了。
实验
二、分析建模 【实验目的】
理解面向对象系统和对象类建模（概念建模）的概念 了解和掌握面向对象系统分析的方法和步骤
了解和掌握寻找开发系统中类（概念）的方法和技巧 掌握用Rose绘制概念模型的方法 【实验内容】
在用例分析的基础上，选择第一个迭代周期打算开发的用例，建立相关的概念模型 【实验原理与步骤】
建模原理：
1.使用概念目录列表（见下图）和非正式分析法（识别问题域的文本描述中的名词 短语，然后将其作为概念或属性的候选对象）相结合的方法识别概念。因此，待开 发用例的文字描述中，名词可能 成为概念或属性的候选对象；表示 行为的动词词 组有可能成为事务型或过程 型对象；形容词组有可能对应抽象的名词型概念。
采用的技术基本上就是：ER图和纯行为+OO的聚合、泛化。
2.最终关联的数量 介于“需要知道”型关联与【“需要知道”型关联+“需要理解”型（从通用关联列表中派生出的，见下图）】之间。
【实验结果】
用Rose绘制的概念模型如下图：
【实验总结】
1.此实验主要注意关联的命名、画法和阅读方向。比如：打算在“销售客户”与“销售 合同之间画一一般关联，命名为“签订”，显然主语是“销售客户”，宾主是“销售合同”， 画线的时候反而要从宾主拖向主语，这样，打开连线的规格说明，才可以看到RoleA 是“销售客户”。
2.关于聚合与组合，首先，关联的读法是A聚合成B（因此菱形在大头），因此 要从B 画向A，比如：从“销售合同”画向“销售合同明细”。这时Role B Detail中的Aggregate 就已经 选中（表示 聚合，是空心菱形），如果再选中Bye Value，就变成 组合了（空心 菱形）。
实验
三、设计建模1 【实验目的】
理解顺序图的基本概念 了解和掌握软件工程中用例逻辑时序的分析方法 掌握使用Rose创建顺序黑乎乎 的方法 【实验内容】
在用例模型和概念模型的基础上，对首选的用例进行分解，识别出系统事件（系统操作）、（并写出契约的后置条件）；为每个系统事件画顺序图，为对象分配职责。 【实验原理与步骤】
原理：
1.在系统顺序图中，所有的系统都被当成黑盒子看待，顺序图的重点是参与者发起的跨 越系统边界的事件。
2.系统事件是由某参与者发起的指向系统 的输入事件。一个事件的发生能够触发一个 响应操作的执行。
3.请仔细研究下图，考察它是如何从左边的“购买商品”用例文字描述中分解出3个系 统事件的。
4.参照用例模型和概念模型。为每个系统操作估计后置条件。（实例创建、形成关联、属性修改）
5.按照设计模式为对象分配职责
步骤：
1.分析首选用例的文字描述，按事件进行分解，识别出系统事件。（下面以“企业 综合信息管理系统”）——》“进销存管理”子系统——》“销售管理”——》“合同 管理”主线中的“收款单处理”用例为例）
2.为每个系统事件估计后置条件。（以上做了部分分析）
3.按设计模式进行设计 首先考虑控制者，领域控制者选参与者角色，即“销售人员”。 为了避免使用FORM窗口等表示层对象，我们构造一个类“应用协调者”向控制者发 送消息。 【实验结果】
用Rose画出的设计类图如下图：
用Rose画出的顺序图如下：
实验
四、设计建模2 【实验目的】
理解面向对象类之间关联的概念
了解和掌握分析类之间关联关系的方法
了解和掌握待开发系统中类之间关联关系的分析方法
完善设计类图，掌握使用Rose对关联进行建模的过程 【实验内容】
根据设计建模（1）中交互分析，进一步设计关联和对象 可见性（补上遗漏的关联）， 完善设计类图。 【实验原理与步骤】
原理：
步骤： 【实验结果】
用Rose完善的设计类图如下图：
【UML与软件建模实验总结】
在建模过程中，遇到一些问题，诸如某些操作界面无法看到，一些修改影响了其他模图的建立，通过询问辅导老师和上网查找资料，得到了比较满意的解决；在这次实验中，关于UML的概念以前比较模糊的地方，我在实际操作中，变得更加清楚了，对Rational Rose的UML功能运用的更加系统，更加熟练；但是更让我明白，UML的知识是十分丰富的，我现在的认识还不够，我将会在以后的学习中，不断提高自己的UML知识。
第20篇：UML与面向对象分析与设计
UML与面向对象分析与设计
实验实践训练体系
适用专业: 计算机科学技术、软件工程
第一部分 课程与实验综述
一．课程简介及实践要求：
《UML与面向对象分析与设计》是以介绍面向对象的统一建模语言UML为主,使学生了解面向对象技术的基本概念,掌握面向对象的分析和设计方法,以及与面向对象技术相关的一些软件开发技术,同时掌握在Rational Rose环境下用UML进行分析和设计的技术。本课程在教学内容方面着重基本理论、基本知识和基本方法，在培养实践能力方面着重设计构思和设计技能的基本训练，熟练的上机操作能力和分析能力。
实验实践训练是UML与面向对象分析与设计教学的重要技能环节。通过实验，使学生加深理解、验证、巩固课堂教学内容，特别是通过设计和综合实验，发挥学生的想象力和创新能力。
二．课程实验目的要求：
通过UML的实验,学生应该: 1．学会用面向对象的思想去分析和设计相关系统; 2．学会用Rose建模工具进行软件建模。 三．课程实验参考资料
1.(美)Joseph Schmuller著.UML基础、案例与应用.人民邮电出版社,2004 2.(美)Hans-Erik Erikon.UML 2工具箱.电子工业出版社,2004 3.吴际,金茂忠.UML面向对象分析.北京航空航天大学出版社,2002 4.赵从军.UML设计及应用.机械工业出版社,2004 5.Grady Booch,James Rumbaugh,Ivar Jacobson.UML用户指南.机械工业出版社,2001 6.吴建,郑潮,汪杰.UML基础与Rose建模案例.人民邮电出版社,2004 第二部分 实验实践指导
实验一
用例图
一、实验目的
1.学会分析系统中的参与者和用例 2.掌握用例图的绘制方法
二、实验器材
1. 计算机一台；
2. Rational Rose 工具软件；
三、实验内容
画出ATM系统的用例图
四、实验步骤
1.分析
ATM自动取款机：客户可以取钱，存钱，查询余额，转帐，修改密码。 通过分析可找出如下几个参与者： 1．ATM 2．客户
通过分析得到如下用例：
（1）存款 （2）取款 （3）查询余额 （4）转帐 （5）修改密码 （6）打印收据 2．绘图步骤：
下面介绍在Rose2003中创建用例图的过程：
（1）在“Use Case View“中双击Main图，或者右击“Use Case View“，弹出在快捷菜单中选择“New”－>“UseCase Diagram”，双击图标，出现图1，为编辑用例图做好准备。
（2）在用例视图中，从工具栏中选择Actor图标，在右边的绘图区中添加一个新元素，并取名客户表明新增一个参与者，如图2所示。
图2 （3）同样的方法添加参与者“ATM”,如图3所示。
图3 (4)在工具栏上选择用例的图标，依次添加存款、取款、查询余额、转帐、修改密码、打印收据，如图4所示。
图4 （5）添加参与者和用例间的关联关系，如图5所示。
图5
五、实验报告要求
1． 整理实验结果。 2． 小结实验心得体会。
实验二
交互图
一、实验目的
1.学会用协作图实现用例
2.掌握顺序图的绘制方法以及顺序图和协作图的相互转换。
二、实验器材
1. 计算机一台；
2. Rational Rose 工具软件；
三、实验内容
画出ATM取款的顺序图，并转换为协作图。
四、实验步骤
1.分析
ATM取款的场景：
（1）通过读卡机，用户插入ATM卡；
（2）ATM系统从卡上读取银行ID、帐号、加密密码、并用主银行系统验证银行ID和帐号；
（3）用户输入密码，ATM系统根据上面读出的卡上加密密码，对密码进行验证； （4）用户输入取款数量；
（5）ATM系统通知主银行系统，传递储户帐号和取款数量，并接收返回的确认信息； （6）ATM系统输出先进、ATM卡和显示帐户余额的收据； （7）ATM系统记录事务到日志文件。 寻找场景中的对象：ATM、客户和帐户。 2．绘图步骤：
下面介绍在Rose2003中创建顺序图的过程：
（1）在“Logical View”中新建“Sequence Diagram“，双击图标，出现图1，为编辑顺序图做好准备。
（2）在顺序图编辑窗口中，从工具栏中选择Object图标，在右边的绘图区中添加一个新元素，并取名Customer表明新增一个对象，如图2所示。
图2
（3）同样的方法，添加ATM对象和Account对象，如图3所示。
图3 （4）根据ATM取款的场景，获得第一条消息为“客户向ATM机提交取款需求”，向图中添加消息，如图4所示。
图4
（5）同样的方法添加其它消息，如图5所示。
图5 （6）根据顺序图生成协作图， 步骤如下：“Browse”－>“Create Collaboration Diagram”，生成的协作图，如图6所示。
图6
五、实验报告要求
1． 整理实验结果。 2． 小结实验心得体会。
实验三 类图
一、实验目的
1.理解类的基本概念 2.理解类间的关系 3.掌握类图的绘制方法
二、实验器材
1. 计算机一台；
2. Rational Rose 工具软件；
三、实验内容
分析选课系统中的类及关系，然后画出它们的类图。
四、实验步骤
1.分析
在选课系统中，通过分析可抽象出如下几个类： 1．学生类 2．管理员类 3．课程类
学生类和管理员类的属性较容易分析，这里只列出课程类的属性和方法： （1）课程名称 （2）开课教室 （3）课程号 （4）授课教师 （5）选课的学生 （6）开课起始时间 （7）允许选课的学生人数 （8）设置课程号 （9）设置课程名称 （10）查询课程号
（11）查询允许选课的学生人数 2．绘图步骤：
下面介绍在Rose2003中创建类和它们之间关系的过程：
（1）在“Logical View“中双击Main图，或者右击“Logical View“，弹出在快捷菜单中选择“New”－>“Cla Diagram”，双击图标，出现图1，为编辑类图做好准备。
图1
（2）在逻辑视图中，从工具栏中选择cla图标，在右边的绘图区中添加一个新元素，并取名Student表明新增一个类。
图2
（3）选择新创建的元素，点击鼠标右键，在弹出的菜单中选择“Open Sepcification”,弹出图3对话框。
（4）在对话框中，可以修改元素的名称，这里新元素的名称定为“Student”，如图4所示。
图3
图4 （5）点击“Attributes”选项卡，添加属性，如图5所示。
图5 （6）点击“operations”选项卡，添加方法如图6所示。
图6 （7）同样的方法添加Course类，如图7所示。
图7 （8）创建两个类之间的关系，通过分析得出：学生类和课程类之间为单向关联。 选择图标栏的“关联”，由学生类指向课程类。如图8所示。
图8 （9）创建关联名。右击关联，选择“open specification“，键入关联名，如图9所示。
图9 （10）分别在“Role A Detail“和“Role B Detail“选项卡中键入名称和多重性，如图10所示。
图10 （11）重复（2）－（10）中的步骤完成选课系统整个类图的创建。
五、实验报告要求
1． 整理实验结果。 2． 小结实验心得体会。 实验四 状态图和活动图
一、实验目的
1． 熟悉状态图和活动图的基本功能和使用方法。 2． 掌握如何使用建模工具绘制状态图和活动图方法。
二、实验器材
1. 计算机一台；
2. Rational Rose 工具软件；
三、实验内容
（1）分析图书管理系统中的书和借书证的状态，画出它们的状态图； （2）分析管理员的活动状态，画出管理员的活动图。。
四、实验步骤
1.分析
在图书管理系统中，分析书的状态如下： 1．可借 2．被借 3．被预约 4．删除
借书证的状态如下： 1．可用 2．不可用 3．删除
管理员的活动如下： 1． 处理还书 2． 处理借书 3． 处理罚款 读者的活动如下： 1．登录 2．找书 3．预约 4．浏览 2．绘图步骤：
下面介绍在Rose2003中创建类和它们之间关系的过程：
（1）在“Logical View“中信件“StateChart Diagram”，双击图标，出现图1，为编辑状态图做好准备。
图1 （2）在工具栏中选择“Start State”图标添加到编辑窗口中，如图2所示。
图2 （3）在工具栏中选择“State”图标，添加一个元素，命名为“New book”，如图3所示。
图3
（4）同样的方法添加其它状态，如图4所示。
图4
（5）书的各个状态之间添加转移及相应的事件，如图5所示。
图5
（6）同样的方法得借书证的状态图，如图6所示。
图6
（7）在Rose2003中，绘制图书管理员的活动图，新建“Activity Diagram”，如图7所示：
图7
（8）读者的活动图如图8所示：
图8
五、实验报告要求
1． 整理实验结果。 2． 小结实验心得体会。
