uml实验心得体会.docx

1、uml 实验心得体会篇一：UML 实验报告UML 实验报告学院 班级 学号 姓名UML 实验报告实验一：用例图实验结果：小结实验心得体会：用例模型用于需求分析阶段，它描述了待开发系统的功能需求，并驱动了需求分析之后各阶段的开发工作。用例图是 UML 中用来对系统的动态方面进行建模的 7 种图之一。用例图描述了用例、参与者以及它们之间的关系。用例图从用户角度描述系统功能，并指出各功能的操作者。通过本次实验，我熟悉 Rational Rose 建模环境，更加清楚的了解了用例图的语义和功能，如何清晰明了的识别参与者、用例，学会了如何使用事件流描述用例。同时掌握了用例间的类属关系、Include 关系

2、和 Extend 关系的语义、功能和应用。最后通过本次实验学习了如何使用用例图为系统的上下文以及系统的需求建模。思考题：1. 如果要删除参与者、用例，请问是在导航窗口删除，还是在绘图窗口删除？答：都可以删除，但在绘图窗口中有两种删除方式：一种是只删除参与者、用例，而不改变 其在导航窗口中的存在，另一种是从建模中完全删除。2. 如果要删除参与者和用例的联系，用例和用例的联系，请问是在绘图中删除，还是 在参与者或用例的设置对话框中删除？答：都可以删除。实验二：类对象模型的建立实验结果：小结实验心得体会：类图是面向对象系统建模最常用的图，描述了类图、接口集、协作以及它们之间的关系。类图描述了系统的静

3、态设计视，该视主要体现系统的功能需求，即系统应该提供给用户的服 务。通过本次实验，加深了我对类图语义的理解和功能的应用，掌握了类之间的联系，关联、依赖、聚合等，同时基本掌握了在 Rational Rose 中绘制类的关联、依赖、泛化关系。思考题：选中一个模型对象，点击鼠标右键，比较快捷菜单项“EditDelete”与“EditDelete from Model”，它们二者之间区别在哪里？答：“EditDelete”只是在绘图窗口中删除了模型对象，而“EditDelete from Model”则是彻底的删除了模型对象。实验三：顺序图、协作图实验结果：顺序图：1.归还图书2.借出图书 协作图：1

4、. 归还图书2. 借出图书小结实验心得体会：顺序图描述了对象之间的动态合作关系，它强调对象之间消息发送的时间顺序，同时显示对象之间的交互。协作图与顺序图是同构的，Rose 可自动转换。顺序图是强调消息的交互作用图，协作图描述了对象间的关系，是强调发送和接收消息的对象的组织结构的交互作用图。 通过本次实验，掌握了对图书管理功能中的借书用例、还书用例进行动态建模。实验过程中由于对 Rational Rose 工具软件的不熟识，导致出现了不该出现的错误。在设计阶段，顺序图中需要引入边界类和控制类，在识别对象职责的基础上，需要将消息转换为类的方法，为方法定义参数、返回值类型，便于计算机的实现。其中，为

5、方法定义参数、返回值类型的时候，还是不能够快速准确的作出判断。实验四：活动图实验结果：篇二：UML 实验心得体会uml 实验报告学院班级 学号 姓名 uml 实验报告实验一：用例图实验结果：小结实验心得体会：用例模型用于需求分析阶段，它描述了待开发系统的功能需求，并驱动了需求分析之后各阶段的开发工作。用例图是 uml 中用来对系统的动态方面进行建模的 7 种图之一。用例图描述了用例、参与者以及它们之间的关系。用例图从用户角度描述系统功能，并指出各功能的操作者。通过本次实验，我熟悉 rational rose 建模环境，更加清楚的了解了用例图的语义和功能，如何清晰明了的识别参与者、用例，学会了如

6、何使用事件流描述用例。同时掌握了用例间的类属关系、include 关系和 extend 关系的语义、功能和应用。最后通过本次实验学习了如何使用用例图为系统的上下文以及系统的需求建模。 思考题：1. 如果要删除参与者、用例，请问是在导航窗口删除，还是在绘图窗口删除？ 答：都可以删除，但在绘图窗口中有两种删除方式：一种是只删除参与者、用例，而不改变 其在导航窗口中的存在，另一种是从建模中完全删除。2. 如果要删除参与者和用例的联系，用例和用例的联系，请问是在绘图中删除，还是 在参与者或用例的设置对话框中删除？答：都可以删除。实验二：类对象模型的建立实验结果：小结实验心得体会：类图是面向对象系统建模

7、最常用的图，描述了类图、接口集、协作以及它们之间的关系。类图描述了系统的静态设计视，该视主要体现系统的功能需求，即系统应该提供给用户的服务。通过本次实验，加深了我对类图语义的理解和功能的应用，掌握了类之间的联系，关联、依赖、聚合等，同时基本掌握了在 rational rose 中绘制类的关联、依赖、泛化关系。 思考题：选中一个模型对象，点击鼠标右键，比较快捷菜单项“editdelete”与“editdelete from model” ，它们二者之间区别在哪里？答：“editdelete”只是在绘图窗口中删除了模型对象，而“editdelete frommodel”则是彻底的删除了模型对象。

8、实验三：顺序图、协作图实验结果：顺序图：1. 归还图书2.借出图书协作图：1. 归还图书2. 借出图书 小结实验心得体会：顺序图描述了对象之间的动态合作关系，它强调对象之间消息发送的时间顺序，同时显示对象之间的交互。协作图与顺序图是同构的，rose可自动转换。顺序图是强调消息的交互作用图，协作图描述了对象间的关系，是强调发送和接收消息的对象的组织结构的交互作用图。 通过本次实验，掌握了对图书管理功能中的借书用例、还书用例进行动态建模。实验过程中由于对 rational rose 工具软件的不熟识，导致出现了不该出现的错误。在设计阶段，顺序图中需要引入边界类和控制类，在识别对象职责的基础上，需要

9、将消息转换为类的方法，为方法定义参数、返回值类型，便于计算机的实现。其中，为方法定义参数、返回值类型的时候，还是不能够快速准确的作出判断。 实验四：活动图实验结果： 篇二：uml 实验总结实验一1源代码生成，在逻辑视图中绘制下图，生成 java源文件 生成代码步骤：“tools”- “java”-“genenate codes”。public class meeting private string username;private string scheduled_user; private date start_time; private dateend_time; private str

10、ing 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进行逆向工程，自行找到一个项目软件源代码，进行逆向

11、工程。 （ftp 上有一个小源程序文件）逆向工程的实现“tools”-“java”- “reverse engineer java”。 public class student private string name;public student() public void test() 实验二根据下属需求，分析参与者和用例，并建立络教学系统的用例图。 络教学系统的功能需求主要包括以下几个方面： 学生可以登录站浏览信息、查找信息和下载文件。 教师可以登录站输入课程简介、上传课件文件、发布消息、修改和更新消息。 系统管理员可以对页面维护以及批准用户的注册申请。 录入课程简介 下载文件查找信息 修

12、改消息注册信息处理 实验三1、已知借书的活动图如图 3 所示，若要求欠费的读者需结清欠款才能借书，请完善该活动图，并在 rose 内绘制出来。 图 3 借书处理活动图2、图 4 为图书“借书”活动图，文字描述此活动图包括哪些活动，活动按照怎样的顺序发生？ 图 4 “借书处理”活动图（1） 读者查找所需的图书，若找到图书，将所需的图书带到借阅台； （2） 工作人员输入读者信息，检查读者身份是否合法，如果读者身份合法， 进入（3） ；（3） 录入图书信息，并检查图书是否允许借阅，如果允许，则记录借阅信 息，否则直接进入（4） ；（4） 检查是否还有图书需要录入，如果还需录入，进入（3） ，否则提借

13、阅信息。3、绘制“删除读者信息”用例的活动图。删除读者信息一般按照以下步骤进行：（1）管理员在录入界面，输入待删除的读者名；（2） “业务逻辑”组件在数据库中，查找待删除的读者名；（3）如果不存在，则显示出错信息，返回步骤（1） ，如果存在则继续； （4） “业务逻辑”组件判断“待删除的读者”是否可以删除；（5）如果不可以，则显示出错信息，返回步骤（8） ，如果可以则继续； （6）在数据库中，删除相关信息； （7）显示删除成功信息； （8）结束。 篇三：uml 实训总结实训总结（收获与体会）通过一个学期的 uml 学习，我从书本上获取了基本的理论知识，而真正的学以致用，将书本理论知识运用到实际

14、的过程，是这次 uml 实训的体现。 三个周的 uml 实训，主要是围绕着一个实训题目“基于 uml 系统需求分析与设计-合倍利业务流管理系统”进行的，以小组为单位进行文档的编写，其中还对各种流程图、类图、用例图等的绘制，整个过程设计了知识的方方面面。从中让我认识到 uml 的作用和运作模式以及方法，它是一种统一建模的标准语言，现在对于大多数软件开发来说，都使用 uml 作为建模语言，形成了统一的标准。它是图形化的的语言，可以很直观的描述一个事物的状态、行为与特征，很好的说明与表达了“合贝利任务管理”这个系统。 总之，在我看来，uml 是一种定义良好、易于表达、功能强大且普遍适用建模语言。融入

15、软件工程领域的心思想、新方法和新技术，作用域不限于支持面向对象的分析和设计，也不单纯是一种方法，仅仅是一组符号而已，它可以对任何具有静态机构和动态行为的系统进行建模，所以我很喜欢适用 uml，在今后的学习中，我还会进一步对该模型的学习，因为它方便、简洁、干净、清爽，直观形象，把整个软件系统的开发流程都融入进去。 这次实训过程中，文档方面的编写，遇到了很多的问题，这些问题主要是对基础知识的理解和把握不够，不能融会贯通和学以致用，有时遇到困难的时候真的不知如何着手解决，但是，我始终相信的那句话“读万卷书，不如行万里路，行万里路不如名师指路” 。所以，当遇到自己模糊和自己难以解决的问题时，向指导老师

16、和懂的同学请教，帮助解决我遇到的问题，经过他们的讲解后，我下来自己在分析，在动手，从不理解到理解，从不会到会，从懂到懂，这是一个让我学习愉快的过程，在这个过程中，既可以丰富了自己的知识，还可以和老师和同学进行有效地方沟通。在这次实训过程中，感触最深的也就是合作精神了。独木难成林，单枪匹马，那是最错误的思想和做法。这次我是深有感触了。对于一个系统的分析，到最终项目的完成，需要分析每个文档，然后在写出纸质的文档，而在每个文档中，内容比较多，分析也要求比较到位，所以单独凭借一个人去完成，似乎有点困难， 于是我们小组，将每个文档进行分析，能独立成块就分配给每一个人，这样，每个人都有自己的任务，谁也不会

17、闲着，既学到了知识，也充实了自己。另外一点，就是我深深体会到了积累知识的重要性。在实训当中我们遇到了不少难题，但是经过我们大家的讨论和老师细心的一一指导，问题得到了解决。 两个月的实训结束了，收获颇丰，同时也更深刻的认识到要做一个合格的程序员并非我以前想像的那么容易，最重要的还是细致严谨。社会是不会要一个一无是处的人的，所以我们要更多更快地从一个学生向工作者转变，总的来说我对这次实习还是比较满意的，它使我学到了很多东西，为我以后的学习做了引导，点明了方向。实训的日子即将结束，回想这一个过程，有过痛苦，有过烦恼，有过喜悦和有过成功。痛苦烦恼的是自己对所学书本知识掌握得不是很扎实，面对着从书本上学

18、到的知识与实际联系不起来，总结起来就是自己的动手练习的时间太少。而喜悦的是，在做的过程中遇到了困难和问题，主动向老师和会的同学请教，然后再做，直至做正确做成功后的那种喜悦。 团队的力量是无穷的，通过组员的共同努力，完成了实训项目。虽然，我们这组的项目存在着诸多的不足和缺点，但这正是以后学习和工作需要弥补的。这次实训将为我以后进入社会提过了一笔宝贵的财富，是对我能力的一个见证。最后，不得不感谢指导教师熊飞老师的辛勤指导，和小组成员的共同努力！篇四：uml 实验报告 学 生 实 验 报 告 书 实验课程名称 uml 建模技术 开 课 学 院 指导老师姓名 学 生 姓 名 学生专业班级 XX XX

19、学年 第 一 学期实验课程名称： uml建模技术 实验课程名称： uml 建模技术 篇五：uml 实验状态图 实验报告南京信息工程大学实验(实习)报告 实验名称 状态图 实验(实习)日期 得分指导老师 系专业 班级 一、实验目的1熟悉活动图的基本功能和使用方法。2掌握如何使用建模工具绘制活动图方法。二、实验器材1计算机一台。2rational rose 工具软件。三、实验内容通过前面内容的学习，完成了对图书馆的图书馆管理系统的需求的初步分析，得出系统的用例图和相应的活动态。通过这两类图我们可以初步了解系统的业务处理过程，但对业务处理过程的处理状态间转换了解仍不够，这不利于设计人员对系统业务的进

20、一步理解，而状态图能从对象的动态行为的角度去描述系统的业务活动。因此，指派你运用本节所学的状态图，完成如下任务：1. 完成图书业务模块中还书用例的状态图。四、实验步骤1业务分析：由前面章节对图书馆管理系统中的还书主要业务的描述和分析可知，还书业务的动态行为是由：空闲（idle） 、图书查找（finding） 、还书（reversion） 、失败（failure） 、归还成功（success）5 种状态及激活相互转换的事件。2绘制状态图：请您根据分析运用 uml 绘制还书用例的状态图。 分析：还书的状态图，还书的主要业务都是由管理员来完成，首先管理员必须先登录系统，并通过验证后，便可以进行下一步

21、的操作，查找该书的相关信息，如存在，则进行还书操作，如不存在该信息，则给出提示信息；绘图步骤：（1）在用例图中的还书（revesion）用例，单击右键，如图所示，新建一个状态图，命名为 revesion 状态图。（2）双击“receivesion”状态图，展开后，在左边的工具栏上选取一个实心圆点，此结点为开始结点；当还书的时候，操作者先要询问系统的状态，如果系统忙，操作者则必需等待，因此，得到系统的两种状态。（3）操作者在询问系统和状态后，得到两种状态，如果系统忙，操作者必需要等待、结束，重返步骤（1） 。（4）如系统空闲，则进行对还书的信息进行查询操作；查询也有两种结果，一是查询得到该书的相

22、关信息，二查询不到该书的相关信息；则此时有两种状态，需要建立两种状态。（5）最后，操作者进行了操作后，系统会给出操作的结果给操作者；操作成功或失败，都会有提示信息给出。整个的还书的过程便完成。（7）根据分析设计情况，进一步添加或细化状态图。五、实验报告要求1整理实验结果。2小结实验心得体会。通过本次试验学习到了项目中状态图的绘制，了解了他们之间的关系以及关系处理的方法，熟悉了对 rational rose 工具软件的使用，在以后做软件项目设计有很大的帮助。篇三：UML 实训总结实训总结（收获与体会） 通过一个学期的 Uml 学习，我从书本上获取了基本的理论知识，而真正的学以致用，将书本理论知识

23、运用到实际的过程，是这次 UML 实训的体现。三个周的 UML 实训，主要是围绕着一个实训题目“基于 UML 系统需求分析与设计-合倍利业务流管理系统”进行的，以小组为单位进行文档的编写，其中还对各种流程图、类图、用例图等的绘制，整个过程设计了知识的方方面面。从中让我认识到 UML 的作用和运作模式以及方法，它是一种统一建模的标准语言，现在对于大多数软件开发来说，都使用 Uml 作为建模语言，形成了统一的标准。它是图形化的的语言，可以很直观的描述一个事物的状态、行为与特征，很好的说明与表达了“合贝利任务管理”这个系统。总之，在我看来，UML 是一种定义良好、易于表达、功能强大且普遍适用建模语言

24、。融入软件工程领域的心思想、新方法和新技术，作用域不限于支持面向对象的分析和设计，也不单纯是一种方法，仅仅是一组符号而已，它可以对任何具有静态机构和动态行为的系统进行建模，所以我很喜欢适用 UML，在今后的学习中，我还会进一步对该模型的学习，因为它方便、简洁、干净、清爽，直观形象，把整个软件系统的开发流程都融入进去。这次实训过程中，文档方面的编写，遇到了很多的问题，这些问题主要是对基础知识的理解和把握不够，不能融会贯通和学以致用，有时遇到困难的时候真的不知如何着手解决，但是，我始终相信的那句话“读万卷书，不如行万里路，行万里路不如名师指路” 。所以，当遇到自己模糊和自己难以解决的问题时，向指导

25、老师和懂的同学请教，帮助解决我遇到的问题，经过他们的讲解后，我下来自己在分析，在动手，从不理解到理解，从不会到会，从懂到懂，这是一个让我学习愉快的过程，在这个过程中，既可以丰富了自己的知识，还可以和老师和同学进行有效地方沟通。在这次实训过程中，感触最深的也就是合作精神了。独木难成林，单枪匹马，那是最错误的思想和做法。这次我是深有感触了。对于一个系统的分析，到最终项目的完成，需要分析每个文档，然后在写出纸质的文档，而在每个文档中，内容比较多，分析也要求比较到位，所以单独凭借一个人去完成，似乎有点困难，于是我们小组，将每个文档进行分析，能独立成块就分配给每一个人，这样，每个人都有自己的任务，谁也不

26、会闲着，既学到了知识，也充实了自己。另外一点，就是我深深体会到了积累知识的重要性。在实训当中我们遇到了不少难题，但是经过我们大家的讨论和老师细心的一一指导，问题得到了解决。 两个月的实训结束了，收获颇丰，同时也更深刻的认识到要做一个合格的程序员并非我以前想像的那么容易，最重要的还是细致严谨。社会是不会要一个一无是处的人的，所以我们要更多更快地从一个学生向工作者转变，总的来说我对这次实习还是比较满意的，它使我学到了很多东西，为我以后的学习做了引导，点明了方向。实训的日子即将结束，回想这一个过程，有过痛苦，有过烦恼，有过喜悦和有过成功。痛苦烦恼的是自己对所学书本知识掌握得不是很扎实，面对着从书本上

27、学到的知识与实际联系不起来，总结起来就是自己的动手练习的时间太少。而喜悦的是，在做的过程中遇到了困难和问题，主动向老师和会的同学请教，然后再做，直至做正确做成功后的那种喜悦。团队的力量是无穷的，通过组员的共同努力，完成了实训项目。虽然，我们这组的项目存在着诸多的不足和缺点，但这正是以后学习和工作需要弥补的。这次实训将为我以后进入社会提过了一笔宝贵的财富，是对我能力的一个见证。最后，不得不感谢指导教师熊飞老师的辛勤指导，和小组成员的共同努力！篇四：UML 实验总结实验一1源代码生成，在逻辑视图中绘制下图，生成 JAVA源文件 生成代码步骤：“Tools”- “Java”- “Genenate C

28、odes”。public class 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; publi

29、c String getLabel() return null; public String toString() return null; public Void main(String args) return null; 2进行逆向工程，自行找到一个项目软件源代码，进行逆向工程。 （FTP 上有一个小源程序文件）逆向工程的实现“Tools”-“Java”- “Reverse Engineer Java”。public class Student private String name;public Student() public void test() 实验二根据下属需求，分析参与者和

30、用例，并建立络教学系统的用例图。 络教学系统的功能需求主要包括以下几个方面： 学生可以登录站浏览信息、查找信息和下载文件。 教师可以登录站输入课程简介、上传课件文件、发布消息、修改和更新消息。 系统管理员可以对页面维护以及批准用户的注册申请。录入课程简介下载文件查找信息 修改消息注册信息处理实验三1、已知借书的活动图如图 3 所示，若要求欠费的读者需结清欠款才能借书，请完善该活动图，并在 Rose 内绘制出来。图 3 借书处理活动图2、图 4 为图书“借书”活动图，文字描述此活动图包括哪些活动，活动按照怎样的顺序发生？图 4 “借书处理”活动图 （1） 读者查找所需的图书，若找到图书，将所需的

31、图书带到借阅台； （2） 工作人员输入读者信息，检查读者身份是否合法，如果读者身份合法，进入（3） ；（3） 录入图书信息，并检查图书是否允许借阅，如果允许，则记录借阅信息，否则直接进入（4） ；（4） 检查是否还有图书需要录入，如果还需录入，进入（3） ，否则提借阅信息。3、绘制“删除读者信息”用例的活动图。删除读者信息一般按照以下步骤进行：（1）管理员在录入界面，输入待删除的读者名；（2） “业务逻辑”组件在数据库中，查找待删除的读者名；（3）如果不存在，则显示出错信息，返回步骤（1） ，如果存在则继续； （4） “业务逻辑”组件判断“待删除的读者”是否可以删除；（5）如果不可以，则显示出

32、错信息，返回步骤（8） ，如果可以则继续； （6）在数据库中，删除相关信息； （7）显示删除成功信息； （8）结束。篇五：UML 学习心得体会养成良好的绘制 uml 序列图的习惯 在学习 uml 的过程中，你可能会遇到绘制 uml 序列图的问题，这里就讨论一下怎样才能养成良好的绘制 uml 序列图的习惯。有一些方法可以帮助您提高 uml 序列图的质量和效力。它们包括：和主题问题专家一起验证决策；使解决方案尽量简单；为绘制消息和返回值选择一种一 致且有效的风格；将序列图分层；遵循一致的逻辑风格；牢记序列图是动态的。一：验证决策绘制 uml 序列图时，我做了一些对其它模型可能有潜在影响的决策。例如

33、，在对第 10步建模时，假设（大致上是个设计决策）费用显示屏幕同时也处理学生对费用是否可接受所进行的验证。该决策应该由用户界面原型反映出来，并由主题问题专家(sme)进行验证。您应该和 sme（特别是那些对于如何开发类似模型有着深刻见解的富有经验的人）一起执行序列图的绘制工作。二：保持简单在对第 2 和第 3 步建模时，我忽然意识到学生可能应该使用口令进入系统。在向 sme 提出了这个概念后发觉我错了：姓名和学号组合对于我们的目的来说已经足够唯一，并且学校也不希望增加复杂的口令管理。这是个很有意思的决策，因为这是学校的一个运作策略，所以可以作为一条商业规则记载到增补规范中。通过与sme 一起检

34、验这个想法，而不是假定我比他们知道得更多，我避免了“镀金”的机会，因而减少了我们小组开发这一系统所需的工作。三：绘制消息和返回值绘制 uml 序列图时我更喜欢从左至右地绘制消息，从右至左地绘制返回值，尽管这样对于复杂的对象类来说不总是非常合适。我将消息上的标签和返回值对齐到离箭头最近的位置。我不喜欢在序列图上标出返回值，为的是使图尽可能地简化。不过，始终标出返回值也同样有效，特别是在序列图用于设计而不是分析目的时。 （我希望我的分析图尽量简单，而设计图尽量全面。 ）在分析期间，我的目标是理解逻辑和确保逻辑的正确性。而在设计期间，则要赋予消息精确的细节。四：将序列图分层绘制 uml 序列图时我喜

35、欢将序列图从左至右地分层。先标出参与者，然后是控制器类，然后是用户界面类，最后是商业类。在设计期间，可能需要添加系统类和持久类，我通常将它们放在序列图的最右侧。以这种方式将序列图分层往往使它们更易于阅读，并且更容易找出分层逻辑问题，例如用户界面类直接访问持久类。 五：遵循一致的逻辑风格请注意，在图 1 序列图所示的过程中，逻辑风格做了部分更改。一开始，特别是在登录时，用户界面处理一些基本逻辑-而在选择研习班，以及稍后的验证时，则是控制器类进行处理。这实际上是个设计问题。我不会在这个问题上纠缠太久，但和往常一样，我建议选择一种适合于您的建模风格，然后始终如一地贯彻在所有序列图中。 六：牢记序列图

36、是动态的绘制 uml 序列图时您可能听说过诸如动态建模和静态建模这样的术语，其他一些熟悉面向对象建模技术的开发人员常常会提到它们。您甚至可能听到过有关每种风格的优点的争论。动态建模技术主要集中在标识系统中的行为，包括序列图的绘制和活动图的绘制（请参阅“如何绘制 uml 活动图” ）以及 uml 协作图的绘制。而静态建模则集中在系统的静态方面，包括类、它们的属性，以及类之间的关联。类模型和持久数据模型一样，都是静态建模的主要产物。(一) uml（unified modeling language，统一建模语言）是一组用于描述 ooad 过程的图形化表达方式。uml 为交流面向对象的设计中的需求，

37、行为、体系结构的实现提供了一套综合的表示法。(二) uml 由 9 个不同类型的图组成： 用例图：显示了系统的外部可视行为。用例图描述了系统外的人员和系统的交互动作，以及系统的响应，该类型的图可以用于描述系统的功能需求。活动图：显示系统行为的峡谷纳西描述。 活动图描述了单个功能需求内部的细节行为，包括基本的场景和一些可选的场景。 组件图：显示了系统的体系结构。 组件图描述了系统的可部署单元（可执行文件，组件，数据存储和其他一些内容）以及一些借口，可部署单元通过这些接口进行交互，该图可以用于研究系统的体系结构。顺序图：显示了对象随着时间的交互。顺序图描述了某个功能需求的路径或场景内相对时间的详细

38、行为，该图可用于理解系统元素之间的消息流程。协作图：显示了对象的交互，强调对象之间的关系。 （在里面找不到了）类图：显示了类的定义和关系。类图描述了系统设计中的类和接口，以及他们之间的关系。该图可用于定义内部的，面向对象的代码结构。 状态图：显示了响应时间的状态改变。状态图描述了系统如何改变状态以相应内部的和外部的事件，确保每个事件都被适当的处理。部署图：显示了系统的物理体系结构。部署图描述了系统的可部署单元（应用，组件，数据存储等）如何被赋予不同的节点，这些节点如何交互通信，用于系统映射和负载的研究。包图：显示了设计的层次结构。包图描述了设计的相关元素如何按组结合在一起，以及他们之间的关系。

39、(三) 各种图的作用1.用例图（usecasediagram）它是 uml 中最简单也是最复杂的一种图。说它简单是因为它采用了面向对象的思想，又是基于用户视角的，绘制非常容易，简单的图形表示让人一看就懂。说它复杂是因为用例图往往不容易控制，要么过于复杂，要么过于简单。用例图表示了角色和用例以及它们之间的关系。2.类图（classdiagram）uml 面向对象中是最常用的一种图，类图可以帮助我们更直观的了解一个系统的体系结构。通过关系和类表示的类图，可以图形化的方式描述一个系统的设计部分。3.对象图uml 面向对象中对象图是类图的实例，几乎使用与类图完全相同的标识。它们的不同点在于对象图显示类

40、的多个对象实例，而不是实例的类。一个对象图是类图的一个实例。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。4.状态图描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。通常创建一个 uml 状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。5.时序图又称顺序图，描述了对象之间动态的交互关系，着重体现对象间消息传递的时间顺序。 顺序图由一组对象构成，每个对象分别带有一条竖线，称作对象的生命线，它代表时间轴，时间沿竖线向下延伸。uml 面向对象中顺序图描述了这些对象随着时间 的推移相互之间交换消息的过程。消息用从一务垂直的对象

41、生命线指向另一个对象的生命线的水平箭头表示。图中还可以根据需要增加有关时间的说明和其他注释。6.协作图uml 面向对象中协作图用于显示组件及其交互关系的空间组织结构，它并不侧重于交互的顺序。协作图显示了交互中各个对象之间的组织交互关系以及对象 彼此之间的链接。与序列图不同，协作图显示的是对象之间的关系。另一方面，协作图没有将时间作为一个单独的维度，因此序列号就决定了消息及并发线程的顺 序。协作图是一个介于符号图和序列图之间的交叉产物，它用带有编号的箭头来描述特定的方案，以显示在整个方案过程中消息的移动情况。协作图用途：通过描绘对象之间消息的移动情况来反映具体的方案。显示对象及其交互关系的空间组

42、织结构，而非交互的顺序。7.活动图（activitydiagram）uml 面向对象中 uml 活动图记录了单个操作或方法的逻辑，单个用户案例，或者单个业务流程的逻辑。描述系统中各种活动的执行顺序，通常用于描述一个操作中所要进行的各项活动的执行流程。同时，它也常被用来描述一个用例的处理流程，或者某种交互流程。 活动图由一些活动组成，图中同时包括了对这些活动的说明。当一个活动执行完毕之后，控制将沿着控制转移箭头转向下一个活动。活动图中还可以方便地描述控制转移的条件以及并行执行等要求。组件图是用来反映代码的物理结构。从组件图中，可以了解各软件组件（如源代码文件或动态链接库）之间的编译器和运行时依赖

43、关系。使用组件图可以将系统划分为内聚组件并显示代码自身的结构。组件图的主要目的是显示系统组件间的结构关系。9.配置图uml 面向对象中配置图描述系统中硬件和软件的物理配置情况和系统体系结构。 在配置图中，用结点表示实际的物理设备，如计算机和各种外部设备等，并根据它们之间的连接关系，将相应的结点连接起来，并说明其连接方式。在结点里面，说明分配给该结点上运行的可执行构件或对象，从而说明哪些软件单元被分配在哪些结点上运行。 uml 是一种软件建模语言，可以对任何具有静态结构和动态行为的系统进行建模。在关注它建模特性的同时更要关注它的过程特性-在什么时间做什么工作，用什么模型 ，让哪些人来做。对系统用户而言，软件的开发模型向他们描述了软件开发者对软件系统需求的 理解。让系统用户查看软件对象模型并且找到其中的问题，可以使开发者不至于从一开始就发生错误。对软件开发而言，软件的对象模型有助于他们对软件的需求以及系统的架构和功能进行沟通。对软件的维护和技术支持者而言，在软件系统开始运行后的相当长的一段时间内，软件的对象模型能够帮助他们理解程序的架构和功能，迅速地对软件所出现的问题进行修复。建模并不是仅对大型的软件系统，甚至一个小型的留言本也能从建模的过程中受益。利用 uml 可以有效地解决软件设计和分析过程中