UMLROSE综合实验报告包括用例图类图组件图等等.docx

UMLROSE综合实验报告包括用例图类图组件图等等.docx

《UMLROSE综合实验报告包括用例图类图组件图等等.docx》由会员分享，可在线阅读，更多相关《UMLROSE综合实验报告包括用例图类图组件图等等.docx（12页珍藏版）》请在冰豆网上搜索。

UMLROSE综合实验报告包括用例图类图组件图等等

……………………………………………装……………………………………订……………………………………线……………………………………………………………

计算机科学与技术专业实验报告

课程名称：

UML统一建模语言

实验名称：

建模语言UML（ROSE）综合实验

班级

学号

成绩：

评语

指导教师签名：

年月日

一实验目的与要求

利用UML和ROSE工具，对一个系统建立完整的模型。

要求包含：

1、系统的简要描述

2、系统的结构模型：

•系统的用例图及其简要描述；

•系统类图和某种典型场景下的对象图；

•系统的构件图；

•系统的部署图；

3、系统的行为模型

•系统的顺序图；

•系统的协作图；

•重要结构元素的状态图；

•系统的活动图；

4、系统模型的自我评价

二、实验环境

WindowsXP/2003,IBMRationRose2003

三、实验容（实习模块、建模角度分析、主要界面、关键技术）

1、系统简要描述：

智方洗衣服连锁系统是专门用来管理干洗行业的业务软件。

主要功能包括有收取衣物，领取衣物，会员管理，基础资料管理，系统设置，衣物价格的设定，操作员管理以及统计分析等功能。

2、系统的结构模型：

⑴用例图（UseCaseDiagrams）：

是软件产品外部特性描述的试图。

用例视图从用户的角度来描述对软件产品的需求，分析产品所需的功能和动态行为。

用例图包括三方面容：

用例（Usecase）、参与者（Actor）、参与者之间的关系。

参与者是系统外部的一个实体（可以是任何的事物或人），它以某种方式参与了用例的执行过程。

而且参与者包括了人参与者和外部系统参与者。

用例是对一个系统或一个应用的一种单一的使用方式所作的描述，是关于单个活动者在与系统对话中所执行的处理行为的述序列。

用例是对系统的用户需求（主要是功能需求）的描述，表达了系统的功能和所提供的服务。

在图形上，用例用一个椭圆来表示。

用例间的关系：

泛化关系、包含关系和扩充关系。

①泛化关系：

一个用例可以被特别列举为一个或多个子用例。

子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变已继承的行为。

在图形上，用例间的泛化关系用带空心箭头的实线表示，箭头的方向由子用例指向父用例。

②包含关系：

一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。

包含关系把几个用例的公共步骤分离成一个单独的被包含用例。

③扩展关系：

一个用例可以被定义为基础用例的增量扩展。

扩展关系为处理异常或构建灵活系统框架提供了一种有效的方法。

而在该系统中，主要包含四个参与者：

系统管理员，店长，营业员和财务管理员。

下面就对该系统用例图作分析解释。

（Ⅰ）按参与者略分

1系统管理员：

相当于系统的一个超级用户，他具有以上各个参与者的最高权限。

他主要的任务是维护系统，维护数据库，对系统基本资料的设置。

当然作为系统的超级用户，他理所当然的具有各个用户所具有的功能。

（如图2-1所示）

2店长：

作为整个店的管理者，他具有会员管理，会员充值，当人手不足的时候，他会额外地负责收、领取衣物等功能。

（如图2-2所示）

3财务员：

主要负责财务管理相关模块。

（如图2-4所示）

4营业员：

作为系统的基层人员，主要负责系统的收、领取衣物功能。

（如图2-3所示）

图2-1

图2-2

图2-3

图2-4

（Ⅱ）按系统的重要模块细分

1系统设置模块：

设置系统基本信息，由系统管理员操控；如图2-5所示

2统计管理模块：

统计分析营业状况，由财务管理员操控；如图2-6所示

3收取衣物模块：

记录营业员收取衣物的状况，由营业员操控；如图2-7所示

4领取衣物模块：

记录顾客衣物领取的状况，由营业员操控；如图2-8所示

图2-5

图2-6

图2-7

图2-8

⑵类图：

是描述类、接口、协作以及它们之间关系的图，用来显示系统中各个类的静态结构。

类图包含七个元素：

类、接口、协作、依赖关系、泛化关系、实现关系以及关联关系。

常以对系统的词汇建模，对简单协作建模，对逻辑数据库模式建模这3种方法之一使用类图。

下面图2-9是对数据库模式进行类图建模：

图2-9

⑶组件图：

描述软件组件以及组件之间的关系，组件本身是代码的物理模块，组件图则显示了代码的结构。

组件图中通常包括：

组件、接口和关系。

在系统建模中建立组件图的用途有：

能帮助客户理解最终的系统结构；能使开发工作有一个明确的目标；有助于工作组的其他人员理解系统；有利于软件系统的组件重用。

以下图2-10是对该软件系统进行组件图建模

图2-10

⑷配置图：

显示了运行软件系统的物理硬件，以及如何将软件部署到硬件上。

配置图中通常包括：

节点、组件和关系。

以下图2-12是对该软件系统进行配置图建模

图2-12

3、系统的行为模型

动态模型描述了系统随时间变化的行为，这些行为是用从静态视图中抽取的系统的瞬间值的变化来描述的。

在UML的表现上，动态模型主要是建立系统的交互图和行为图。

交互图包括时序图和协作图；行为图则包括状态图和活动图。

（1）时序图：

时序图用来显示对象之间的关系，并强调对象之间消息的时间顺序，同时显示对象之间的交互，它可以与时序图互换。

包括了4个元素，分别是对象、生命线、激活和消息。

时序图强调按时间展开信息的传送顺序。

下面我们对该系统中部分对象进行建模。

下面对该系统的收取衣物和领取衣物两个重要环节进行时序图建模

图3-1是收取衣物；图3-1是领取衣物

图3-1

图3-2

（2）协作图：

协作图主要用来描述对象间的交互关系，它强调参加交互的各对象结构的信息。

协作图中包括如下元素：

对象、链、消息。

对象代表协作图交互中所扮演的角色，链代表协作图中连接在交互中所扮演的角色，而消息代表协作图中对象间通过发送的消息。

对系统动态行为建模，当按组织对控制流建模时，一般使用协作图。

图3-3是收取衣物的协作图

图3-4是获取衣物的协作图

图3-3

图3-4

（3）状态图：

状态图通过对类对象的生存周期建立模型来描述对象随时间变化的动态行为。

状态图通常包括状态和转换。

状态主要有以下几个部分组成：

名字、入口/出口动作、部转换等。

转换是状态间的关联。

它们用于对一个实体的不同状态间的关系模型。

转换刷5个部分组成：

源状态、目标状态、触发事件、监护条件、动作。

以下是该系统的重要对象的状态图建模

图3-5是衣服的状态图建模；图3-6是会员帐户的状态图建模

图3-7是洗衣机的状态图建模

图3-5

图3-6

图3-7

（4）活动图是一种特殊形式的状态机，用于对计算流程和工作流程建模。

活动图可以算是状态的一种扩展方式。

活动图与状态图不同，它除了描述对象状态之外，更突出了它的活动。

活动图包括动作状态和活动状态。

对象的动作状态是活动图最小单位的构造块，表示原子动作。

动作状态表示状态的入口动作。

对象的活动状态可以被理解成一个组合，它的控制流由其他活动状态或动作状态组成。

活动图还包括动作流。

当一个动作或活动状态结束时，该状态就会转换到下一个状态，这就是无触发转移或称为自动转移。

活动图开始于初始状态，然后自动转移到第一个动作状态，一旦该状态所说明的工作结束，控制就会不加延迟的转换到下一个动作或活动状态，并以此不断重复，直到遇到一个通知状态为止。

图3-8是领取衣物的活动图建模

图3-8

四、总结（收获与经验、教训与不足等）

通过这次的实验，我们更进一步了解了如何用RationalRose对某一个软件系统建立动态视图与用例视图。

UML可以描述软件开发过程从需求分析直到实现和测试的全过程。

通过UML能使那些不懂软件技术的人员清晰地了解本软件系统的一些功能和流程，也能够锻炼我们分析一个系统的能力，这是做好一个软件系统的重要前提。

因此，再以后的学习工作中，我们不能忽视这个重要的环节，相反，还要继续学习和深造它。