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 freeform 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中，这些类群形成交互。通常显示在类图中．