uml.org.cn UML和Rose教程.doc a)封装(Encapsulation) 在面向对象系统中，我们将信息与处理信息的功能组合起来，然后将其包装成对象，称为封装。 另一种理解封装的方法就是把应用程序分解成较小的功能组件。 例如，我们把与银行有关的信息，如帐号、节余、客户名和功能：开户、销户、存取款。我们 将这些信息与处理信息的功能封装成帐目对象。结果，银行系统对帐目的任何改变就会在帐目对象 中实现。它是所有帐目信息与功能的集合。 银行模型：有银行信用帐户的客户，增加支票帐户的透支额只要改变Account类。 Card Reader ATM Screen Accept Card ◆Prompt0 ◆Accept Card(0 ◆AcceptInput0 Eject Card0 Read Card0 Account ®Card Number PIN Cash Dispenser Balance Cash Balance ◆open0 ◆Provide Cash0 ithdraw Funds0 Provide Receipto Deduct Funds0 Verify Funds0 封装的另一好处是将系统改变的影响限制在对象内。 b)继承(Inheritance) 在面向对象系统中，继承机制可以根据旧对象生成新对象。子对象继承父对象的特性。 继承的主要好处之一是易于维护。（变化时只需改变父对象） 第页6
UML 和 Rose 教程.doc 第页6 a) 封装(Encapsulation) 在面向对象系统中，我们将信息与处理信息的功能组合起来，然后将其包装成对象，称为封装。 另一种理解封装的方法就是把应用程序分解成较小的功能组件。 例如，我们把与银行有关的信息，如帐号、节余、客户名和功能：开户、销户、存取款。我们 将这些信息与处理信息的功能封装成帐目对象。结果，银行系统对帐目的任何改变就会在帐目对象 中实现。它是所有帐目信息与功能的集合。 银行模型：有银行信用帐户的客户，增加支票帐户的透支额只要改变 Account 类。 封装的另一好处是将系统改变的影响限制在对象内。 b) 继承(Inheritance) 在面向对象系统中，继承机制可以根据旧对象生成新对象。子对象继承父对象的特性。 继承的主要好处之一是易于维护。（变化时只需改变父对象）
uml.org.cn UML和Rose教程.doc 父母 发色 眼睛 ®肤色 儿子 女儿 c)多态(Polymorphism) 多态的定义是多种不同形式、阶段或类型发生的事，表示特定功能有多种形式或实现方法。 画图 恩形状 drawMe0 圆 长方形 线 ◆drawMe0 ◆drawMe0 ◆drawMe0 假如没有多态代码为 Function shape.drawMe() case shape.Type case“Circle" shape.drawCircle(); case”Rectangle” shape.drawRectangle(): case”Line” shape.drawLine(); Endcase } 多态代码为 第页7
UML 和 Rose 教程.doc 第页7 c) 多态(Polymorphism) 多态的定义是多种不同形式、阶段或类型发生的事，表示特定功能有多种形式或实现方法。 假如没有多态代码为 Function shape.drawMe() { case shape.Type case “Circle” shape.drawCircle(); case”Rectangle” shape.drawRectangle(); case”Line” shape.drawLine(); Endcase } 多态代码为
uml.org.cn UML和Rose教程.doc Function drawO shape.drawMe(); } 1.3 Rational Rose的界面介绍 可视化建模将模型中的信息用标准图形元素直观地显示。 建立模型后，可以向所有感兴趣的方面显示这个模型，让他们对模型中的重要信息一目了然。 演示并解说Rose的主要功能和使用方法。 专Rational Rose-银行.mdl[das5 Diagram:Use Case View/银行模型】 5x Ele Edi Yiew Format Browse Report Query Iools Add-Ins Window Help x D它日品追昌▣品咒自是如室←aQ四@ 的银行 白C□Us9 Case View 星ia 目银行积型 Card Reader ATM Screen 甲Card Reader Accept Card 回园Account b ◆Prompti0 由目C4 sh Dispen5eg ◆Accept Card(0 AcdClass Use Case View::ATM Screen g白Loic1View Eject Card0 目Main Read Card0 由三Associations 白 白□Component View 毛Main Deploymont Viow Account Model Properties Card Number PIN Cash Dispenser 色8 alance cash日alance Open0 Provide Casho withdraw Funds( ◆Provide Receipto Deduct Funds0 erity Funds0 For Help,pross F1 机M 2.第二周：静态建模：用例和用例图(Use Case Diagram) 2.1角色和角色之间的关系 2.1.1角色 角色(actor)是与系统交互的人或事。角色是一个群体概念，代表的是一类能使用某个功能的 人或事，角色不是指某个个体。 第页8
UML 和 Rose 教程.doc 第页8 Function draw() { shape.drawMe(); } 1.3 Rational Rose 的界面介绍 可视化建模将模型中的信息用标准图形元素直观地显示。 建立模型后，可以向所有感兴趣的方面显示这个模型，让他们对模型中的重要信息一目了然。 演示并解说 Rose 的主要功能和使用方法。 2. 第二周：静态建模：用例和用例图(Use Case Diagram) 2.1 角色和角色之间的关系 2.1.1 角色 角色(actor)是与系统交互的人或事。角色是一个群体概念，代表的是一类能使用某个功能的 人或事，角色不是指某个个体
uml.org.cn UML和Rose教程.doc “所谓系统交互”指的是角色向系统发送消息，从系统中接受消息，或是在系统中交换信息。 只要使用用例，与系统相互交流的任何人或事都是角色。比如，某人使用系统中提供的用例，则该 人是角色：与系统进行通讯（通过用例）的某种硬件设备也是角色。 角色与系统进行通讯的收、发消息机制，与面向对象编程中的消息机制很像。角色是启动用例 的前提条件，又称为刺激物(stimulus)。 角色可以分为：主要角色(primary actor)指执行系统主要功能的角色，次要角色(secondary ctor)指使用系统的次要功能的角色，次要功能是指一般完成维护系统的功能（比如，管理数据库、 通讯、备份等)。 或分为：主动角色（可以初始化用例），被动角色（不能初始化用例）仅仅参与一个或多个用 例，在某个时刻与用例通讯。 2.1.2发现角色： ●使用系统主要功能的人是谁（即主要角色）？ ●需要借助与系统完成日常工作的人是谁？ ●谁来维护、管理系统（次要角色），保证系统正常工作？ ●系统控制的硬件设备有哪些？ ● 系统需要与哪些其他系统交互？其他系统包括计算机系统，也包括该系统将要使用的计算 机中的其他应用软件。其他系统也分二类，一类是启动该系统，另一类是该系统要使用的 系统。 ● 对系统产生的结果感兴趣的人或事是哪些？ <<Actor>≥ 保险代理 角色 角色类的图示方式 2.1.3角色之间的关系 角色是类所以拥有与类相同的关系描述： 第项9
UML 和 Rose 教程.doc 第页9 “所谓系统交互”指的是角色向系统发送消息，从系统中接受消息，或是在系统中交换信息。 只要使用用例，与系统相互交流的任何人或事都是角色。比如，某人使用系统中提供的用例，则该 人是角色；与系统进行通讯（通过用例）的某种硬件设备也是角色。 角色与系统进行通讯的收、发消息机制，与面向对象编程中的消息机制很像。角色是启动用例 的前提条件，又称为刺激物(stimulus)。 角色可以分为：主要角色(primary actor)指执行系统主要功能的角色，次要角色(secondary actor)指使用系统的次要功能的角色，次要功能是指一般完成维护系统的功能（比如，管理数据库、 通讯、备份等）。 或分为：主动角色（可以初始化用例），被动角色（不能初始化用例）仅仅参与一个或多个用 例，在某个时刻与用例通讯。 2.1.2 发现角色： 使用系统主要功能的人是谁（即主要角色）？ 需要借助与系统完成日常工作的人是谁？ 谁来维护、管理系统（次要角色），保证系统正常工作？ 系统控制的硬件设备有哪些？ 系统需要与哪些其他系统交互？其他系统包括计算机系统，也包括该系统将要使用的计算 机中的其他应用软件。其他系统也分二类，一类是启动该系统，另一类是该系统要使用的 系统。 对系统产生的结果感兴趣的人或事是哪些？ 2.1.3 角色之间的关系 角色是类所以拥有与类相同的关系描述：
-头水 UML和Rose教程.doc 雇员 合同工 季时工 把某些角色的共同行为（原角色中的部分行为），抽取出来表示成通用行为，且把它们描述成 为超类(superclass),即通用化关系。 这样在定义某一具体的角色时，仅仅把具体的角色所特有的那部分行为定义一下就行了，具体 角色的通用行为则不必重新定义，只要继承超类中相应的行为即可。表示方式如上图。 2.2用例和用例之间的关系 用例代表的是一个完整的功能。在L中的用例是动作步骤的集合。 2.2.1用例的特征： 用例总由角色初始化 用例为角色提供值 用例具有完全性 2.2.2发现用例 ·角色需要从系统中获得哪些功能？角色需要做什么？ ●角色需要读取、产生、删除、修改或存储系统中的某些消息吗？ ●系统中发生的事件需要通知角色吗？或者角色需要通知系统某件事吗？这些事件（功能） 能干些什么？ 如果用系统的新功能处理角色的日常工作是简单化了，还是提高了工作效率？ 。系统需要的输入/输出是什么信息？这些输入/输出信息从哪儿来到哪儿去？ ●系统当前的这种实现方法要解决的问题是什么（也许是用自动系统代替手工操作）？ 表示方式： 第0
UML 和 Rose 教程.doc 第页10 把某些角色的共同行为（原角色中的部分行为），抽取出来表示成通用行为，且把它们描述成 为超类(superclass)，即通用化关系。 这样在定义某一具体的角色时，仅仅把具体的角色所特有的那部分行为定义一下就行了，具体 角色的通用行为则不必重新定义，只要继承超类中相应的行为即可。表示方式如上图。 2.2 用例和用例之间的关系 用例代表的是一个完整的功能。在 UML 中的用例是动作步骤的集合。 2.2.1 用例的特征： 用例总由角色初始化 用例为角色提供值 用例具有完全性 2.2.2 发现用例 角色需要从系统中获得哪些功能？角色需要做什么？ 角色需要读取、产生、删除、修改或存储系统中的某些消息吗？ 系统中发生的事件需要通知角色吗？或者角色需要通知系统某件事吗？这些事件（功能） 能干些什么？ 如果用系统的新功能处理角色的日常工作是简单化了，还是提高了工作效率？ 系统需要的输入/输出是什么信息？这些输入/输出信息从哪儿来到哪儿去？ 系统当前的这种实现方法要解决的问题是什么（也许是用自动系统代替手工操作）？ 表示方式：