RationalRose建模实践指南.docx
- 文档编号:3655322
- 上传时间:2022-11-24
- 格式:DOCX
- 页数:32
- 大小:573.53KB
RationalRose建模实践指南.docx
《RationalRose建模实践指南.docx》由会员分享,可在线阅读,更多相关《RationalRose建模实践指南.docx(32页珍藏版)》请在冰豆网上搜索。
RationalRose建模实践指南
上机课的时间:
5.21——6.15,整4周时间。
上机目的:
熟悉和掌握RationalRose软件的操作和使用。
具体来说,通过这4周的上机课,希望大家了解、熟悉和掌握:
(1)在RationalRose中建立用例图、类图、对象图、时序图、协作图、状态图、活动图、组件图(构件图)、配置图的操作方法。
也即:
重点讨论创建(画)这些图的具体操作问题(建模)。
(这是通过上机课要达到的基本要求。
)
通过初步接触、学习Rose之后,针对该软件,今后的努力方向:
(2)进而加强理解和应用面向对象的概念、思想;
(3)进而加强对UML语言的掌握与应用(UML的基本概念、基本方法);
(4)再进而具备分析企业系统、规划和设计企业管理信息系统的能力,具有用统一建模语言对复杂对象进行分析、设计等描述的能力;
(5)并了解UML领域最新技术发展情况及研究前沿动态。
学习方法:
自学
上机计划及任务:
第1周:
掌握用例图、类图、对象图的创建。
第2周:
掌握时序图、协作图的创建。
第3周:
掌握状态图、活动图的创建。
第4周:
掌握构件图、配置图的创建。
上机课导读:
RationalRose是面向对象分析与设计建模最好用的工具。
它的应用领域宽,应用时间长,也较为成熟。
当前,它是IT企业常用的CASE工具之一。
计算机及软件专业的大学生、研究生和软件工程师必须学会它,掌握它,并用它来解决面向对象分析与设计建模的实际问题。
学习与探险一样,针对不会或未知的内容,需要保持一颗无比好奇的心态,去探索。
喜欢冒险和探险的朋友,让我们一起来吧!
RationalRose的理论基础是统一建模语言UML。
在学习RationalRose之前,必须对UML有所了解。
由于UML本身也较为复杂。
所以,学习RationalRose比学习PowerDesigner要困难得多。
但是,天下无难事,只要肯用心!
路漫漫其修远兮
吾将上下而求索
--屈原《离骚》
Rose这个软件,由于课堂上没有时间来教大家,大家需要自学这个软件。
所以,我的要求是:
在学习这个软件之前及任何与这个软件有关的内容之前,甚至是在学习的过程中,要首先摆好和始终摆好“自学”这个软件的心态。
UML的网上交流论坛:
RationalRose是面向对象的CASE工具,即面向对象分析和设计的强大工具。
它不仅可以帮助系统先建立模型,后编写代码,而且可以保证软件开发过程中代码和模型的一致性,从而一开始就保证系统结构的合理性。
软件开发团队利用RationalRose可以有效地进行团队交流和开发,及时发现开发过程中的缺陷,避免开发周期中不必要的成本消耗。
本文档的内容作为今后大家在上机时的一个自学的内容,尽最大的努力去屏蔽一些相关的理论知识,只讲操作,侧重于操作。
欲让你们知之其所以然,必要先让你们知之其所然。
本文档的内容毕竟有限,不能与相关的教材相提并论,只能起到一个“抛砖引玉”的作业。
要求大家下机以后,针对上机课中所产生的问题去查阅学习相关的教材和资料。
在本文档中,仅会根据上机目的、上机计划及任务、以及大家的学习方法,首先对RationalRose的有关操作进行简单的可视化介绍,介绍界面中各种工具的使用方法。
然后通过一些项目的案例分析,让大家练习。
在介绍RationalRose建模实践之前,再申明两点:
1、UML是RationalRose的理论基础,RationalRose是UML的实现工具;
2、UML只是一种可视化的建模语言,不是一种建模方法论。
因此,对于任何一个系统,要建什么模型,在什么时候建模,建多少个模型,完全由系统的开发者自己确定,这就是语言与方法论的差异。
======================================================================
第1周上机:
本次上机课的任务主要是初识RationalRose2003、熟悉RationalRose2003的操作界面、掌握创建模型、保存模型、发布模型等相关的基本操作。
掌握用例图、类图、对象图的创建。
实验内容:
实验一用例图、类图、对象图(2学时)
1、实验目的
掌握用例图、类图、对象图的UML表示方法,并掌握它们的设计与制作。
2、实验内容
以“网上选课系统”或“图书管理系统”为例,画出该系统的用例图、类图、对象图。
3、实验方案
(1)介绍“网上选课系统”或“图书管理系统”基本情况,让学生分析该系统的需求;
(2)让学生将自己的需求分析写成具体的文档,然后相互交流,最后选出最具体、最准确的需求分析报告;
(3)然后使用一个具体的UML工具,如用RationalROSE画出系统的用例图、类图、对象图,练习上述三种图形的具体设计技术;
(4)总结该实验过程后,写出详细的实验报告。
“网上求职招聘系统”用例建模案例分析
1、系统功能需求分析
“网上求职招聘系统”是为求职者和用人单位提供的一个智能化的人才市场,使求职者能找到满意的工作,使用人单位能及时找到合适的人才。
当访客进入系统时,他们可以根据自己的需求注册为求职者、招聘者或者管理员。
我们根据用户需求,将系统划分为3个功能模块,这3个功能模块的用例分析如下:
(1)求职者模块
●修改密码
●更新个人资料
●搜索招聘信息
●发布求职意向
●下载简历模板
●投递简历
●查看个人信箱
(2)招聘者模块
●修改密码
●更新企业资料
●发布招聘信息
●搜索应聘信息
●查看企业信箱
●回复求职者
●浏览所获简历
(3)管理员模块
●修改密码
●更新个人资料
●管理求职用户
●管理招聘用户
●管理新闻
2、“网上求职招聘系统”用例建模
从上述功能需求可以看出,该系统的参与者Actor(用户)就是求职者、招聘者、管理员。
根据每个模块的用例(功能),我们对每个模块进行用例建模。
(1)对系统的求职者模块进行用例建模,如下图所示:
(2)对系统的招聘者模块进行用例建模,如下图所示:
(3)对系统的管理员模块进行用例建模,如下图所示:
(4)对系统总体功能进行建模型,如下图所示:
部分考参资料:
一、初识RationalRose
解决面向对象问题的核心是建模,即建立系统的Rose模型。
软件系统内部的高内聚、低耦合程序及维护成本是软件设计所关注的问题,RationalRose是基于UML而产生的,是软件开发过程中不可或缺的一个建模工具。
它的主要特点有:
略。
一个Rose模型就是从各个不同的角度来透视系统的多张视图,它包括系统所有的UML图。
二、安装RationalRose
安装步骤如下:
略。
三、Rose界面简介
Rose的界面,由5个主要的部分组成:
浏览器窗口、文档窗口、菜单及标准工具栏、工具箱及绘图区、日志窗口。
各部分的作用简述:
浏览器窗口——用于浏览整个模型的层次及各个图形元素。
文档窗口——用于快速访问各个图形元素的documentation。
菜单及标准工具栏——
工具箱及绘图区——用工具箱里提供的工具在绘图区中画各种图形元素。
日志窗口——用于观看错误和各种各样的命令的结显报告。
四、在Rose中有四种视图
–UseCase视图
包、Actor、UseCase、对象、消息和关系
–逻辑视图
•包、类、状态和关系
–组件视图
•包、组件和依附关系
–拓扑视图
•节点和关系
五、Rose建模操作简介
1、创建模型
2、保存模型
3、发布模型
4、绘制用例图
用例图UseCaseDiagram:
是软件需求分析结果的可视化表示。
该图形中包含的模型元素有:
参与者Actor、用例UseCase、参与者和用例之间的关系。
参与者Actor:
参与者是系统外部的一个实体,是与系统进行交互的任何事、物、人,以某种方式参与系统的某一方面功能的执行过程。
参与者通过向系统输入或向系统发出某种请求来触发系统某一功能的执行。
参与者通常是以它们在系统中所扮演的角色来命名的,而不是以它们要执行的功能或它们本身的名字来命名的。
如赵薇在《还珠格格》中演“小燕子”,在戏中,赵薇就叫小燕子,而不是叫“赵薇”。
在定义用例之前,要先确定系统有哪些参与者。
从下面的一些问题有助于我们找出系统的参与者:
(1)谁或什么事物来使用系统?
(2)谁来安装系统?
(3)谁来启动和停止系统?
(4)谁来管理系统?
(5)谁来进行用户管理和安全管理?
(6)与该系统交互的是什么系统?
(7)谁提供信息给系统?
(8)谁从系统获取信息?
(9)由于系统对时间进行响应,“时间“是否也是一个参与者?
用例UseCase:
见后面。
关系:
见后面。
5、绘制类图
类Class:
6、绘制对象图
据我发现,好像在rose里,并没有单独提供对象图。
UML简介
UML的产生与发展:
自面向对象技术出现以后,面向对象技术在软件业得到了广泛应用。
为了解决复杂系统的开发,各种面向对象的建模语言开始出现。
在1989年—1994年,面向对象建模语言的数量从最初的不到10种,增加到了50多种。
20世纪90年代中期,以Booch1993、OOSE、OMT-2等为代表的新的建模语言被提出,建模语言逐渐走向成熟。
Booch是面向对象方法最早的倡导者之一,他提出Booch1993方法比较适合于系统的设计和构造。
Rumbaugh等人提出的OMT-2方法引入了各种独立于语言的表示符。
这种方法用对象模型、动态模型、功能模型和用例模型共同完成对整个系统的建模,所定义的概念和符号可用于软件开发的分析、设计和实现的全过程,软件开发人员不必在开发过程的不同阶段进行概念和符号的转换。
Jacobson于1994年提出了OOSE方法,该方法的最大特点是面向用例,并在用例的描述中引入了外部角色的概念。
用例贯穿于整个开发过程,包括对系统的测试和验证。
OOSE比较适合商业工程的需求分析。
用户由于不了解各种建模语言的优缺点及相互之间的差异,所以很难根据应用特点选择合适的建模语言。
1994年10月,GradyBooch和JimRumbaugh开始致力于统一建模语言的工作。
他们首先将Booch93和OMT-2统一起来,于1995年10月发布了第一个公开版本,称为统一方法UM0.8(UnitedMethod)。
1995年秋,OOSE的创始人IvarJacobson加盟统一建模的工作。
3人于1996年6月和10月分别发布了两个新的版本,即UML0.9和UML0.91,并将UM重新命名为UML(UnifiedModelingLanguage)。
UML0.9结合了Booch等3人建模语言的主要技术,并吸取了其他方法,如:
Fusion、Shlaer-Mellor、Coad-Yourdon的长处。
1996年,为完善、加强和促进UML的定义工作,UML成员协会成立。
当时的成员有DEC、HP、I-Logix、Itellicorp、IBM、ICONComputing、MCISystemhouse、Microsoft、Oracle、RationalSoftware、TI以及Unisys。
这一机构对UML1.0及UML1.1的定义和发布起了重要的促进作用。
UML语言的产生、发展与演化的过程如下图所示。
UML的组成:
UML将软件的体系结构分解为五个不同的侧面,称为视图(view)。
它们分别是:
用例视图(usecaseview)、设计视图(designview)、进程视图(processview)、实现视图(implementationview)、分布视图(deploymentview)。
设计视图和进程视图又可被统一称为逻辑视图(logicalview)。
每一个视图分别关注软件开发的某一侧面,它们由一种或多种模型图(diagram)构成。
模型图描述了构成相应视图的基本模型元索及它们之间的相互关系。
请大家注意这个地方的描述内容。
这里主要描述的是UML的各个组成部分及它们之间存在的包含关系。
简单地来说,一个模型(一个模型文件)里由4种视图组成,每一个视图反映的是系统的某一个侧面。
在每一个视图里,又则一个或多个模型图组成,在UML中,模型图一共有9种,分别是用例图、类图、对象图、时序图、协作图、状态图、活动图、组件图、配置图。
另外,在UML中,还存在一种图,叫做包图。
在上述每一个模型图diagram中,又包含了许多个基本的模型元系,以及它们之间有关系。
(1)用例视图:
用例视图用来支持软件系统的需求分析,它定义系统的边界,关注的是系统的外部功能的描述。
它从系统的使用者的角度,描述系统外部的动态行为和静态的功能组合。
系统的动态功能由UML里的交互图(interactiondiagram)、状态图(state-chartdiagram)、活动图(ativitydiagram)构成。
(2)逻辑视图:
逻辑视图定义系统的实现逻辑。
它描述了为实现用例视图描述的功能,在对软件系统进行设计时,所产生的设计概念,设计概念又称为软件系统的设计词汇。
逻辑视图定义了设计词汇的逻辑结构和存在于它们之间的语义联系。
设计词汇包括系统的类、协同、接口及其关系。
对逻辑视图的描述在原则上与软件系统的实现平台无关。
它相当于电子产品生产中的电原理图。
逻辑视图包含的模型图有:
类图(classdiagrams)、对象图(Objectdiagrams)、交互图(interactiondiagrams)、状态图(state-chartdiagrams)、活动图(activitydiagrams)。
(3)实现视图:
当系统的逻辑结构在逻辑视图里被定义之后,需要定义逻辑结构的物理实现。
这包括:
用什么文件保存相应的设计元素的源代码,各物理文件之间的关系,存放路径,等等。
实现视图就是定义这些内容的地方。
它相当于电子产品的印刷电路板的布线图。
实现视图描述的是组成一个软件系统的各个物理部件,这些部件以各种方式(如:
不同的源代码经过编译,构成一个可执行系统;或者不同的软件组件配置成为一个可执行系统;以及不同的网页文件,以特定的目录结构,组成一个网站,等等)组合起来,构成了一个可实际运行的系统。
实现视图包含的模型图有:
部件图(componentdiagrams)、交互图、状态图、活动图。
(4)分布视图:
当一个软件产品被安装以后,它将运行在计算机硬件系统上,如果软件产品是面向网络的应用系统,则有可能同时运行在多个计算机上。
分布视图用来描述软件产品在计算机硬件系统和网络上的安装、分发(delivery)和分布(distribution)情况。
在分布视图中,系统的静态特性用分布图(deploymentdiagrams)描述,动态特性用交互图、状态图、活动图描述。
UML是用于软件建模的图示化语言。
从软件的体系结构出发,UML把软件模型分成了五个视图,每个视图由不同的模型图构成。
模型图实际上就是UML的基本成员之一。
作为UML完整的概念模型,UML被理解为是由UML成员加上在其上的建模规则构成的:
UML=UML成员+UML建模规则
(图形)
UML成员是UML的基本组成部分,它和UML建模规则一起组成了UML。
UML成员可进一步划分为UML基本模型元素、关系和模型图(diagram):
UML成员=UML基本模型元素+关系十模型图
UML基本模型元素类似于电子产品电原理图里的集成电路符号,是模型图上包含的基本符号。
基本模型元素之间的语义上的联系,在UML里用关系来描述。
基本模型元素可分为四类,它们是:
结构模型元素、行为模型元素、分组模型元素、注解元素:
UML基本模型元素=结构模型元素+行为模型元素+成组元素+注解元素
1、结构模型元素
结构模型元素是UML模型里的名词,它们是模型的静态组成部分,代表软件系统里的概念的或物理的存在。
例如:
类就是最常用的一个结构模型元素,它代表一系列共享同样的属性(attributes)、操作(operation)、关系和语义的对象。
类在图上通常用一个矩形表示,其上同时还包含有类的名字及对其属性和操作的描述(如图2.2所示)。
结构模型元素一共有七种,它们是:
类、接口(interface)、协同、用例(usecase)、主动类(activeclass)、组件(component)、节点(node)。
在这些结构元素中,最常用的除了类之外,还有用例、接口、组件等(如图2-3所示)。
2、行为模型元素
行为模型元素(behavioralthings)是UML模型的动态组成部分。
它是模型的动词,代表软件系统在空间和时间上的行为。
行为模型元素包括交互(interaction)和状态机(statemachine)两类。
行为模型元素=交互十状态机
交互代表了系统内一系列的对象之间互相交换消息的行为。
相互交换信息的行为。
那什么是消息呢?
消息代表软件系统内两个对象中一个对象向另一个对象发出的执行某种操作的请求。
交互描述了什么?
交互描述了一系列的对象为完成某一项任务而联合采取的一系列的行动,其中包括这些行动在时间上的顺序,以及为执行这些动作序列,对象之间所发生的语义上的联系。
所以,
消息是描述交互的一个重要手段。
在模型图上,消息被表述为一个箭头(如图2.4所示)。
在描述一个对象的动态特性(特征,即状态)时,状态机也是一个有效的手段。
它描述的是对象在其生命周期内,在响应外界的事件的过程中,自身的状态的变化过程。
状态机包括了一系列的对象状态(如图2.5所示)、事件、由事件引起的状态之间的变迁以及变迁发生的同时对象所执行的动作。
3、成组模型元素
在对一个复杂的软件系统进行了建模的时候,必须要按分治的原则将一个大的问题分解为多个子问题分别描述和解决。
UML提供了支持分治原则的语言成分,这就是成组模型元素(groupingthings)。
成组模型元素只有一类,即模型包(package)。
模型包是UML中用来组织多种语言成分的通用手段。
结构模型元素、行为模型元素、甚至成组模型元素自身都可以置于模型包中。
模型包是纯概念性的,它只存在于软件系统的开发阶段。
在UML图中,模型包被绘制成文件夹的形状(如图2.6所示)。
模型包是UML的基本成组元素,它还有一些变体,如:
框架(framework)、模型(model)、子系统(subsystem)。
4、注解元素
在机械制和电子线路图中,注解是大量存在的,它用来标示产品的工艺要求。
在UML中,也存在着相似的语言成分,这就是注解元素。
注解元素只有一种,即标注。
标注用来描述施加于一个或多个模型元素的限制或对模型元素的语义加以说明。
标注在UML模型图上被绘制成一个折了一个角的长方形(图2.7),在此长方形中写标注的内容标注的内容可以是形式或非形式化的文本,也可以是图形。
5、关系
UML中的结构模型元素是UML模型的静态组成部分。
这些静态组成部分不是孤立存在的,它们被组合在一起互相协作以完成某项任务。
因此,结构模型元素之间必然存在着某种语义上的联系。
在UML中,这种联系是用关系表示的。
UML中共有4种关系.它们是:
(1)依赖关系(dependency)
(2)关联关系(association)
(3)泛化关系(generalization)
(4)实现关系(realization)
关联关系代表两个结构元素之间的某种语义上的连结,它是所有的关系中语义最弱的一种。
从定义上看,关联关系是双向的,意味着被关联关系连接的两个模型元素的地位是相同的。
如果两个结构模型元素之间存在着关联关系,则它们之间可以互相访问。
关联关系可以描述数据库记录之间的对应关系(如图2.8所示),可以描述结构模型元素之间的部分和整体关系。
结构模型元素之间的部分和整体关系是关联关系的一种,又被称为聚合关系。
依赖关系代表一个结构模型元素的语义依赖于另一个结构模型元素的语义。
当被依赖的结构模型元素的语义部分地发生变化时,依赖元素的语义也会发生变化。
可以用依赖关系描述的情形包括类之间的函数调用和变量引用(如图2.9所示)。
另外两类关系是泛化关系(图2.10(a))和实现关系(图2.10(b)),它们分别可以用来描述基类和导出类之间的继承关系和类之间的接口定义和实现的关系。
第二周上机:
======================================================================
实验二时序图和协作图(2学时)
1、实验目的:
熟悉并掌握时序图和协作图的画法。
2、实验内容:
本实验以在ATM取款机上取款为例,练习时序图和协作图的设计和实现。
3、实验方案:
(1)了解时序图和协作图的区别;
(2)画出ATM取款机的时序图和协作图;
(3)根据实验过程,写出详细的实验报告。
第三周上机:
======================================================================
实验三状态图和活动图(2学时)
1、实验目的:
理解并掌握状态图和活动图的画法。
2、实验内容:
使用状态图来描述图书管理系统中书和借书证的状态变化过程以及图书管理员维护读者信息和书目信息的活动图。
3、实验方案:
(1)分析对象的状态;
(2)用ROSE对各个对象的行为进行建模;
(3)检查共享事件状态图和活动图的一致性;
(4)根据实验过程,写出详细的实验报告。
图一
图二
图三
图四
图五
带有“泳道”进货过程的活动图(图六)
图七
图八
第4周上机:
======================================================================
实验四组件图和配置图(2学时)
1、实验目的:
理解并掌握组件图和配置图的画法。
2、实验内容:
本实验以在图书管理系统为例,练习组件图和配置图的设计和实现。
3、实验方案:
(1)掌握组件图与配置图的画法;
(2)了解组件图的作用、了解配置图的作用;
(3)根据实验过程,写出详细的实验报告。
图一
图二
图三
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- RationalRose 建模 实践 指南