Rose 的用法

 

一、模型与建模

模型:对问题的书面上的无歧义文字或图形的描述.简言之, 模型是对现实的简化. 通过模型, 人们可以了解所研究事物的本质.

建模:对现实系统进行适当的过滤,用适当的表现规则描述出简洁的模型。

建模是一种深入解决问题的方法。

建模的原则:

(1). 选择建立什么样的模型对如何发现和解决问题具有重要的影响。正确的模型有助于提高开发者的洞察力。

(2)每个模型可以有多种表现方式,使用者的身份和使用的原因是评判模型好坏的关键。

(3)最好的模型总是能够切合实际。模型是现实的简化,必须保证简化过程不会掩盖任何重要的的细节。

(4)孤立模型是不完整的,

软件建模的实现过程:

软件建模的作用是把来源于现实世界的问题转化为计算机可以理解和实现的问题。

软件建模的实现过程是从需求入手,用模型表达分析设计过程,最终将模型

二、UML

1、UML(United Modeing Languange)统一建模语言:是一种基于面向对象的可视化建模语言。

UML 采用了一组形象化的图形(如类图)符号作为建模语言, 使用这些符号可以形象地描述系统的各个方面

UML 通过建立图形之间的各种关系(如类与类之间的关系)来描述模型.

2、UML 中一共有 10 种图: 类图、对象图、包图、组件图、部署图、用例图、时序图、协作图、状态图、活动图(前五个静态模型图: 描述系统的静态结构;后动态模型图: 描述系统行为的各个方面)

3、UML 中的关系主要包括 4 种: 关联关系(association)、依赖关系(dependency)、泛化关系(generalization)、实现关系(realization)

三、用例图

1、用例图(Use Case Diagram): 也称为用户模型图, 是从软件需求分析到最终实现的第一步, 它是从客户的角度来描述系统功能.

2、用例图包含 3 个基本组件: 参与者(Actor), 用例(Use Case), 关系:

(1)参与者(Actor): 与系统打交道的人或其他系统即使用该系统的人或事物. 在 UML 中参与者用人形图标表示

(2)用例(Use Case): 代表系统的某项完整的功能. 在 UML 中使用一个椭圆来表

(3)关系: 定义用例之间的关系 ------ 泛化关系, 扩展关系, 包含关系

 

A 用例之间的关系 ---- 泛化关系

泛化关系: 表示同一业务目的(父用例)的不同技术实现(各个子用例). 在 UML 中, 用例泛化用一个三角箭头从子用例指向父用例. 以下是某购物网站为用户提供不同的支付方式

 

 

B 用例之间的关系----包含关系

一个用例可以包含其他用例具有的行为, 并把它包含的用例行为作为自身行为的一部分. 在 UML 中包含关系用虚线箭头加 “<<include>>”, 箭头指向被包含的用例

 

C  用例之间的关系----扩展关系

如果在完成某个功能的时候偶尔会执行另外一个功能, 则用扩展关系表示.在 UML 中扩展关系用虚线箭头加 “<<extend>>”, 箭头指向被扩展的用例

四、类图

类图是面向对象系统建模中最常用的图. 是定义其他图的基础.

类图主要是用来显示系统中的类, 接口以及它们之间的关系.

类图包含的主要元素有类, 接口和关系. 其中关系有关联关系, 泛化关系, 依赖关系和实现关系. 在类图中也可以包含注释和约束.

1、类的表示法

1)类是类图的主要组件, 由 3 部分组成: 类名, 属性和方法. 在 UML 中, 类用矩形来表示, 顶端部分存放类的名称, 中间部分存放类的属性, 属性的类型及值, 底部部分存放类的方法, 方法的参数和返回类型.

2)在 UML 中可以根据实际情况有选择的隐藏属性部分或方法部分或两者都隐藏

3)在 UML 中, 公有类型有 + 表示, 私有类型用 – 表示, 保护类型用 # 表示. UML 的工具开发商可以使用自己定义的符号表示不同的可见性

2、接口的表示法

1)接口中包含方法, 但不包含属性. 在 UML 中接口用一个带有名称的圆圈表示, 并且通过一条实线与它的模型元素相连

2)有时候接口也使用普通类符号表示

3、类之间的关系 ---- 泛化关系

1)在 UML 中, 泛化关系用来表示类与类, 接口与接口之间的继承关系. 泛化关系有时也称为”is a kind of”关系

在 UML 中泛化关系用一条实线空心箭头由子类指向父类

4、类之间的关系 ---- 实现关系

1)在 UML 中, 实现关系用来表示类与接口之间的实现关系.

2)在 UML 中实现关系用一条虚线空心箭头由子类指向父类

5、类之间的关系 ---- 依赖关系

1)对于两个相对独立的系统,当一个系统负责构造另一个系统的实例,或者依赖另一个系统的服务时,这两个系统之间体现为依赖关系. 例如生产零件的机器和零件,机器负责构造零件对象; 充电电池和充电器,充电电池通过充电器来充电;自行车Bicycle和打气筒Pump,自行车通过打气筒来充气

2)在现实生活中,通常不会为某一辆自行车配备专门的打气筒,而是在需要充气的时候,从附近某个修车棚里借个打气筒打气。在程序代码中,表现为Bicycle类的expand()方法有个Pump类型的参数。以下程序代码表示某辆自行车先后到两个修车棚里充气:

6、类之间的关系 ---- 关联关系

1)对于两个相对独立的系统,当一个系统的实例与另一个系统的一些特定实例存在固定的对应关系时,这两个系统之间为关联关系。例如客户和订单,每个订单对应特定的客户,每个客户对应一些特定的订单;公司和员工,每个公司对应一些特定的员工,每个员工对应一特定的公司;自行车和主人,每辆自行车属于特定的主人,每个主人有特定的自行车。而充电电池和充电器之间就不存在固定的对应关系,同样自行车和打气筒之间也不存在固定的对应关系。

2)Person 类与 Bicycle 类之间存在关联关系,这意味着在 Person 类中需要定义一个 Bicycle 类型的成员变量

在现时生活中,当骑自行车去上班时,只要从家里推出自己的自行车就能上路了,不象给自行车打气那样,在需要打气时,还要四处去找修车棚。因此,在Person类的goToWork()方法中,调用自身的bicycle对象的run()方法。假如goToWork()方法采用以下的定义方式:

那就好比去上班前,还要先四处去借一辆自行车,然后才能去上班。

7、关联关系的名称: 关联关系可以有一个名称, 用于描述该关系的性质.  此关联名称应该是动词短语, 因为它表明源对象正在目标对象上执行动作.

8、关联关系的角色

当一个类处于关联的某一端时, 该类就在这个关系中扮演一个特定的角色. 具体来说, 角色就是关联关系中一个类对另一个类所表现的职责. 角色名称是名词或名称短语.

9、关联关系的多重性:关联关系的多重性是指有多少对象可以参与该关联, 多重性可以用来表达一个取值范围, 特定值, 无限定的范围.

10、  关联关系 ---- 聚合关系

1)           聚合关联是一种特殊的关联. 它表示类间的关系是整体与部分的关系. 简言之: 关联关系中的一个类描述了一个较大的事物, 它由较小的事物组成.

2)           聚合关系描述了 “has a” 的关系, 即整体对象拥有部分对象

3)           整体和部分之间用空心菱形箭头的连线连接, 箭头指向部分

11、关联关系 ---- 组成关系

1)组成关系是更强形式的聚合.

2)组成关系中, 整件拥有部件的生命周期, 所以整件删除时, 部件一定会跟着删除. 而且, 多个整件不可以同时共享同一个部件。

3) 聚合关系中, 整件不会拥有部件的生命周期, 所以整件删除时, 部件不会被删除. 再者, 多个整件可以共享同一个部件.

4) UML 中组成关系用实心的菱形实线表示

12、关联关系 ---- 导航性

1)导航性表示可从源类的任何对象到目标类的一个或多个对象遍历. 即: 给定源类的一个对象, 可以得到目标类的所有对象. 可以在关联关系上加上箭头表示导航方向.

2) 只在一个方向上可以导航的关联称为单向关联,用一个带箭头的方向表示; 在两个方向上都可以导航的关联称为双向关联, 用一条没有箭头的实线表示.

五、时序图

1)时序图用于描述对象之间的传递消息的时间顺序, 即用例中的行为顺序.

2)当执行一个用例时, 时序图中的每条消息对应了一个类操作或者引起转换的触发事件.

3)在 UML 中, 时序图表示为一个二维的关系图, 其中, 纵轴是时间轴, 时间延竖线向下延伸. 横轴代表在协作中各个独立的对象. 当对象存在时, 生命线用一条虚线表示, 消息用从一个对象的生命线到另一个对象的生命线的箭头表示. 箭头以时间的顺序在图中上下排列.

 

1、              时序图中的基本概念

1) 对象: 时序图中对象使用矩形表示, 并且对象名称下有下划线. 将对象置于时序图的顶部说明在交互开始时对象就已经存在了. 如果对象的位置不在顶部, 表示对象是在交互的过程中被创建的.

2) 生命线:  生命线是一条垂直的虚线. 表示时序图中的对象在一段生命周期内存在. 每个对象底部中心的位置都带有生命线.

3) 消息: 两个对象之间的单路通信. 从发送方指向接收方. 在时序图中很少使用返回消息.

4) 激活: 时序图可以描述对象的激活和钝化. 激活表示该对象被占用以完成某个任务. 钝化指对象处于空闲状态, 等待消息. 在 UML 中, 对象激活时将对象的生命线拓宽为矩形来表示的. 矩形称为计划条或控制期. 对象就是在激活条的顶部被激活的. 对象在完成自己的工作后被钝化.

5) 对象的创建和销毁: 在时序图中, 对象的默认位置是在图的顶部. 这说明对象在交互开始之前就已经存在了. 如果对象是在交互过程中创建的, 那么就应该将对象放到中间部分. 如果要撤销一个对象, 在其生命线终止点处放置 “ X” 符号.

六、活动图

 在 UML 中, 活动图本质上就是流程图. 它用于描述系统的活动, 判定点和分支等.

1、活动图中的基本概念

1)动作状态: 原子的, 不可中断的动作, 并在此动作完成之后向另一个动作转变. 在 UML 中动作状态用圆角矩形           表示, 动作状态所表示的动作写在圆角矩形内部.

2) 分支与合并:  分支在软件系统中很常见. 一般用于表示对象类所具有的条件行为. 用一个布尔型表达式的真假来判定动作的流向. 条件行为用分支和合并表达.在活动图中, 分支用空心小菱形      表示. 分支包括一个入转换和两个带条件的出转换, 出转换的条件应该是互斥的, 须保证只有一条出转换能够被触发. 合并包含两个带条件的入转换和一个出转换.

3) 分叉与汇合: 分叉用来描述并发线程, 每个分叉可以有一个输入转换和两个或多个输出转换. 每个转换都可以是独立的控制流. 汇合代表两个或多个并发控制流同步发生, 当所有的控制流都达到汇合点后, 控制才能继续往下进行. 每个汇合可以有两个或多个输入转换和一个输出转换. 在 UML 中分叉和汇合用一条粗直线              表示

4) 泳道: 泳道将活动图中的活动划分为若干组, 并将每一组指定给负责这组活动的业务组织. 泳道区分负责活动的对象, 明确地表示哪些活动是由哪些对象进行的. 每个活动指定明确地属于一个泳道. 在活动图中, 泳道用垂直实线绘出, 垂直线分隔的区域即为泳道

七、状态图

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

1、状态图中的基本概念

1)状态: 用圆角矩形表示. 状态名称表示状态的名字, 通常用字符串表示. 一个状态的名称在状态图所在的上下文中应该是唯一的.

2) 转换: 用带箭头的直线表示. 一端连着源状态, 一端连着目标状态.

3) 初始状态: 每个状态图都有一个初始状态. 此状态代表状态图的起始位置. 初始状态只能作为转换的源, 不能作为转换的目标, 并且在状态图中只能有一个. 初始状态用一个实心圆表示.

4) 终止状态: 模型元素的最后状态, 是一个状态图的终止点. 终止状态在一个状态图中可以有多个.

八、协作图

协作图(也叫合作图)是一种交互图.

时序图主要侧重于对象间消息传递在时间上的先后关系, 而协作图表达对象间的交互过程及对象间的关联关系。

九、对象图简介

对象图是类图的一个实例, 用于显示系统执行时的一个可能的快照. 即在某一个时间上系统可能出现的样子. 对象图用带下划线的对象名称来表示对象.

十、包图简介

1)包图: 由包和包之间的关系组成. 包的图标就如同一个带标签的文件夹.

2)包提供了一种用于组织各种元素的分组机制. 在 UML 中, 包用来对元素进行分组, 并为这些元素提供命名空间. 包所拥有的或者引用的所有元素称为包的内容, 包没有实例.

十一、组件图简介

1) 组件图用来建立系统中各组件之间的关系, 各组件通过功能组织在一起.

2) Javabean, ejb, jsp 都是组件。在UML中,组件使用在左侧有两个小矩形的大矩形来表示。

3) 组件图可以用来设计系统的整体构架。

十二、部署图简介

1) 部署图用来帮助开发者了解软件中的各个组件驻留在什么硬件位置, 以及这些硬件之间的交互关系。

2) 节点: 用来表示一种硬件, 可以是打印机, 计算机等.节点的标记符号是一个三维框,在框的左上方包含了节点的名称。

3) 通信关联: 节点通过通信关联建立彼此的关系,采用从节点到节点绘制实线来表示关联。

实验一 实验名称:业务建模 一、实验目的 1.熟悉业务建模内容。 2.掌握如何使用建模工具rational rose绘制业务模型图。 3.学习使用Microsoft Project对题目进行进度安排。 二、实验器材 1.计算机一台。 2.Rational Rose 工具软件。 三、实验内容 根据图书管理系统开发进度,在完成对系统的需求建模,得到用例模型后,应针对每个用例进行业务分析,说明其具体的业务流程,现系统分析部指派您完成该项任务。 要求: 1、创建业务用例模型。(参与者--用例)。 2、用活动图来描述系统核心业务过程。 3、创建业务对象模型。 四、实验步骤 1. 系统当前业务描述 …………………………… 2. 系统业务用例模型 ………………………….. 3. 核心业务用例的活动图 …………………………. 4. 系统业务对象模型 ………………………… 五、 实验心得 实验二 用例建模 一、 实验目的: 通过学生对提供的案例进行用例建模,熟练掌握用例建模技术。 二、主要实验仪器设备及环境 1. 计算机:安装有:操作系统为windows 2000,WindowsXP Professional; 2. 软件:National rose 三、实验内容: 1. 认真阅读案例的需求,根据其内容建立相应的用例模型; 2. 选择主要用例进行事件流分析,并把分析结果作为说明文档附在用例模型中; 四、实验步骤: 1. 系统参与者 2. 系统用例 3. 系统用例模型 4. 用例文档(主要用例) 五、实验心得 (对用例模型、用例的粒度、关系的理解) 实验三 顺序图 一、实验目的 1.理解顺序图的基本概念。 2. 掌握在Rational Rose中绘制交互图的操作方法。 3. 细化用例文档中的事件流,绘制顺序图。 二、实验器材 1.计算机一台。 2.Rational Rose 工具软件。 三、实验内容 通过对系统动态模型部分的学习,根据用例建模阶段的用例图和用例文档,对对应的用例实现用顺序图来描述系统的动态特性。完成如下任务: 对选定系统中的主要用例进行动态建模(顺序图)。 四、实验步骤 1.在logic view中创建“分析模型”包,在该包中添加“用例实现”包,在“用例实现”包中添加跟踪关系图(类图),在跟踪关系图中描述用例与用例实现的关系。为系统中主要的用例实现添加顺序图。 如下图: 2.在logic view中分别添加三个包(构造型:layer):边界层、控制层、实体层。主要根据用例文档来识别分析类(边界类、控制类、实体类)。如下图: 3.对主要的用例实现,根据细化用例文档中的主要事件流。 ……………………………………… 4.结合用例实现中识别出来的分析类,绘制顺序图。如下图: ……………………………………… 五:实验心得: 实验四 系统分析类图 一、实验目的 1.识别分析类之间的关系、类的属性和操作。 2.使用ROSE软件构建系统的分析类图。 二、实验器材 1.计算机一台。 2.Rational Rose 工具软件。 三、实验内容 根据***系统开发进度,在完成对系统的需求建模,得到用例模型后,应针对每个用例进行分析,识别出分析类,识别类的属性和方法,构建每个用例的VOPC图,综合所有用例的VOPC图,构建系统的分析类图 要求: 1、针对每个用例实现构建其VOPC图 2、综合所有VOPC图,构建系统的分析类图 四、实验步骤 1. 对每个用例实现识别分析类,根据需求、常识识别类的属性,根据交互图识别类的方法,在每个用例实现下创建一个类图,命名为 **用例的VOPC图(借书用例VOPC) 2. 综合所有VOPC图,在系统分析包中创建一个类图,命名为系统分析类图 3. 通过用例实现顺序图中的消息映射出分析类的操作(如下图)。 ……………………………………. 4. 根据用用例文档映射出类的属性(如下图)。 ……………………………………….. 五、实验总结 实验五 实验名称:子系统和接口 一、实验目的 1.基于分析阶段的BCE架构,抽取子系统。 2.根据包设计原则,对系统组织结构进行设计 。 二、实验器材 1.计算机一台。 2.Rational Rose 工具软件。 三、实验内容 根据指定系统的开发进度,已经完成对系统用例分析,应用BCE架构构建了系统的组织结构。本次实验主要根据抽取子系统的方法设计子系统、子系统接口,然后根据打包原则重构系统组织结构 要求: 1、抽取子系统,设计相应接口 2、利用包图设计系统架构 四、实验步骤 1. 抽取子系统 子系统是一种特殊的包,采用构造型《subsystem》扩展包的寓意,子系统内部是完全封装的,子系统提供接口对外服务。  你抽取子系统是依据什么角度(从那几个方面收取子系统?教材P263) ………文字描述子系统及抽取角度…………………… 2. 接口设计 接口是子系统对外提供的服务。接口采用构造型《interface》通过对类进行扩展表示 ……………子系统和接口的关系及几口中的操作,如P262 8-11图…….. 3. 更新软件架构 …………系统架构更新后的包图,如图8-17………………. 五、 实验心得 实验四 (系统静态模型)分析类图 一、实验目的 1.识别分析类、关系、类的属性和操作。 2.使用UML工具软件构建系统的分析类图。 二、实验器材 1.计算机一台。 2.Rational Rose 工具软件。 三、实验内容 根据***系统开发进度,在完成对系统的需求建模,得到用例模型后,应针对每个用例进行分析,识别出分析类,识别类的属性和方法,构建每个用例的VOPC图,综合所有用例的VOPC图,构建系统的分析类图 要求: 1、针对每个用例实现构建其VOPC图 2、综合所有VOPC图,构建系统的分析类图 3、根据顺序图为类添加操作 4、根据需求和用例文档为类添加属性 四、实验步骤 1. 对每个用例实现识别分析类,根据需求、常识识别类的属性,根据交互图识别类的方法,在每个用例实现下创建一个类图,命名为 **用例的VOPC图(借书用例VOPC) 1) 添加VOPC图 2) 打开vopc图,把该用例中的边界类、控制类、实体类拖入其中,并建立关系 2. 通过用例实现顺序图中的消息映射出分析类的操作(如下图)。 把每个类收到的消息映射为该类的一个操作。下面以申请边界类为例: 3. 根据用用例文档映射出类的属性(如下图)。 1) 打开某个类的规格说明,选择“属性”选项卡,在编辑窗口中点击鼠标右键,在菜单中“Insert”,可以为类添加属性 . 2) 例: 4. 综合所有的VOPC图,创建完整的系统分析类图 1) 在分析模型包下添加一个类图:命名为系统分析类图 2) 打开系统分析类图,把边界类包、控制类包、实体类包中的所有类拖入系统分析类图中,由于类的属性和操作、类之间的关系已经在每个类图中已经描述,所以在系统分析类图中会自然体现出来。 五、实验总结
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值