-
面向对象问题处理的关键是建模问题。
建模可以把在复杂世界的许多重要
的细节给抽象出来。
许
多建模工具封装了
UML
(也就是
Unified Modeling Lan
guage
),
UML
中有九种建模的
图标,即:用
例图、类图、对象图、顺序图、协作图、状态图、活动图、组件图、配置图
。本文重点讲述类图。
为什么
UML
很重要?
为了回答这个问题,
我们看看建筑行业。
设计师设计出房子。
施工
人员使用这个设计来建造房子。
建筑越复杂,
设计师和施工人员
之间的交流就越重要。
蓝图就成为了这个行业中的设计师和施工人员
的必修课。
写软件就好像建造建筑物一样。
系统越复杂,
参与编写与配置软件的人员之间的交流也就越重要。
在过去十年里
UML
就成为分析师,设计师和程序
员之间的“建筑蓝图”。现在它已经成为了软件行业
的一部分了。
UML
提供了分析师,设计师和程序员之间在软件设计时的通用语言。
UML
被应用到面向对象的问题的解决上。想要学习
UML
必须熟悉面向对象解决问题的根本原
则――都是从模型的建造开始的。一个模型
model
就是
根本问题的抽象。域
domain
就是问题所处的
真实世界。
模型是由对象
objects
组成的,它们之间通过相互发送消息
messa
ges
来相互作用的。记住把一
个对象想象成“活着的”。对象
有他们知道的事(属性
attributes
)和他们可以做的
事(行为或操
作
behaviors or operatio
ns
)。对象的属性的值决定了它的状态
state
。
类
Classes<
/p>
是对象的“蓝图”。一个类在一个单独的实体中封装了属性(数据)和行为(方法或
函数)。对象是类的实例
instances
。
UML
中的
4
种关系
UML
中类与类
,
类与接口
,
接口与接口之间的关系有
:
泛化
(generalization)
关系
,
关联
(association)
关系
(
关联
,
聚合
,
合成
),
依赖
(dependency)
关系,实现
(realizati
on)
关系
.
泛化
(generalization)
关系是一种<
/p>
特殊
/
一般
关系
,特殊元素(子元素)的对象可替代一般
元素(父元素)的对象。用这种方法,子元素共
享了父元素的结构和行为。泛化关系其实是
一个类(称为子类、子接口)
继承
另外的一个类(称为父类、父接口)的功能,并可以增加
< br>它自己的新功能的能力,继承是类与类或者接口与接口之间最常见的关系;在
Ja
va
中此类
关系通过关键字
exten
ds
明确标识,在设计时一般没有争议性。
实现
(realization)<
/p>
关系是类元之间的语义关系,
其中一个类元指定了由另一个类元保
证执
行的契约。它其实是一个
class
类
实现
interface
接口(可
以是多个)的功能;实现是类与接
口之间最常见的关系;在
Ja
va
中此类关系通过关键字
implements
明确标识,在设计时一般
没有争议性;
依赖
(dependency)
p>
关系
:
表示两个事物间的语义关系,
p>
其中一个事物(独立事物)发生
变化会影响另一个事物(依赖事物)
的语义
。它也是类与类之间的连接
.
表示一个类依赖于
另一个类的定义
.
依赖关系总是单向的
。
可以简单的理解,就是一个类
A
使用到了另一个类<
/p>
B
,而这
种使用关系是具有偶然性的、临
时性的、非常弱的
,但是
B
类的变化会
影响到
A
;
比如某人要过河,需要借用
一条船,
此时人与船之间的关系就是依赖
;
表现在代码层面,为
类
B
作为参数
被类
A
在某个
method
方法中使用。
在
java
中
.
依赖关系体现为
:
局部变量方法
p>
中的
参数
和对静态方法的调用
.
关联
(association)
关系
:
表示类与类之间的联接
,
它使一个类知道另一个类的属性和方
法
.
关联可以使用单箭头表示单向关联
,
使用双箭头或不使用箭头表示双向关联
,
不建议使用
双向关联
.
关联有两个端点
,
在每个端点可以有一个基数
,
表示这个关联的类可以有几个实
例
.
常见的基数及含义
:
0..1:
0
或
1
个实例
.
0..*:
对实例的数目没有限制
.
1:
只能有一个实例
.
1..*:
至少有一个实例
.
他体现的是两个
类、
或者类与接口之间语义级别的一种强依赖关系,
比如我和我
的朋友;
这
种关系比依赖更强、
不存在
依赖关系的偶然性、关系也不是临时性的,
一般是长期性的
,而
且双方的关系一般是平等的
,
表现在代
码层面,
为被关联类
B
以类属性的形式
出现在关联类
A
中
,也可能是关联类<
/p>
A
引用了一个类型为被关联类
B
的全局变量;
在
java
语言中关联关系
是使用实例变量实现的
.
< br>
关联关系描述的是类与类之间的连接,他表示一个类知道另一个类的属性和
方
法。关联关系可以是单向的或者双向的。
在
< br>Java
语言中,
单向的关联关系是通过以实例变量的方
式持有被关联对象的引
用来实现的。
一般来说是不建议使用双向的关联关系的。下面举例介绍单向的关联关系。
上面的类图表现的是骑手和
马之间的关系。
Rider
中有一个实例变量类型是
Horse
。
每个连接都会有两个端点,
上面的
Ri
der
和
Horse
就是端点,
且每个端点都
可以有
(optional)<
/p>
一个基数
(multiplicity)
,表示这个类可以有几个实例。
左
侧的
Rider
端点的
1
表示只有一个
Rider
,
右侧
Horse
端点的
1..n
表示至少
有
1
个
p>
Horse
,也就是说
Rider
方是
1
,而
Horse
方是
n
,体现的是
Rider
和
Horse
之间的<
/p>
1
对多关系。
聚集
/
聚合
(aggregation)
关系
:
关联关系的一种特例
,
是强的关联关系
.
聚合是整体和个体
之
间的关系
,
即
has-a
的关系
,
此时整体与部分
之间是可分离的,
他们可以具有各自的生命周期,
部分可以属于
多个整体对象,
也可以为多个整体对象共享;
比如计算机与
p>
CPU
、
公司与员工
的关系等;
表现在代码层面,和关联关系是一致的,只能从语义级别来区分;聚合关系
也是
使用实例变量实现的
.
从
java
语法上是分不出关联和聚合的
.
关联关系中两个类是处于相同
的层次
,
而聚合关系中两个类是处于不平等的层次
,
一个表示整体
,
一个表示部分
.
p>
组合
(
合成
)
p>
关系
(composition):
也是
关联关系的一种特例,
他体现的是一种
contains-a<
/p>
的关
系
,这种关系比聚合更强,也称为强
聚合;
他同样体现整体与部分间的关系,但此时整体与
部分是不
可分的
,
整体的生命周期结束也就意味着部分的生命周期结束;
比如你和你的大脑;
合成关系不能共享。表现在代码层面,和关
联关系是一致的,只能从语义级别来区分。
组合跟聚合几乎相
同,唯一的区别就是
“
部分
”
不能脱离
“
整体
”
p>
单独存在,就是说,
“
< br>部分
”
的生命期不能比
“
整体
”
还要长。
总结:
对于继承、
实现这两种关系没多少疑问,
他们体现的是一种类与类、
或者类与接口间的纵向
关系;
p>
其他的四者关系则体现的是类与类、或者类与接口间的引用、横向关系,是比较难区
分的,
有很多事物间的关系要想准确定位是很难的,
前面也提到,
这几种关系都是语义级别
的,
所以从代码层面并不能完全区分各种关系;
但总的来说,
后几种关系所表现的强弱程度
依次为:组合
>
聚合
>
关联
>
依赖。
类图
类图
Class
diagram
p>
通过显示出系统的类以及这些类之间的关系来表示系统。
类图是静态
的-它
们显示出什么可以产生影响但不会告诉你什么时候产生影响。
下面是一个顾客从零售商处预定商品的模型的类图。
中心
的类是
Order
。
连接它的是购买货
物的
Customer
和
Paymen
t
。
Payment
有三种形式:
p>
Cash
,
Check
,
或者
Credit
。
订单包括
OrderDetails
(
line
item
),每个这种类都连着
Item
。
p>
UML
类的符号是一个被划分成三块的方框:类名,属性,和操作。
抽象类的名字,像
Payment
是
斜
体的。类之间的关系是连接线。
类图有三种关系。
关联
association
-表示两种类的实例间的关系。
如果一个类的实例必须要用另一个类的实例才
能完成工作时就要用关联。在图中,关
联用两个类之间的连线表示。
聚合
a
ggregation
-当一个类属于一个容器时的一种特殊关系。
聚合用一个带菱形的连线,
菱形
指向具有整体性质的类。在
我们的图里,
Order
是
Order
Details
的容器。
泛化
generalization
-一个指向以其他类作为超类的继承连
线。泛化关系用一个三角形指向超
类。
Payment
是
Cash
,
Chec
k
和
Credit
的超类。
一个关联有两个尾端。每个尾端可以有一个角色名
role n
ame
来说明关联的作用。比如,一个
OrderDetail
实例是一个
Order
实例的项目。<
/p>
关联上的方向性
navigabili
ty
箭头表示该关联传递或查询的方向
。
OrderDetail
类可以查询他
的
Item
,但不可以反过来查询。
箭头方向同样可以告诉你
哪个类拥有这个关联的实现;也就是,
OrderDetail
拥有
Item
。
没有方向性的箭头的关
联是双向。
关联尾端的数字表示该关联另一边的一个实例可以
对应的数字端的实例的个数,
通过这种方式表
达关联的多样性<
/p>
multiplicity
。多样性的数字可以是一个单独的数字
或者是一个数字的范围。在例
子中,每个
Order
只有一个
Customer
,但一个
Customer
可以有任意多个
Order
。
下面这个表给出了最普遍的多样性示例。
每个类图包括类,关联和多样性表示。方向性和角色是为了使
图示得更清楚时可选的项目。
CDE
基本概念
The
fundamental
information
component
in
the
ISO/IEC
11179
model
is
the
data
element
,which constitutes a
single
(单个)
unit
of data considered
indivisible
(不可分割的)
in
the context in which it
is used. Another way of saying this is that a data
element is the smallest
unit of
information that can be exchanged in a transaction
between cooperating systems.
A critical
notion
(概念)
in the
metadata model is that any concept represented by
a data
element
must
have
an
explicit
(明确的)
definition
that
is
independent
of
any
particular
representation.
In
order
to
achieve
this
in
the
model,
the
ISO/IEC
11179
standard
specifies
the
following four
components:
1. A
DataElementConcept
consists
of an
object
and a selected
property
of that object;
2. The
ConceptualDomain
is the set
of all intended meanings for the possible values
of an
associated DataElementConcepts;
3. The
V
alueDomain
is a set of
accepted representations for these meanings;and
4. A
DataElement
is a combination of a selected
DataElementConcept and a ValueDomain.
A
simple example should help to clarify these
definitions. Figure 3.1-1 shows a DataElement
that
might
be
used
to
represent
hair
color.
The
associated
DataElementConcept
use
the
ObjectClass
Hair
and the Property
Color
to define the intended
concept. The intended meanings
for this
data element are the familiar hair colors
blonde,brunette,etc.,but the ValueDomain uses a
numeric representation that is mapped
to these intended meanings. Both the
DataElementConcept
and
the
ValueDomain
are
components
of
the
DataElement
,
and
each
references
the
same
ConceptualDomain, which is defined
outside the DataElement. Important principles of
this design
are:
?
The
DataElementConcept is used to signify a concept
independent of representation.
?
The ValueDomain
specifies a set of representational values
independent of meaning.
?
The DataElement
combines a specific object and property with a
value representation.
?
The
ConceptualDomain
specifies
the
complete
set
of
value
meanings
for
the
concept
and allows the interpretation of the
representation.
Figure 3.1-2 uses a UML Class diagram
to show the cardinality constraints that hold for
these
relations. Each DataElement must
specify exactly one DataElementConcept and one
V
alueDomain
in order to
fully specify the data element. Similarly, each
DataElementConcept and ValueDomain
must
specify exactly one ConceptualDomain. Conversely,
a ConceptualDomain may be associated
with any number of ValueDomains and any
number of DataElementConcepts. Figure 3.1-3 shows
an
example
of
this,
using
the
color
property
of
different
geometric
objects
as
DataElementConcepts, and alternate
color representations for the ValueDomains.
-
-
-
-
-
-
-
-
-
上一篇:边界元与有限元
下一篇:常用物理英语词汇大全