6.5 Object Attributes


The UML defines an attribute to be "a named property of a type." In this sense, attributes are "smaller" than objects they have only a primitive structure and, of themselves, no operations other than get_ and set_. Practically speaking, attributes are the data portion of an object. A sensor object might include attributes such as a calibration constant and a measured value. Attributes are almost always primitive and cannot productively be broken down into smaller pieces. If you find attributes to be structurally nonprimitive or behaviorally rich, then they should usually be modeled as objects owned (via composition) by the main object, rather than as attributes of that main object. For example, if a sensor has a simple scalar calibration constant, then it would be appropriate to model it as an attribute of the sensor object. If, however, the sensor object has an entire set of calibration constants, the calibration constants should be each be modeled as an object aggregated unidirectionally by the sensor object with a 1-* multiplicity. The set of constants would probably be managed by a container class (added in design), as shown in Figure 6-12. It is important to remember that modeling the table in this way does not necessarily entail any additional overhead in terms of performance or memory usage but does provide superior encapsulation of concerns and easier maintenance.

Figure 6-12. Modeling Nonprimitive Attributes

graphics/06fig12.gif

Sometimes the primary attributes of an object are obvious, but not always. Developers can ask themselves some key questions to identify the most important attributes of objects:

  • What information defines the object?

  • On what information do the object's operations act?

  • What does the object know?

  • Are the identified attributes rich in either structure or behavior? (If so, they are probably objects in their own right rather than simple attributes.)

  • What are the responsibilities of the object? What information is necessary to fulfill these responsibilities?

The Elevator class provides a good example of a real-time class with attributes. Let's ask these questions about this class:

  • What information defines the object? The Elevator is a physical thing that must be controlled. To fulfill its function it must know where it is, where it is going (destination list), its current direction, its operational status, and its error history.

  • On what information do the object's operations act? It has a goto() operation, which must act on where it is, its current direction, and its state (moving, stopped, etc.).

  • What does the object know? It knows where it is, where it is going, and what it is doing right now.

  • Are the identified attributes rich in either structure or behavior? If so, they are probably objects rather than attributes. The Elevator has a door that has state (open, closed, opening, closing), interlocks with the floor door, and operations. The door is probably a separate object.

  • What are the responsibilities of the object? What information is necessary to fulfill these responsibilities? The Elevator's primary responsibility is to transport passengers from one floor to another safely. It needs the attributes of where it is, in which direction it is traveling, a list of current destinations, and its current state.

There are cases in which an object with no attributes is valid within the domain. A button is a reasonable class, but what attributes does it have? Probably none. Some composite objects are only aggregates of many objects with no data specific in and of themselves. Other objects contain only functions and so are often called functoids or (in UML-speak) class utilities.

In object domain analysis, we are not particularly concerned with the visibility of the attributes (or of the operations). Later, in design, we will mark them as public (+'), private (-) or protected (#). If you'd like to mark your best guess as to visibility when you enter these features, that's fine, but it isn't a primary focus.



Real Time UML. Advances in The UML for Real-Time Systems
Real Time UML: Advances in the UML for Real-Time Systems (3rd Edition)
ISBN: 0321160762
EAN: 2147483647
Year: 2003
Pages: 127

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net