uml开发实验指导书

uml开发实验指导书（共6篇）

1.uml开发实验指导书 篇一

天津理工大学（华信软件学院）

实验指导书

实验七：创建活动图

课程名称：面向对象设计UML建模 适应课程：（1460460/1460466/14606617）

一.活动图的作用

〃活动图用于描述工作流程；用来描述处理和算法

二.上机实验目的：根据实际案例创建对应的活动图

三.实验内容：

1．熟悉活动图组成元素：

起始状态(Start state)终止状态(End state)转移(Transition)

活动（Activity）分支(Branch)决策(Decision)

分叉和汇合(Fork & Join)警戒条件(Guard condition)泳道(Swim Lane)

同步棒(Synchronization bar)

2.绘制“学生选课系统”中“Add Course”(添加课程)的活动图

（1）问题陈述：

1）管理员选择添加课程；

2）系统提示输入新课程信息；

3）管理员输入课程的各项信息；

4）统验证是否和已有课程冲突；

有冲突

（主脚本）

’提示课程冲突信息，要求重新输入；

2’ 返回 2）

（2）绘制活动图。

3．根据以下陈述，绘制“住宅工程建筑施工”活动图

问题陈述：

“住宅大楼在基础工程（包括地基和地下管道）完成后，就可以分别进行主

体结构和水电设备的安装。

①主体结构包括：砌筑主体结构、安装门窗、和室内装修；

②水电部分包括：水电准备、铺设室内管线、和安装水电设备；

当室内装修和安装水电设备均完成后，才能进行竣工验收。”

4.绘制“图书管理系统”的“借书”活动图

提示：借书主要活动有查找选择标题、查找有效书目和查找借书者（信息），如果查找顺利，则可登记借书。这时如果借书者预先有预订，则预定自

动取消。

5．绘制“订货服务系统”的活动图

提示：①本活动图可分为三个泳道：处理订货、顾客服务和财务结算；

② 活动图从接受定货开始（在顾客服务区），然后分别进行处理（学生

自己设计）……最后订货结束。

四.操作步骤：

1．在Use Case View 下，选Activity Diagram

进行命名（比如Add Course等）；

2．需要设置泳道时，点击工具栏的Swimlane工具。进行泳道设置；

3．双击浏览器中New Swimlane, 可以命名或修改泳道名；

4．利用工具栏的Start State ,End State ,Activity ,Transition ,Decision ,Horizontal Synchronization等按钮来设计活动图。

五．实验结果

1．“学生选课系统”中“Add Course”(添加课程)的活动图如下：

图7—1 “学生选课系统”中“Add Course”的活动图

2．绘制“住宅工程建筑施工”活动图（请同学自己完成，此例可以不画出泳道）

3．“借书”用例的活动图如下：

图7—2 “图书管理系统”中“Lend Item”的活动图

4．“订货服务系统”的活动图（请同学自己完成）

六．评分标准

1．能正确绘制“学生选课系统” 中“Add Course”、“图书管理系统”的“借书”活动图和“住宅工程建筑施工”活动图者，可酌情给予60-80分的成绩。

2．有创造性发挥着，可得到80分以上的成绩。

*上机实验补充内容（第12章业务建模）

一.实验目的：业务建模

二.实验内容：

1．根据以下 “某零售店”的业务描述，建立零售店的业务模型：

〃零售店具有产品销售、送货、自主定价及退款等业务；

〃售货员负责销售产品；司机负责给顾客送产品；产品定价及退款等事宜由零售店经理负责。

零售店的业务模型

注意：上图是从机构角度出发来显示业务实例和业务角色之间的交互。

2．以下是“银行信用业务”的业务描述，建立银行信用业务系统的业务模型：

〃银行的出纳员负责管理各个客户的账户；

〃对信用账户，则由专门的信用管理员来管理，信用管理员也同时负责对客户贷款资金的管理。

〃对于ATM则由分行服务器统一管理。（请同学自己完成）

3．根据以下陈述，创建“订货业务”的业务模型：

“采购员从仓库收到缺货通知单后，查阅订货合同。若已订货，则向供货单位发出催货请求。否则填写补充订货单脚供货单位。供货单位发货同时，向采购员发出提货通知单。”

（请同学自己完成）

实验步骤

1．右击工具栏，并选Customize…打开“自定义工具栏”窗口；

2．添加业务建模元素到工具栏中；

3．在Use Case Diagram窗口中，使用新增加的按钮进行业务建模。

2.uml开发实验指导书 篇二

1 UML概述

1.1 UML技术简介

面向对象的软件分析与设计(OOA&D)方法得到的OO(Object-Oriented)的模型,OOA&D方法从模型开始,就是识别对象、不断细化的过程,开发过程就是不断的迭代过程[1]。简明准确的建模是把握复杂系统的关键,是一个优秀系统开发中的重要的核心部分,其目的是把所要设计的结构和系统的行为沟通起来,对系统的体系结构进行可视化和控制,建模可以更好的理解正在构造的系统,并提供简化和和复用的机会。因此面向对象的分析和设计应该从建模开始。统一建模语言UML(Unified Modeling Language)融合了Booch、OMT和OOSE方法中的基本概念,是国际上标准的建模语言,是面向对象的分析和设计方法发展的产物,能够产生和长期其他技术学科的蓝图相似的草图。UML有统一语义和符号表示,可使项目根植于一个成熟的标准建模语言,从而可以拓宽软件系统的适用范围,并提高其灵活程度。统一建模语言(UML)是一种可视化(Visualizing)及文件化(Documenting)、规格化(Specifying)的软件建模语言。主要使用个案图、类别图、对象图、循序图、

合作图、状态图、活动图、组件图、部署图等可视化图形符号,来帮助分析设计与了解系统。UML具有一致的图形表示法和语义,同时也出现了许多UML工具,能够很好地支持软件设计和开发。例如UML的开发工具Rational Rose提供了面向对象的分析和设计(OOA和OOD)到面向对象编程(OOP)的平滑过渡机制,完整地体现了面向对象的软件工程思想[2]。

1.2 UML技术的发展历程

统一建模语言(Unified Modeling Language,UML)是Rational公司整合Booch、Rumbaugh与Jacobson三种方法而提出的对象导向建模工具,该语言最早起源于Booch与Rumbaugh在1995年10月提供给OOPSLA(Object-Oriented Programming,Systems,Languages&Applications)的统一方法(Unified Method),当初的版本是Version 0.8。在1996年,Rational公司将统一方法加入Jacobson的研究(例如使用个案模式等)及其它,并将版本更新为Version 0.9,且正式改名称为统一建模语言[3]。后经过不同公司的推广和发展,到目前为止UML工具更新的Version6.1.0。UML及其相关工具发展历程详见图1所示。

1.3 UML的静态建模机制和动态建模机制

在应用中,当采用面向对象技术设计系统时,首先是描述需求,其次根据需求建立系统的静态模型,以构造系统的结构。这两步所建立的模型都是静态的,包括用例图、类图、对象图、组件图和配置图等五个图形,是标准建模语言UML的静态建模机制[4]。第三步是描述系统的行为,所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言UML的动态建模机制。

UML包括静态建模机制和动态建模机制两大类。静态结构定义了系统中重要对象的属性和操作以及这些对象之间的相互关系;动态行为定义了对象的时间特性和对象为完成目标任务而相互进行通信的机制。UML定义了9种图用于系统建模,分为两类:静态结构图和动态行为图。

1.3.1 静态结构图

用于对系统的静态方面进行可视化、详述、构造和文档化。可以把系统的静态方面看作是对系统的相对稳定的骨架的表示,它由类、接口、协作、构件和节点等事物的布局组成。结构图包括:类图(Class diagram)描述系统中类的静态结构,它定义了系统中类的内部结构以及类之间的联系,用来捕获信息和事件中的对象;对象图(Object diagram)是类的实例化图;构件图(Component diagram)描述程序代码的物理结构;部署图(Deployment diagram)描述系统中软、硬件的物理体系结构,用于捕获系统硬件和软件构件的部署关系。

1.3.2 动态行为图

用于对系统的动态方面进行可视化、详述、构造和文档化。可以把系统的动态方面看作是对系统变化部分的表示,它由诸如随时间变化的信息流和在网络上构件的物理运动之类的事物组成。行为图包括:用例图(Use Case diagram)从用户的角度描述系统的功能,并指出各功能的执行者,说明执行者与提供的用例之间的某种联系;顺序图(Sequence diagram)描述几个对象之间的动作协作关系;协作图(Collaboration diagram)从另一个角度展示对象之间的动作协作关系。它可以和顺序图相互转换。在rational rose中可以由顺序图生成协作图;状态图(State diagram)描述一类对象具有的所有可能的状态以及状态转移关系;活动图(Active diagram)描述系统中各种活动的执行顺序。

1.4 UML可视化建模

UML可视化建模系统支持从系统需求、系统分析到系统设计的整个建模过程[5]。如表1所示。在需求分析阶段,UML可以用用例来捕获用户需求。通过需求建模,描述对系统感兴趣的外部角色及其对用例的功能要求。在分析和设计阶段,通过UML的静态建模机制和动态建模机制对问题域的对象建模,描述类的属性、类之间的关系、系统动态特征。编码是一个独立的阶段,其任务是用面向对象编程语言将来自设计阶段的类转换成实际的代码。UML模型还可作为测试阶段的依据。同时UML还支持对系统体系结构的建模。

2 MDA概述

模型驱动架构(Model Driven Architecture)是OMG(Object Management Group,对象管理组织)采用的一种新的系统开发方法架构,它提供了一种使用模型来进行系统的分析、设计、建构、开发、实作、维护和修改的方法,并经由模型的转换,自动转换产生软件系统相关程序代码[6]。

MDA是由OMG定义的一种软件开发架构,其关键是软件开发过程中每个阶段(或步骤)的产出均须建构出模式(Model),且该模式产出是下一个阶段的输入。

MDA的发展生命周期其实与其它系统开发模式(例如瀑布模式或RUP模式)的系统发展生命周期并没有差别,但主要的差别之一是在发展过程中步骤之产出,强调该产出是由计算机可理解的正式模式(Formal Model)表达。

2.1 MDA的流程

模型驱动架构(MDA)的主要流程和产出示意如图2所示[7]。其中PIM是分析与设计结果的重要产出,主要根据需求建模的结果,从如何支持企业运作的观点描述一个软件系统,并不涉及描述系统开发与运作之平台。PIM必须以有完整定义(Well-Defined)的语言来描述,一个具有完整定义的语言具有完整定义的语法(Syntax)与语义,且适合用计算机来自动解译。

一个PSM是一种特定平台的模式,也就是该模式相依于软件开发技术。对某一种PSM而言,可能仅具有该特定平台知识的开发者才能理解。一个PIM可被转成一个或多个PSM,因为一个系统可能包含几种技术,对每一个特定的技术平台需产生一个与其它技术分开的PSM,PSM间可借由沟通桥梁(Communication Bridge)的机制来互动。每一个PSM需被转成程序模式(或简称程序代码),因为一个PSM相依于其开发技术,因此PSM转成程序代码之步骤非常直接。若有多个PSM则会转出多种的程序代码,不同的程序代码间也须借由沟通桥梁的机制来互动。

2.2 MDA的转换

MDA的每一个转换(例如PIM→PSM,PSM→Code)须有清楚的转换定义,且该转换的工作主要是借由CASE工具来执行,也就是PIM可借由CASE工具转换成PSM,再转换成Code[8]。MDA的转换流程和案例分别如图3和图4所示。

在OMG的蓝图中,UML、MOF、XMI、CWM、OCL等一系列标准分别解决了模型驱动架构中的模型建立、模型扩展、模型转换等这几个方面的问题。OMG试图经由标准化的定义,扩大模型驱动架构的应用范围。同时经由这样一个可扩展的建模语言环境,软件开发厂商可以自行设计自己的建模语言,以及建模语言到可执行程序代码的转换对应,不过都必须处于OMG的标准化架构之下。如图5所示的模型转换与成果关联关系。

3 结论

通过统一建模语言(UML)和模型驱动架构(MDA)技术的推广和研究应用,使得系统开发模型标准化,增加系统模型的重用性,增加信息技术部门的产值,降低软件系统开发与维护的成本,缩短软件系统开发与导入的时间,增加软件产能,提升软件系统开发的国际竞争力。因此,UML技术必将为软件开发带来新的技术变革和崭新的工作流程。

参考文献

[1]蔡敏,徐慧慧,黄炳强.UML基础与Rose建模教程[M].北京:人民邮电出版社,2006:60-62.

[2]Unified Modeling Language[EB/OL].http://en.wikipedia.org/wiki/Unified_Modeling_Language#UML_2.x.

[3]徐宝文.UML与软件建模[M].北京:清华大学出版社,2006:47-48.

[4]O'Docherty M.面向对象分析与设计(UML 2.0版)[M].俞志翔,译.北京,清华大学出版社,2006:72-74.

[5]Coad P,Lefebvre E,De Luca J.彩色UML建模[M].王海鹏,译.北京:机械工业出版社,2008:110-112

[6]MDA framework[EB/OL].http://en.wikipedia.org/wiki/MDA_framework.

[7]施穆勒.UML基础、案例与应用[M].李虎,赵龙刚,译.北京:人民邮电出版社,2004:83-84.

3.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 class，它包含一个帐户最基本的属性及操作。而有些操作先定义为abstract，如余额的计算。然后再继承这个abstract class，我们可以有saving account 和checking account等等。不同的帐户有不同的余额计算方法，我们可以加上具体的算法。对于不同的帐户可能还有一些它特有的操作，我们也可以加上，比如saving account在存款达到多少时可以享受机票打折的优惠。通过类图不仅可以使设计者明确的表达自己的设计意图，也能帮组自己整理思路，充实及优化自己的设计。

3.顺序图

描述顾客在ATM机上取款时信息的流动情况。以时间为顺序。因为是示例图，所以整个过程是没有出现任何故障时的流程，并且只画到了取款结束。通过这个图，我们可以看出消息是如何在系统中不同对象之间进行交互。

通过流程图我们可以很清楚地看到系统是如何工作的，系统各部分之间的信息及控制是如何发送的，整个流程是否合理。流程图对我们的设计起到了很好的帮助作用。注意在本图没有一个生命线终端有一个“X”，这是因为这个流程中还未遇到有对象生命结束。当有对象生命结束时需在对应的生命线终端画“X”，表明这个对象在这时被销毁。

4.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工具软件的不熟识，导致出现了不该出现的错误。在设计阶段，顺序图中需要引入边界类和控制类，在识别对象职责的基础上，需要将消息转换为类的方法，为方法定义参数、返回值类型，便于计算机的实现。其中，为方法定义参数、返回值类型的时候，还是不能够快速准确的作出判断。

实验四：活动图

实验结果：

篇二：uml实验总结

实验一

1．源代码生成，在逻辑视图中绘制下图，生成java源文件 生成代码步骤：

“tools”-〉“java”-〉“genenate codes”。

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;} public string getlabel(){ return null;} public string tostring(){ return null;} public void main(string args){ return null;} } 2．进行逆向工程，自行找到一个项目软件源代码，进行逆向工程。（ftp上有一个小源程序文件）

逆向工程的实现

“tools”->“java”-〉“reverse engineer java„”。public class student { private string name;public student(){ } public void test(){ } } 实验二

根据下属需求，分析参与者和用例，并建立网络教学系统的用例图。网络教学系统的功能需求主要包括以下几个方面： ① 学生可以登录网站浏览信息、查找信息和下载文件。②

教师可以登录网站输入课程简介、上传课件文件、发布消息、修改和更新消息。③ 系统管理员可以对页面维护以及批准用户的注册申请。

录入课程简介

下载文件 查找信息

修改消息

注册信息处理

实验三

1、已知借书的活动图如图3所示，若要求欠费的读者需结清欠款才能借书，请完善该活动图，并在rose内绘制出来。

图3 借书处理活动图

2、图4为图书“借书”活动图，文字描述此活动图包括哪些活动，活动按照怎样的顺序发生？

图4 “借书处理”活动图

（1）读者查找所需的图书，若找到图书，将所需的图书带到借阅台；（2）工作人员输入读者信息，检查读者身份是否合法，如果读者身份合法，进入（3）；

（3）录入图书信息，并检查图书是否允许借阅，如果允许，则记录借阅信

息，否则直接进入（4）；

（4）检查是否还有图书需要录入，如果还需录入，进入（3），否则提借阅信息。

3、绘制“删除读者信息”用例的活动图。删除读者信息一般按照以下步骤进行：

（1）管理员在录入界面，输入待删除的读者名；

（2）“业务逻辑”组件在数据库中，查找待删除的读者名；

（3）如果不存在，则显示出错信息，返回步骤（1），如果存在则继续；（4）“业务逻辑”组件判断“待删除的读者”是否可以删除；

（5）如果不可以，则显示出错信息，返回步骤（8），如果可以则继续；（6）在数据库中，删除相关信息；（7）显示删除成功信息；（8）结束。

篇三：uml实训总结

实训总结（收获与体会）

通过一个学期的uml学习，我从书本上获取了基本的理论知识，而真正的学以致用，将书本理论知识运用到实际的过程，是这次uml实训的体现。

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

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

这次实训过程中，文档方面的编写，遇到了很多的问题，这些问题主要是对基础知识的理解和把握不够，不能融会贯通和学以致用，有时遇到困难的时候真的不知如何着手解决，但是，我始终相信的那句话“读万卷书，不如行万里路，行万里路不如名师指路”。所以，当遇到自己模糊和自己难以解决的问题时，向指导老师和懂的同学请教，帮助解决我遇到的问题，经过他们的讲解后，我下来自己在分析，在动手，从不理解到理解，从不会到会，从懂到懂，这是一个让我学习愉快的过程，在这个过程中，既可以丰富了自己的知识，还可以和老师和同学进行有效地方沟通。

在这次实训过程中，感触最深的也就是合作精神了。独木难成林，单枪匹马，那是最错误的思想和做法。这次我是深有感触了。对于一个系统的分析，到最终项目的完成，需要分析每个文档，然后在写出纸质的文档，而在每个文档中，内容比较多，分析也要求比较到位，所以单独凭借一个人去完成，似乎有点困难，于是我们小组，将每个文档进行分析，能独立成块就分配给每一个人，这样，每个人都有自己的任务，谁也不会闲着，既学到了知识，也充实了自己。另外一点，就是我深深体会到了积累知识的重要性。在实训当中我们遇到了不少难题，但是经过我们大家的讨论和老师细心的一一指导，问题得到了解决。两个月的实训结束了，收获颇丰，同时也更深刻的认识到要做一个合格的程序员并非我以前想像的那么容易，最重要的还是细致严谨。社会是不会要一个一无是处的人的，所以我们要更多更快地从一个学生向工作者转变，总的来说我对这次实习还是比较满意的，它使我学到了很多东西，为我以后的学习做了引导，点明了方向。

实训的日子即将结束，回想这一个过程，有过痛苦，有过烦恼，有过喜悦和有过成功。痛苦烦恼的是自己对所学书本知识掌握得不是很扎实，面对着从书本上学到的知识与实际联系不起来，总结起来就是自己的动手练习的时间太少。而喜悦的是，在做的过程中遇到了困难和问题，主动向老师和会的同学请教，然后再做，直至做正确做成功后的那种喜悦。

团队的力量是无穷的，通过组员的共同努力，完成了实训项目。虽然，我们这组的项目存在着诸多的不足和缺点，但这正是以后学习和工作需要弥补的。这次实训将为我以后进入社会提过了一笔宝贵的财富，是对我能力的一个见证。最后，不得不感谢指导教师熊飞老师的辛勤指导，和小组成员的共同努力！篇四：uml实验报告

学 生 实 验 报 告 书

实验课程名称

uml建模技术

开 课 学 院

指导老师姓名

学 生 姓 名

学生专业班级

2009 — 2010学年 第 一 学期

实验课程名称： uml建模技术

实验课程名称：

uml建模技术

篇五：uml实验——状态图 实验报告

南京信息工程大学实验(实习)报告

实验名称 状态图 实验(实习)日期 2014.04.26 得分 指导老师

系专业 班级

一、实验目的

1．熟悉活动图的基本功能和使用方法。

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

二、实验器材

1．计算机一台。

2．rational rose 工具软件。

三、实验内容

通过前面内容的学习，完成了对图书馆的图书馆管理系统的需求的初步分析，得出系统的用例图和相应的活动态。通过这两类图我们可以初步了解系统的业务处理过程，但对业务处理过程的处理状态间转换了解仍不够，这不利于设计人员对系统业务的进一步理解，而状态图能从对象的动态行为的角度去描述系统的业务活动。因此，指派你运用本节所学的状态图，完成如下任务：

1.完成图书业务模块中还书用例的状态图。

四、实验步骤 1．业务分析：由前面章节对图书馆管理系统中的还书主要业务的描述和分析可知，还书业务的动态行为是由：空闲（idle）、图书查找（finding）、还书（reversion）、失败（failure）、归还成功（success）5种状态及激活相互转换的事件。

2．绘制状态图：请您根据分析运用uml绘制还书用例的状态图。

分析：

还书的状态图，还书的主要业务都是由管理员来完成，首先管理员必须先登录系统，并通过验证后，便可以进行下一步的操作，查找该书的相关信息，如存在，则进行还书操作，如不存在该信息，则给出提示信息；

绘图步骤：

（1）在用例图中的还书（revesion）用例，单击右键，如图3.1所示，新建一个状态图，命名为revesion状态图。

（2）双击“receivesion”状态图，展开后，在左边的工具栏上选取一个实心圆点，此结点为开始结点；当还书的时候，操作者先要询问系统的状态，如果系统忙，操作者则必需等待，因此，得到系统的两种状态。

（3）操作者在询问系统和状态后，得到两种状态，如果系统忙，操作者必需要等待、结束，重返步骤（1）。

（4）如系统空闲，则进行对还书的信息进行查询操作；查询也有两种结果，一是查询得到该书的相关信息，二查询不到该书的相关信息；则此时有两种状态，需要建立两种状态。

（5）最后，操作者进行了操作后，系统会给出操作的结果给操作者；操作成功或失败，都会有提示信息给出。整个的还书的过程便完成。

（7）根据分析设计情况，进一步添加或细化状态图。

五、实验报告要求

1．整理实验结果。

2．小结实验心得体会。

5.uml开发实验指导书 篇五

基于UML面向对象需求分析的通讯录管理系统一、实验目的：

1、熟悉UML建模工具Visio2007

2、熟悉活动图

3、熟悉顺序图

二、所用软件：

Microsoft Visio2007

三、实验分析：

时代在发展，人们的交际圈越来越广泛，人际关系的记录也越来越多，所以我就编写了一个通讯录管理系统，此系统由JAVA语言写成，主要功能有：

1、添加联系人信息

2、模糊查找了联系人（按姓名、按号码）

3、修改联系人信息

4、删除联系人信息

通过这个系统，正快速准确的对联系人信息进行各种操作。

还有此系统运用的数据库为SQL-server数据库，各种联系人信心都储存在其中，用户输入数据，系统通过数据库数据的验证，来完成各种多通讯录的操作。

四、实验步骤

1、活动图 Customersystem写入数据库进入主页面数据库中查找号码选择业务显示查询结果号码不存在添加联系人输入数据数据库中查找姓名按号码输入号码查找联系人显示查询结果姓名不存在按姓名输入姓名数据库中查找姓名修改联系人输入联系人姓名姓名不存在修改联系人信息提取联系人信息写入数据库删除联系人输入联系人姓名数据库中查找姓名姓名不存在退出系统从数据库删除联系人信息

2、顺序图

用户选择业务增加查找修改删除顶层包：用户选择添加返回查找返回修改返回删除返回

五、心得体会

6.uml开发实验指导书 篇六

关键词：考勤,UML,B/S,管理系统

学生考勤管理是高校管理的重要组成部分, 对高校教育教学秩序的正常运行起着重要作用。传统人工方式的缺点有:数据统计量大, 造成人工统计中工作时间过长。传统方式中一般由班干部上交每日考勤表, 班干部上交不及时, 学生向辅导员 (班主任) 请假, 没有及时告诉班干部等, 都易造成统计中的数据错误和遗漏。传统方式实时性不强, 造成辅导员、学生不能及时了解自己的缺勤情况, 辅导员不能及时对缺勤学生进行批评教育等。当今随着计算机、网络技术的普及, 越来越多的政府机关、事业单位都积极利用各种计算机应用系统来解决问题, 以提高工作效率, 因此, 建立学生考勤管理系统来快速、准确的获取学生的考勤情况、旷课情况等, 保障考勤工作的实时性、准确性是必要的。

1 UML简介

面向对象建模领域有Booth、OMT和OOSE方法, 为了统一UML (统一建模语言) 被对象管理组织 (OMG) 采纳成为基于面向对象技术的标准建模语言。UML是当今使用较多的可视化建模的工业标准, 使用UML技术对学生考勤管理系统建模, 可以帮助不同的参与人员交流和改善开发过程。所以, 系统选用UML (统一建模语言) 来建模。目前, UML语言建模工具很多, 本系统采用Rational公司的Rose工具。

2 系统需求分析

系统要实现的总体功能是要快速、准确统计学生的旷课次数、时间、归寝等考勤情况, 满足辅导员 (班主任) 、教师及时掌握学生的考勤情况, 满足学生查询自己的考勤和处分情况, 及其学生通过网络提交请假申请的需求。整个系统需要有考勤信息录入、请假信息录入、晚归信息录入、处分信息录入、旷课信息查询、综合评分查询、处分信息查询、班级信息管理、考勤信息管理、处分信息管理、用户管理、权限管理等核心功能, 主要功能模块包括:

2.1 考勤信息录入模块

该功能主要实现任课教师或辅导员 (班主任) 录入学生的考勤信息、辅导员录入学生的处分信息, 学生的晚归信息, 学生录入自己的请假信息。

2.2 信息查询模块

该功能主要实现任课教师或辅导员 (班主任) 查询学生的旷课信息、综合评分信息和处分信息, 学生查询自己的旷课信息、综合评分信息和处分信息。

2.3 信息管理模块

该功能主要实现辅导员 (班主任) 修改自己的班级信息, 如:添加、删除班级学生和任课教师, 添加、修改、删除学生的旷课信息、综合评分信息和处分信息, 审批学生的请假信息。

2.4 系统管理模块

该功能主要实现添加、修改、删除学生考勤管理系统中的用户及指定其权限。

3 学生考勤管理系统的建模

3.1 确定参与者

在UML中, 用例图分为两部分:参与者和用例。参与者代表直接作用于系统的一个角色。根据对学生考勤管理系统需求的分析在该系统中, 主要存在以下参与者:学生、任课教师、专职辅导员 (班主任) 、系统管理员, 参与者的用例图如图1所示。

3.2 识别用例

在UML中, 使用用例是进行系统需求的最好方法, 在学生考勤管理系统中, 通过需求分析, 获取用例, 在该系统中用例描述如下:登录系统 (提供对用户身份的验证功能) 、信息录入 (提供学生的考勤信息、处分信息、晚归信息、请假信息的录入) 、信息查询 (提供对旷课信息、综合评分、处分查询) 、考勤管理 (提供辅导员 (班主任) 修改自己的班级学生信息、任课教师信息、处分信息、审批请假信息) 、系统管理 (提供添加、修改、删除学生考勤管理系统中的用户及指定其权限) 、打印 (提供了打印数据功能) , 本系统的用例图如图2所示。

3.3 用例事件流描述

以请假信息录入为例, 参与者为学生, 描述为提供了学生提出申请请假信息的功能, 前置条件为当学生不能按时上课时, 提出请假申请, 事件流程为学生登录系统, 通过验证后, 打开请假界面, 然后如实填写请假理由和时间, 检查无误后提交更新数据库, 辅导员 (班主任) 审核学生的请假信息, 填写审批意见, 确认更新数据库, 最后学生查看自己请假的返回信息。

4 结语

本文以学生考勤管理系统为例, 说明了UML在实际应用系统中的可视化建模机制。

参考文献

[1]王小平.基于UML的煤炭销售系统的设计与实现[J].榆林学院学报, 2011, (4) .