UML对基本结构建模---类

1.术语和概念

      类是对一组具有相同属性、操作、关系和语义的对象的描述。在图形上,把类画成一个矩形。
(1)名称
      每个类都必须有一个有别与其他类的名称。名称是一个文字串。单独的名称叫做简单名,用类所在的包的名称作为前缀的类名叫做限定名。绘制的类可以仅显示它的名称,如下图所示。 (一个包中的各类的名称都必须是唯一的)
在这里插入图片描述
(2)属性
      属性是已命名的类的特性,它描述了该特性的实例可以取值的范围。类可以有任意数目的属性,也可以没有属性。
在这里插入图片描述
(3)操作
      操作是一个服务的实现,该服务可以由任何类的对象来请求以影响其行为。换句话说,操作是能对一个对象所做的事情的抽象,并且它由这个类的所有对象共享。类可以有任意数目的操作,也可以没有操作。 在这里插入图片描述
(4)对属性和操作的组织
      当画一个类时,不必同时把所有的属性和操作都显示出来。这意味着可以有选择地仅显示类的一部分属性和操作,甚至可以一个也不显示。空栏并不一定意味着没有属性或操作,只是没有选择要显示它们。通过在列表的末尾使用省略号(“…”),可以明确地表示出实际的属性和操作比所显示的要多。
(5)职责
      职责是类的合约或责任,可以把单个职责写成一个短语、一个句子或(最多)一段短文。当创建一个类时,就声明了这个类的所有对象具有相同种类的状态和相同种类的行为。比如,类Wall负责了解墙的高度、宽度和厚度。对类建模的一个好的起点是详述词汇表中的事物的职责。当精化模型时,要吧这些职责转换成能很好地完成这些职责的一组属性和操作。在图形上,可以在注解中描绘出类的职责。
在这里插入图片描述

2.常用建模技术

(1)对系统的词汇建模
      类的最常见的用途是对从试图解决的问题或者从解决该问题的技术得到抽象进行建模。每个这样的抽象都是系统词汇表的一部分,这意味着它们在整体上描述了对用户和实现者重要的事物。为了对系统的词汇建模,需要做如下工作。

  • 识别用户或实现者用于描述问题或者描述解决方案的那些事物。
  • 对于每个抽象,识别一个职责集。确保能清楚地定义每个类,而且这些职责能在所有的类之间很好的均衡。
  • 提供为实现每个类的职责所需的属性和操作。

(2)对系统的职责分布建模
      一旦开始对大量的类建模,就要保证抽象提供了均衡的职责集。这意味着不能让任何类过大或过小,每一个类应该做好一件事。对系统中的职责分布建模,要做如下工作。

  • 识别一组为了完成某些行为而紧密地协同工作的类。
  • 对上述的每一个类识别出一组职责。
  • 从整体上观察这组类,把职责过多的类分解成较小的抽象,把职责过于琐碎的小类合成较大的类。
  • 考虑这些类的相互协作方式,相应的重新分配它们的职责,是协作中没有哪个类的职责过多或过少。

3.提示和技巧

      在用UML堆类建模时要记住:对最终用户说实现这来说,各个类都应该映射到某个有形的或者概念性的抽象。一个结构良好的类,应满足如下条件。

  • 为取自问题域或者解域的词汇中的事物提供明确的抽象。
  • 嵌入一个小的、明确定义的职责集,并且能很好地实现它们。
  • 把抽象的规约和它的实现清楚的分开。
  • 简单而且可理解,并句有可适应性和可拓展性。
  • 仅显示在该类的语境中对理解抽象较为重要的类的特性。
  • 按属性和操作的种类进行分组,以更好地组织其长列表。
  • 把相关的类显示在同一个类图中。
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

赶路的苟狗

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值