Organizing Attributes and Operations
组织属性和操作
When drawing a class, you don’t
have to show every attribute and every operation at once. In fact, in most cases, you can’t
(there are too many of them to put in one figure) and you probably should not (only a subset of these attributes and operations are likely to be relevant to a specific view). For these reasons, you can elide a class, meaning that you can choose to show only
some or none of a class’s attributes and operations. You can indicate that there are more
attributes or properties than shown by ending each list with an ellipsis (“...”).
You can also suppress the compartment entirely, in which case you can’t tell if there
are any attributes or operations or how many there are.
在你画类的时候，不需要同时显示每个属性和每个操作．事实上，大多数情况下，你不能(有太多要放到一个图里) 也不想(只有一部分属性和操作似乎与指定的视图相关)这么做．由于这个原因，你可以省略一个类，这意味着你可以选择不显示或只显示类的部分属性或操作．你可以在列表末尾用一个省略号指示出更多的属性或操作．在说不清是否有属性或操作，也不知道它们有多少个的这种情况下．你也可以完全限制分隔栏．
To better organize long lists of attributes and operations, you can also prefix each group with a descriptive category by using stereotypes, as shown in Figure 4-7.
比组织一长串的属性和操作列表更好的方法是，你可以通过使用模式化为每一个描述性的类别组加前缀，如图４－７显示的那样．
Responsibilities
职责
A
responsibility
is a contract or an obligation of a class. When you create a class, you are making a statement that all objects of that class have the same kind of state
and the same kind of behavior. At a more abstract level, these corresponding attributes and operations are just the features by which the class’s
responsibilities are carried out. A Wall class is
responsible for knowing about height, width, and thickness; a FraudAgent
class, as you might find in a credit card application, is responsible for processing orders and determining if they are legitimate, suspect, or fraudulent;
a TemperatureSensor class is responsible for measuring
temperature and raising an alarm if the temperature reaches a certain point.
职责是一个类的契约或是义务．当你创建一个类时，你正在声明类的所有对象所拥有的一种状态和一种行为．在更抽象的层面里，类的职责被执行后显示出来的特征就是所对应的属性和操作．一个墙类的职责目的是了解墙的高度，宽度和厚度；一个欺诈代理类，你可以在申请信用卡时发现，这个类的职责是处理订单和确定这些申请是否真实，是否可疑或是否欺骗；一个温度传感器类的职责是测量温度和当温度达到界定值时发出警报．
When you model classes, a good starting point is to specify the responsibilities of the things in your vocabulary. Techniques like CRC cards and use
case-based analysis are especially helpful here. A class may have any number of responsibilities, although, in practice, every well-structured class has at least one responsibility and at most just a handful. As you refine your models, you will translate these
responsibilities into a set of attributes and operations that best fulfill the class’s
responsibilities.
当你构建类模型时，一个好的起点是描述词汇表中所有事物的职责．象CRC卡和基本用例分析技术在这里特别有帮助．一个类可以有任意数量的职责，尽管事实上，每个拥有良好结构的类至少有一个职责和大多数时候其职责并不多．作为你定义的模型，你将会把这些职责转化成一组属性和操作以最好地实现类的职责．
Graphically, responsibilities can be drawn in a separate compartment at the bottom of the class icon, as shown in Figure 4-8.
图形表示上，职责被画在类图最低部的分隔栏内，如图4-8显示的．
Note:
Responsibilities are just free-form text. In practice, a single responsibility is written as a phrase, a sentence, or (at most) a short paragraph.
备注：职责是自由形式的文本．在实际中，单个的职责由一个短语，一个句子或是(大多数情况)一段文字表示．
Other Characteristics
其它特征
Attributes, operations, and responsibilities are the most common features you’ll
need when you create abstractions. In fact, for most models you build, the basic form of these three features will be all you need to convey the most important semantics of your classes. Sometimes, however, you’ll
need to visualize or specify other characteristics, such as the visibility of individual attributes and operations; language-specific features of an operation, such as whether it is polymorphic or constant; or even the exceptions that objects of the class
might produce or handle. These and many other features can be expressed in the UML, but they are treated as advanced concepts.
在你创建抽象事物时，属性，操作和职责是最常见的特性．事实上，这三个特性的基本形式将为你所构建的大多数模型传达类的最重要的语义．然而有时，你需要可视化或是描述其它的特征，如个别属性或操作的个见性；某个操作的特定语言特性，如它是否具有多态性，或它是不是个常数；甚至是类的对象可能产生或处理的异常．这些或是更多的其它特性，在UML中都可以被表述，但它们被视为更深层的概念．
When you build models, you will soon discover that almost every abstraction you create is some kind of class. Sometimes you will want to separate the implementation of
a class from its specification, and this can be expressed in the UML by using interfaces.
在你建构模型时，不久将会发现几乎每个你所创建的抽象都是某种类．有时你会想将某个类的实现和它的描述分开，这种类在UML中表述为接口．
When you start designing the implementation of a class, you need to model its internal structure as a set of connected parts. You can expand a top-level class through
several layers of internal structure to get the eventual design.
在你开始设计某个类的实现时，你需要构建它的内部结构作为一组连接部分．你可以展开顶级类，通过内部结构的多层连接获取最终设计．
When you start building more complex models, you will also find yourself encountering the same kinds of entities over and over again, such as classes that represent concurrent
processes and threads, or classifiers that represent physical things, such as applets, Java Beans, files, Web pages, and hardware. Because these kinds of entities are so common and because they represent important architectural abstractions, the UML provides
active classes (representing processes and threads) and classifiers, such as artifacts (representing physical software components) and nodes (representing hardware devices).
在你开始构建更复杂的模型时，你也会发现自己不断的遇到同一种实体，如代表并发进程和线程的类，或是表达物理事物的分类器，如小应用程序，Java组件，文件，网页和硬件．因为这一类的实体太普通，同时因为它们表达了重要的体系架构抽象，UML提供活动类(体现进程和线程)和分类器，如工件和(体现物理的软件组件)节点(体现硬件设备)
Finally, classes rarely stand alone. Rather, when you build models, you will typically focus on groups of classes that interact with one another. In the UML these societies
of classes form collaborations and are usually visualized in class diagrams.
最后，类很少独立存在．相反，在你建构模型时，你通常会集中在一群相互作用的类上．在UML中，这些类群形成交互，通常显示在类图中．
UML基本架构建模－－类的辅助信息,布布扣,bubuko.com