信息管理与信息系统实训.pdf

《信息管理与信息系统实训.pdf》由会员分享，可在线阅读，更多相关《信息管理与信息系统实训.pdf（28页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、1 信息管理与信息系统实训复习大纲 第 1 章 系统分析与设计概述 本章介绍软件开发、软件工程系统分析与设计的发展，并简要说明面向对象软件开发方法。11 软件与软件工程 软件定义 软件危机 软件工程定义 软件工程三要素过程、方法、工具 软件过程的基本活动-分析、设计、演化 软件过程模型/软件生存周期模型 软件质量、需求工程、需求开发四阶段 软件规格说明-12 面向对象软件开发方法 COA、OOD、OOT、OOSE OOD 的两个阶段系统设计和概要设计/两个层次 软件体系结构 软件开发方法、耦合与内聚、模块化【分治算法的实践】、设计模式的概念 MVC 面向对象的编程包括两个过程【程序设计和程序实

2、现】、面向对象与面向方面 第二章 统一建模语言 UML 2.1 UML 和软件体系结构 1.UML 是用于描绘软件蓝图的标准语言。1)建模的原则:准确、分层、分治、标准 2)统一建模语言 UML 就是满足这四个原则的建模语言。3)UML 可用于对软件密集型系统进行：可视化 说明 建造 建档 UML 的构成UML=UML 成员+UML 建模规则 UML 成员UML 基本模型元素、关系、模型图 结构模型【7 种】-类、接口、用力 协同 主动类 组件 结点 行为模型交互 状态机 五中视图用例视图 逻辑视图 进程视图 实现视图 分布视图 模型图用例图 类图 对象图 时序图 协作图 活动图 状态图 组件

3、图 部署图 2.UML 根据软件体系结构对软件进行建模 1)分层是软件建模的重要原则 2)为了表达不同的软件开发相关人员在软件开发周期的不同时期看待软件产品的不同侧重面,需要对模型进行分层。3)UML 根据软件产品的体系结构（architecture）对软件进行分层 4)软件体系结构由一系列的决定组成，这些决定定义了如下内容：2 a)软件系统的组织；b)构成软件系统的结构元素的结构及它们之间的接口；c)结构元素的行为及元素之间的协同（collaboration）；d)结构元素的不断组合以构成日渐完备的子系统的过程；e)指导软件建造过程的软件构筑风格（architectural style）：静

4、态和动态元素之间的 接口 协同 构成（composition）。5)软件体系结构不仅仅决定软件的结构和行为，而且还决定软件的 a)用途 b)功能 c)性能 d)应变性(resilience)e)可重用性 f)经济和技术方面的限制和折衷 g)以及美学考虑（aesthetic concern）。6)UML 将软件的体系结构分解为五个不同的视图(view)。a)用例视图（Use case view）用例视图用来支持软件系统的需求分析，它定义系统的边界，关注的是系统的外部功能的描述。它从系统的使用者的角度，描述系统的外部的动态行为和静态的功能。系统的动态功能由 UML 以下模型图描述：交互图(inte

5、raction diagram)状态图(state-chart diagram)活动图(activity diagram)b)设计视图(design view)逻辑视图定义系统的实现逻辑。描述为实现用例图描述的功能，在对软件系统进行设计时,所产生的设计 概念，设 计概念又 称为软件 系统的设 计词汇(vocabulary)。逻辑视图定义了设计词汇的逻辑结构和存在于它们之间的语义联系。设计词汇包括系统的:类 协同 接口及其关系 对逻辑视图的描述在原则上与软件系统的实现平台无关。它相当于电子产品生产中的电原理图。逻辑视图包含的模型图有：类图（class diagrams）对象图（object di

6、agrams）交互图（interaction diagrams）状态图（state-chart diagrams）活动图（state-chart diagrams）c)进程视图（process view）3 d)实现视图(implementation view)当系统的逻辑结构在逻辑视图里被定义之后，需要定义逻辑结构的物理实现。这包括：设计元素对应的源代码文件 各物理文件之间的 关系 存放路径，等等。实现视图就是定义这些内容的地方。它当于电子产品的印刷电路板的布线图。实现视图描述组成一个软件系统的各个物理部件，这些部件以各种方式组合起来，（如：不同的源代码经过编译，构成一个可执行系统；或者不同

7、的软件组件配置成为一个可执行系统；以及不同的网页文件，以特定的目录结构，组成一个网站，等等）构成了一个可实际运行的系统。实现视图包含的模型图有:部件图（Component diagram）交互图（Interaction Diagram）状态图（state-chart diagram）活动图（activity diagram）e)分布视图(deployment view)软件产品将运行在计算机硬件系统上如果软件产品是面向网络的应用系统，则有可能同时运行在多个计算机上。分布视图用来描述软件产品在计算机硬件系统和网络上的 安装 分发（delivery）分布（distribution）在分布视图中，系

8、统的静态特性用分布图（deployment diagram）描述，动态特性用 交互图（interaction diagram）状态图（state-chart diagram）活动图（activity diagram）描述。设计视图和进程视图又可被统一称为逻辑视图(logical view)。其中每个视图分别关注软件开发的某一侧面。视图由一种或多种模型图(diagram)构成。模型图描述了构成相应视图的基本模型元素（element）及它们之间的相互关系。2.2 UML 的构成 从软件的体系结构出发，UML 把软件模型分成了五个视图，每个视图由不同的模型图构成。模型图实际上就是 UML 的基本成员

9、之一。作为 UML 的完整的概念模型，UML 的构成为：UML=UML 成员+UML 建模规则（roles of the UML）1)UML 建模规则相当于建模语言的语法；2)UML 成员（building blocks of the UML）是 UML 的基本组成部分，它和 UML 建模规则一起组成了 UML。UML 成员可进一步划分为 UML 基本模型元素（things in UML）关系（relationship）模型图（diagram）：4 UML 成员=UML 基本模型元素+关系+模型图 类在模型图（类图）上被通常用一个矩形为一个矩形，其上包含类的名字、属性、操作。图 2.2 类图

10、结构模型元素一共有七种，它们是：类 接口（interface）协同 用例（use case）主动类（active class）组件（component）节点（node）在这些结构元素中，最常用的包括：用例、接口和组件。用例 接口 组件 图 2.2 一些常用的结构模型元素 行为模型元素 行为模型元素（behavioral things）是 UML 模型的动态组成部分，它是模型的动词，代表软件系统在空间和时间上的行为。行为模型元素包括两类:交互（interaction）状态机（state machine）行为模型元素=交互+状态机 交互是系统内一系列的对象之间互相交换消息的行为。消息代表软件系统内

11、两个对象中一个对象向另一个对象发出的执行某种操作的请求。交互描述了一系列的对象为完成某一项任务而联合采取的一系列的行动，其中包括这些行动在时间上的顺序，以及为执行这些动作序列，对象之间所发生的语义上的联系。所以，消息是描述交互的一个重要手段。消息的图形表示：图 2.3 消息 图 2.4 状态 成组模型元素 Windoworiginsizeopen()close()display()Check Pass WordISpellingShell.cppdisplayWaiting5 分治的原则:在为复杂的软件系统建模的时候，将大的问题分解为多个子问题分别描述和解决。UML 提供了支持分治原则的语言成

12、份，成组模型元素(grouping things).成组模型元素只有一类，即模型包（package）。模型包用来组织多种语言成份，其中可包含：结构模型元素 行为模型元素 成组模型元素自身 模型包是纯概念性的，它只存在于软件系统的开发阶段。在 UML 模型图中，模型包被绘制成文件夹的形状（下图）。模型包是 UML 的基本成组元素，它还有一些变体，如：框架（framework）模型(model)图 2.5 包 图 2.6 标注 一个模型包的例子如子系统(subsystem)。注解元素 注解大量存在于机械图和电子线路图中被用来标示产品的工艺要求，等等。在 UML 中，也存在着相似的语言成分，这就是注

13、解元素（annotation things）注解元素只有一种，即标注（note）。标注用来描述施加于一个或多个模型元素的限制，或对模型元素的语义加以说明 标注的图形表示：一个折了角的长方形(图 2.6)在长方形中写标注的内容。标注的内容可以是形式的文本,或非形式的文本，也可以是图形。关系 结构模型元素是 UML 模型的静态组成部分，静态组成部分不是孤立存在的，它们被组合在一起互相协作以完成某项任务。因此，结构模型元素之间存在着某种语义上的联系，在UML 中，这种联系是关系（relationship）。UML 中共有 4 种关系，它们是：依赖关系(dependency)关联关系（associat

14、ion）聚合关系 泛化关系(generalization)实现关系(realization)（1）关联关系代表两个结构元素之间的某种语义上的连接 它是所有的关系中语义最弱的一种。关联关系是双向的 意味着被关联关系连接的两个模型元素的地位是相同的。如果两个结构模型元素之间存在着关联关系，则它们之间可以互相访问。关联关系可以 业 务函数在此返回6 a)描述数据库记录之间的对应关系（下图 2-7）b)描述结构模型元素之间的部分和整体关系，又被称为聚合关系。关联关系(2)依赖关系 它代表一个结构模型元素的语义依赖于另一个结构模型元素的语义。当被依赖的结构模型元素的语义部分地发生变化时，依赖元素的语义也

15、会发生变化。可以用依赖关系描述的情形包括：类之间的函数调用 变量引用 图形表示（下图 2-8）虚线箭头 依赖关系 (3)泛化关系（图（2-9a），描述基类和导出类之间的继承关系(4)实现关系（图（2-9b），描述类之间的接口定义和实现的关系。模型图 UML 是图示化的建模语言，UML 基本模型元素及其关系必须通过某种载体表示，这种载体就是模型图（diagram）。在 UML 中，模型图是一组 UML 基本模型元素的图形表示，它通常由 一组节点（UML 基本模型元素）及节点之间的连线（关系）组成。软件系统体系结构的 5 个视图的内容,就是用模型图视化的。一般地说，一个 UML 基本模型元素既可以

16、出现在所有的模型图中，又可以出现在某些模型图中，甚至可以不在任何一个模型图上出现。但是，对不同的视图，其中的模型图通常只包含特定的 UML 基本模型元素及其关系的组合。由此便产生了 9 种 UML 模型图。它们是：类图 对象图 用例图 序列图 协同图 状态图 活动图 组件 分布图+e m plo ye r+e m plo ye e*0.1(b)实现关系(a)泛化关系7 (1)类图 类图包含 类 接口 协同及其关系 类图用来描述逻辑视图的静态属性。（2）对象图 对象图包含对象及其关系，它用来表示类图的类的对象在系统运行过程中某一时刻的状态。对象也是软件系统的逻辑视图的一个组成部分。（3）组件图

17、组件图描述系统的物理实现，包括构成软件系统的各部件（运行文件）的组织和关系。类图里的类在实现时，最终会映射到组件图的某个组件，一个组件可以实现多个类。组件图是软件系统实现视图的组成部分。（4）分布图 分布图描述系统的组件在运行时在运行节点上的分布。一个节点可包含一个或多个组件。分布图是软件系统分布视图的组成部分。上述四种模型图主要用来描述软件系统的静态结构。描述软件系统的动态特性的,使用：用例图 序列图 协同图 状态图 活动图 (5)用例图 描述系统的边界，和其上的动态行为。图中包括：用例（use case）、系统作用者（actor）及其之间的(关联)关系。用例图是用例视图的重要组成部分。(6

18、)序列图和协同图 序列图和协同图用来描述一组对象之间的动态交互,以用来描述系统的动态特性，如外部的动态特性和内部的动态特性。序列图和协同图包含：对象 消息 序列图和协同图是用例视图和逻辑视图的重要组成部分。序列图和协同图是交互图的两种不同的表现形式。（7）状态图和活动图 状态图和活动图用于描述对象的动态特性。状态图强调对象对外部事件的响应及相应的状态变迁；活动图描述对象之间控制流的转换和同步机制。UML 建模规则：UML 的模型图不是 UML 语言成份（UML 成员）的简单堆砌，它必须按特定的规则有机地组合而成，从而构成一个完备的 UML 模型图。完备的 UML 模型图（well-formed

19、 UML diagram）必须在语义上是一致的并且和一切和它相关的模型和谐地组合在一起。UML 建模规则包括：名字：任何一个 UML 成员都必须包含一个名字。作用域：UML 成员所定义的内容起作用的上下文环境。可见性：UML 成员能被其它成员引用的方式。8 完整性：UML 成员之间互相联接的合法性和一致性。运行属性（execution）：UML 成员在运行时的特性。完备的 UML 模型必须对以上的内容给出完整的解释。当用于软件系统的建造时，UML模型是必须是完备的。但是当模型在不同的视图中出现时，出于不同的交流侧重点其表达可以是不完备的。在系统的开发过程中，模型可以：被省略，即模型本身是完备的

20、，但在图上某些属性被隐藏起来，以减化表达。不完全，在设计过程中某些元素可以暂时不存在。不一致，在设计过程中暂不保证设计的完整性。其目的在于鼓励开发者在设计模型时把注意力放在某一特定时期内对分析设计活动最重要的问题上，而暂不迷恋于细节的完美，使模型逐步趋向完备。UML 共用机制 在模型图上对 UML 成员进行描绘时，存在着共同的描绘方式，它们称为 UML 共用机制（UML common mechanism）.使用这些共用机制，使得建模的过程易于掌握,模型易于被理解。共用机制可被分解为四个方面的内容：规格说明 修饰 公共划分 扩充机制（1）规格说明（specification）软件模型必须是完备的

21、以便于软件系统的建造意味着此模型必须具备足够的详细信息以供软件建造之用。这些构成一个完备模型的详细信息就是模型的规格说明（specification）。所有 UML 模型元素都包含规格说明.在模型图上被省略的内容并不代表它也不存在于模型之中，模型的完整的或完备的信息是被保存在模型的规格说明中的，而通常一个完备的模型全部内容是通过多个模型图表达出来的。(2)修饰 UML 模型图中的图符通常都有一个基本的结构,它暴露了模型最主要的特征。出于表达或建造的需要，需要在基本图符的上表达更详细的信息时，UML 提供了有选择地暴露相关细节的方式-修饰（adornment）。（如图 2-10）图 2-10 修

22、饰 (3)公共划分(common divisions)在面向对象的设计中，有许多事物可以划分为抽象的描绘（class）和具体的实例。UML提供了事物的这两种两分法（dichotomy）表达-公共划分(common divisions)。几乎每种UML 成员都有这种类/对象的两分法划分。通常对象和类使用同样的图符，在对象的名字下面加下划线以示区别，还有一种两分法是接口和实现的两分法划分：接口定义了一种协议，实现是此协议的实施。UML 里这样的接口/实现两分法划分包括：接口/类或部件，用例和协通过修饰使得操作的可见性被暴露Transaction+execute()+rollback()#prior

23、ity()-timestamp()Transactionexecute()rollback()priority()timestamp()简略形式9 同操作和方法。（4）扩充机制（extensibility mechanisms）当使用 UML 的基本成份难以有效地表达复杂事物时，就需要对 UML 进行某种形式的扩充。正如同人类的语言需要不断地扩充语汇，以描述各种新出现的事物一样。UML 提供了这种扩充方式，称为扩充机制（extensibility mechanisms）。扩充机制为 UML 提供了扩充其表达内容的范围的能力。第 3 章 用例模型视图 3.1 参与者 1.参与者 参与者是与系统、

24、子系统或类发生交互作用的外部用户、进程或其他系统的理想化概念。作为外部用户与系统发生交互作用，这是参与者的特征。在系统的实际运作中，一个实际用户可能对应系统的多个参与者。不同的用户也可以只对应于一个参与者，从而代表同一参与者的不同实例。每个参与者可以参与一个或多个用例。它通过交换信息与用例发生交互作用（因此也与用例所在的系统或类发生了交互作用），而参与者的内部实现与用例是不相关的,参与者可以被一组定义它的状态的属性充分描述。参与者可以通过泛化关系来定义,在这种泛化关系中，一个参与者的抽象描述可以被一个或多个具体的参与者所共享。参与者可以是人、另一个计算机系统或一些可运行的进程。在图中，参与者用

25、一个名字写在下面的小人表示。2.识别参与者 谁使用该系统 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责维护、管理并保持系统正常运行 系统需要应付那些硬件设备 系统需要和那些外部系统交互 谁对系统运行产生的结果感兴趣 时间、气温等内部外部条件 例子：识别航空售票系统的参与者。建立一个航空公司的机票预定系统，让客户通过电话或网络买票、改变订票、取消订票、预定旅馆、租车等等。Customer(from Actor)Customer Service Representative(from Actor)Credit System(from Actor)10 Flight

26、 Coordinator(from Actor)3.2 用例 对一组动作序列的描述，系统执行该动作序列来为 Actor 产生一个可观察的结果值。用例的动态执行过程可以用 UML 的交互作用来说明，可以用状态图、顺序图、合作图或非正式的文字描述来表示。用例功能的执行通过类之间的协作来实现。一个类可以参与多个协作，因此也参与了多个用例。在系统层，用例表示整个系统对外部用户可见的行为。一个用例就像外部用户可使用的系统操作。然而，它又与操作不同，用例可以在执行过程中持续接受参与者的输入信息。用例也可以被像子系统和独立类这样的小单元所应用。一个内部用例表示了系统的一部分对另一部分呈现出的行为。例如，某个

27、类的用例表示了一个连贯的功能，这个功能是该类提供给系统内其他有特殊作用的类的。一个类可以有多个用例。用例是对系统一部分功能的逻辑描述，它不是明显的用于系统实现的构件。非但如此，每个用例必须与实现系统的类相映射。用例的行为与类的状态转换和类所定义的操作相对应。只要一个类在系统的实现中充当多重角色，那么它将实现多个用例的一部分功能。设计过程的一部分工作即在不引入混乱的情况下，找出具有明显的多重角色的类，以实现这些角色所涉及的用例功能。用例功能靠类间的协作来实现。在 UML 中，用例表示为一个椭圆，用例的名字可以放在椭圆的里面，也可以放在椭圆的下面。3.3 用例模型 用例的发起者在用例图的左侧，接受

28、者在用例图的右侧。参与者的名字放在参与者图标的下方。关联线连接参与者和用例并且表示参与者与用例之间有通信关系。关联线是实线，和类之间的关联线类似。用例分析的一个好处是它能够展现出系统和外部世界之间的边界。参与者是典型的系统外部实体，而用例是典型的属于系统内部。系统的边界用一个矩形来代表，里面写上系统的名字。系统的用例装入矩形之内。用例的适用性 用例首先用于需要响应客观事件的系统。它们能用于提供了一个有很容易理解的目标的清楚的行为者的环境。当结果不可定义或不清晰时不能用用例。意思是如果目标成功或目标失败不能有一个明确的定义，那么用例不能用来捕获需求。然而说到这，现在大部分对象方法都使用用例。因为

29、用例被证明是捕获需求的非常有效的机制。识别用例 Actor 希望系统提供什么功能 11 系统是否存储和检索信息，如果是，这个行为有哪个 Actor 触发 当系统改变状态时，通知参与者吗 存在影响系统的外部时间吗 用例开发顺序 用例并没有从一开始就就明确的定义，它主要的开发顺序如下：1)指出行为者 2)指出行为者的目标 3)指出每一行为者：目标语句对的成功或失败的意思 4)指出每一用例的主要的成功的情节 5)在细化阶段，指出失败的条件及可恢复/不可恢复的情节 3.4 用例的控制流语义 虽然每个用例的实例是独立的，但是一个用例可以用其他的更简单的用例来描述。这有点像一个类可以通过继承它的超类并增加

30、附加描述来定义。一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分，这被称作包含关系。在这种情况下，新用例不是初始用例的一个特殊例子，而且不能被初始用例代替。包含关系可以用含有关键字的带箭头的虚线表示。包含关系箭头指向被包含的用例。一个用例也可以被定义为基用例（原来的用例）的增量扩展,这叫做扩展关系。同一个基用例的几个扩展用例可以在一起应用。基用例的扩展增加了原有的语义,此时是本用例而不是扩展用例被作为例子使用。扩展点（extension points）：扩展只能发生在基用例的序列中的某几个具体指定点上，这个点被称为扩展点。扩展关系可以用含有关键字的带箭头的虚

31、线表示。扩展关系箭头指向被扩展的用例。在基用例中，扩展点出现在”extension point”的下方。一个用例也可以被特别列举为一个或多个子用例，这被称做用例泛化。当父用例能够被使用时，任何子用例也可以被使用。参与者之间也像用例一样可能存在泛化关系。参与者泛化与用例泛化关系的表示法相同，都用一个三角箭头从子参与者指向父参与者。用例泛化与其他泛化关系的表示法相同，都用一个三角箭头从子用例指向父用例。表 3-2 用例之间的关系比较 特 性 包 含 扩 展 泛 化 基行为 基用例 基用例 父用例 附加行为 包含用例 扩展用例 子用例 引用方向 基用例引用包含用例 扩展用例引用基用例 子用例引用父用

32、例 基行为是否被附加行为修改 包含用例显式地修改基用例的行为，基用例可以有或者没有包含用例，但是基用例的实例执行包含用例 扩展用例隐式地修改基用例的行为，除非基用例没有扩展，否则扩展用例一旦存在，基用例的实例将会执行扩展用例 父用例的执行效果不受子用例的影响。要得到附加行为的效果，子用例而不是父用例必须实例化 附加行为可否实例化 包含用例无需是可实例化的，可以是框架 扩展用例无需是可实例化的，可以是框架 子用例无需是可执行的，可以是抽象的 附加行为可否包含用例可以访问基用例扩展用例可以访问并修子用例可以访问并修改12 访问基行为 的状态，基用例必须为包含用例提供相应的属性 改基用例的状态 基用

33、例的状态（通过常规继承机制）基行为可否看到增加的行为 基用例可以看到包含用例，可以依赖于它的结果，但是不能访问它的属性 基用例不能看到扩展用例，在没有扩展用例时必须是结构完整的 父用例不能看到子用例，在没有子用例时必须是结构完整的 重复 只重复一次 取决于条件 只控制自己的执行 项目管理系统用例模型 管 理 项 目 项 目 经 理 项 目 数 据 库 项 目 管 理 系 统 图 3-1 参与者与用例之间的关联关系示例 添 加 项 目 项 目 经 理 项 目 数 据 库 删 除 项 目 查 找 项 目 项 目 管 理 系 统 图 3-2 用例包含关系示例 项 目 经 理 项 目 数 据 库 管

34、理 任 务 管 理 资 源 更 新 项 目 项 目 管 理 系 统 扩 展 点 任 务 函 数 资 源 函 数 (任 务 函 数 )选 择 任 务 选 项 (资 源 函 数 )选 择 资 源 选 项 图 3-3 用例扩展关系示例 13 项 目 经 理 项 目 数 据 库 发 送 邮 件 生 成 W e b 站 点 公 布 项 目 进 度 表 全 职 经 理 兼 职 经 理 W e b 站 点 主 机 关 系 数 据 库 面 向 对 象 数 据 库 邮 件 系 统 项 目 管 理 系 统 图 3-4 用例泛化关系示例 第 4 章 静态模型 本章内容 1.面向对象编程中的类,学会提取类的属性、方法

35、、类成员的存取控制方式、类之间的关系 2.对象图 3.包技术的使用 4.1 类图 4.1.1 类 类（class）是对一组具有相同属性、操作、关系和语义的对象的描述。类是对事物的抽象，它不是个体对象，而描述一些对象完整集合。例如，你可以把 CPU 看作是对象类，它具有 CPU 的共同属性，如：主频、指令集、Cache容量、运算位数、功率等。也可以考虑 CPU 的某个具体实例，如“Intel 的 P4 处理器”。在 UML 中为类提供了图形表示。这种可视化的抽象表示，使得我们对类的描述脱离了具体编程语言，而只需要强调抽象的主要部分。14 名称属性操作 类主要是由：名称、属性和操作。名称 类必须各

36、自有不同的类名称。类名称是一个字符串。单独的名称为简单名;还有一种用类所在包的名称作为前缀的类名称作路径名。例如书类属于数据表包中的类则其类的路径名为“数据表：书”。类名可以是由数字、字母和下划线等符号组成，类名的长度没有限制。例如顾客类可以用 Customer 作为类名。属性 属性（attribute）是已被命名的类的特性，它描述了该特性的实例可以取值的范围。属性描述了正被建模的事件的一些特性，这些特性是类的所有对象所共有。例如，所有的 CPU 都有主频率、指令集类型、运算的位算和外观尺寸。属性描述的一般语法格式为：可见性 属性名：类型名 初值 特性串 在 UML 中定义了 3 种可以用于属

37、性的特性：(1)可变（changeable）：对修改属性的值没有约束。(2)只增（addOnly）：对于多重性大于 1 的属性，可以增加附加值，但一旦被创建，就不可对值进行消除或改变。(3)冻结（frozen）：在初始化对象后，就不允许改变属性值。操作 操作（Operation）是服务的实现，该服务可以由类的任何对象请求以影响其行为。在 UML 中把操作序列放在类属性下面的栏中，如图所示：操作BookgetName():StringSetName(bookName:String)getAuthor():String 操作的标准语法格式为：可见性 操作名（参数表）：返回值特性串 可用于操作的特性

38、：查询（isQuery）顺序（sequential）监护（guarded）并发（concurrent）4.1.2 类成员的可见性 15 1公有（Public）用“”表示。2受保护（protected）用“#”表示。3私有（private）用“”表示。公有受保护私有 4.1.3 类的类型 1实体类（entity）实体类是对系统中需要存储的信息和其信息的行为建立模型。实体类具有永久的特性。这类似于数据库中的表一样用于保存系统的业务信息。Reader 在 UML 中，实体类的构造类型（stereotype）被设定为 Entity。2边界类（boundary）边界类（boundary）位于系统与外界的

39、交接处，它在一个或多个角色和系统之间建立相互作用的模型。newReaderFramemodifyReaderFramedeleteReaderFramenewReaderFramemodifyReaderFramedeleteReaderFrame 边界类可以是窗口、打印机接口、传感器和终端。要寻找和定义边界类，可以检查用例图。每个参与者（Actor）和用例交互至少要有一个边界类。在 UML 中，实体类的构造类型（stereotype）被设定为 Boundary。3控制类（control）控制类是负责协调其他类的工作，它建立了一个或几个用例的行为模型。16 例如登录用例就须要有用户验证类就是控

40、制类，他通过协调登录边界类与用户信息实体类来完成登录的工作。它整理系统的行为并描述一个系统的动态特性，处理主要的任务和控制流。每个用例通常都有一个控制类、控制用例中的事件顺序。也存在多个用例共享同一个控制类。在 UML 中，控制类的构造类型（stereotype）被设定为 control。4.1.4 类的识别 类的识别策略：(1)从事件流中寻找名词或名词词组（或交互图中的对象），将性质相同的归为一类，或性质内容值正负相反的归为一类。(2)去除不恰当的与含糊的类别，去除应是归类为属性的项目。(3)给这些类取个合适的名字，在现实系统实现时，可以参照真实系统相关的命名规约。4.1.5 类的关系 关系

41、（Relationship）是指事物之间的联系。在面向对象的建模中，有 3 种最重要的关系是 依赖 泛化 关联 在图形上，把关系画成一条线，并用不同的线区别关系的种类。1.依赖（dependency）依赖（dependency）是一种使用关系，它说明了一个事物声明说明的变化可能影响到使用它的另一个事物，但反之未必。例如在 windows 系统中的窗体事件（类 Event）的变化将会影响到使用它的窗体（类Window）。依赖 在图形上，把依赖画成一条有向的虚线，指向被依赖的事物。当要指明一个事物使用另一个事物时，就使用依赖。2.泛化（generalization）泛化（generalizatio

42、n）是一般事物（称为父类或超类）和较特殊事物（称为子类或孩子17 类）之间的关系。例如，你可能遇到一般类 Client（用户类）和它的较特殊类 Librarian(管理员类)。父类泛化子类 泛化的用途 一种用途是用来定义下列情况：当一个变量（如参数或过程变量）被声明承载某个给定类的值时，可使用类的实例，这被称作可替换性原则。该原则表明后代的一个实例可以用于任何祖先被声明的地方。例如，如果一个变量被声明为图书管理员，那么他就可代替用户实例。另一个用途是在共享父类所定义的成员的前提下允许它增加自身定义的描述，这被称作继承。继承允许描述的共享部分只被声明一次而可以被许多子类所共享，而不是在每个类中重

43、复声明并使用它，这种共享机制减小了模型的规模。更重要的是，它减少了为了模型的更新而必须做的改变和意外的前后定义不一致。3.实现（realization）实现（realization）是类元（类）之间的语义关系，关系中的一个类元（类）描述了另一个类元（接口）实现的契约。也就是说，实现关系中的一个类只具有行为的定义，而具体的结构和行为，则是由另一个类来给出。实现关系说明实现方法 4.关联（association）关联是一种结构关系，它详述了一个事物的对象与另一个事物的对象相互联系。例如，类 Library（图书馆类）与类 Book（书类）就是一种一对多的关联，这表明每一18 个 Book 实例仅被

44、一个 Library 实例所拥有。此外，给定一个 Book，能够找到它所属的 Library，给定 Library，能够找到它的全部 Book。在 UML 中，把关联画为连接相同或不同的类的一条实线。当要表示结构关系时，就使用关联。在 UML 中，有 4 种可应用到关联的基本修饰：关联名 关联端的角色 关联端的多重性 聚合 (1)关联名即名称 关联可以通过命名的方式来描述关系的性质。此关联名称应该取为动词短语，因为它表明源对象正在目标对象上执行的动作。为了消除名称含义的歧义，UML 中提供了一个指引读者名称方向的三角形，并给名称一个方向。在图书馆管理系统中的书与书目记录之间是存在着一种关联关系

45、。这种关联关系可以称为“拥有”而名称的方向是指向书目类。如图所示。关联(2)角色 当一个类处于关联的某一端时，该类就在这个关系中扮演了一个特定的角色。它呈现的是对另一端的职责。可以显式地命名类在关联中所扮演的角色。(3)多重性 关联表示了对象间的结构关系。有时在建模时需要说明一个关联的实例中有多少个相互连接的对象。(4)聚合 在实际建模中，往往需要对“整体/部分”的关系进行描述。在这种关系中，其中一个类所描述的是一个较大的事物（即“整体”），它由较小的事物（“部分”）组成。这种关系在面向对象中就称为聚合，它描述了“has-a”的关系，意思是整体对象拥有部分对象。在 UML 中被表示为在整体的一

46、端用一个空心菱形修饰的简单关联。例如，在对学校的组织结构进行建模时，学校和系部之间就存在着这种“整体/部分”的关系，因为一所学校里肯定会设置多个系部。如关联如图所示。19 学校系部整体聚合1*部分 (5)组合：组合是聚合的一种形式，它具有强的拥有关系，而且整体与部分的生命周期是一致的。带有非确定多重性的部分可以在组合物自身之后创建，但创建后，就同生共死，即整体释放部分也跟着被释放。例如，视窗系统中，一个 Frame 只属于一个 Window。如所示。WindowFrame1*整体部分组合 在 UML 中，组合是一种特殊的关联，用整体端有实心菱形箭头的简单关联修饰它。4.2 对象图(Object

47、 Diagram)对象图（Object Diagram）是描述在某一时刻，一组对象以及它们之间关系的图形。现金=20张三:客户对象1张三:客户(a)(b)(c)对象图可以看作是类图在系统某一时刻的实例。对象图表示的是被冻结的系统在运行时的某一瞬间的情况，类似于使用 DVD 播放机播放 DVD 光碟时，按下暂停（pause）键时，出现的静止画面。对象图中一般包括“对象”和“链”两类基本的模型元素。1对象(Object)一般来说，把类的具体表示称为对象，对象是类的实例。2链（link）链是两个或多个对象之间的独立连接，是关联的实例。通过链可以将多个对象连接起来，形成一个有序列表，称为元组。名称 =

48、远景软件C:公司名称 =开发部D1:部门名称 =人事部D3:部门名称 =财务部D2:部门对象属性值链 20 3对象图的建模技术 要对对象结构建模，应遵循以下步骤:1)确定参与交互的各对象的类，可以参照相应的类图和交互图 2)确定类间的关系，如依赖、泛化、关联和实现 3)确定在某特定时刻各对象的状态值，使用对象图为这些对象建模 4)根据建模目标，绘制对象的关键状态和关键对象之间的连接关系 4.3 包(package)包是用于把元素组织成组的通用机制。包有助于组织模型中的元素，使你更容易理解系统模型，也可以控制对包的内容的访问。UML 提供了对包的图形表示法。1包的名字包 U s e r#B o

49、r r o w e r+R e a d e r-L i b r a r i a n 和其他建模元素一样，每个包都必须有一个区别于其他包的名字。2包拥有的元素 包是对模型元素进行分组的机制，它把模型元素划分成若干个子集。包可以拥有 UML中其他元素，包括类、接口、组件、节点、协作、用例、甚至还可以包含其他子包。对包内所包含的建模元素可以使用文本或图形的方式，加以显示。3包的可见性 包内的元素加以控制，使得某些元素能被外界访问，可见某些元素不能被外界访问。这就是所谓的包内元素可见性控制。可见性可以分成 3 种：公有访问（public）保护访问（protected）私有访问（private）4引入（

50、import）与导出（export）引入（import）使得一个包中的元素可以单向访问另一个包中的元素。导出（export）指的是包中具有公有访问权限的内含元素，一个包中“导出”部分仅仅只对显示地引入这个包的其他包中的内含元素可见。User#Borrower+Reader-LibrarianProcess+Loan引入导出 5泛化关系 在包之间可以有两种关系：一种关系是引入和访问依赖；另一种关系就是泛化。包间的泛化关系与类之间的泛化关系类似。21 GUIWindowsGUIButtonsGUI 6标准元素 UML 的扩充机制同样适用于包元素，可以使用标记值来增加包的新特性，用构造型来描述包的新