CHAPTER
UCP 5 UUCP TCF EF For the running example we obtain
6.2 Attributes
Attributes are, in the conceptual model, the alphanumeric and primitive elements such as date, money, number, string, interval, etc.
Although most programming languages allow attributes to be defined as data structures such as lists, arrays, sets, trees, etc., it is not advisable in conceptual modeling because those structures are better modeled as associations, as explained in the following sections.
Complex concepts (classes) should also not be used as attributes of other concepts (although, again, programming languages allow that). For example, a book should not be an attribute of an order. If a relationship between books and orders exists, then anassociationshould be used instead, because books and orders are complex concepts. An exception to this recommendation occurs when a primitive type (Section 6.2.5) or enumeration (Section 6.2.4) is used to label an attribute;
primitive types and enumerations are defined as stereotyped classes, but they do not behave like concepts. They are used as attribute types. For example, a date is composed by parts such as year, month, and day, however a birth date is considered an attribute of a person, not a complex concept associated to a person.
Attributes in UML are always represented inside a class, as shown inFigure 6.2, where the class Customerhas the attributes:name,id,address, andphone.
115 6.2 Attributes
6.2.1 Attribute types
Attributes may have a type, although this is not mandatory for the conceptual model.Figure 6.3 presents a version of the class ofFigure 6.2with typed attributes.
Types in conceptual models have the same meaning they have in programming languages. In Figure 6.3, we have the classical type String, and primitive user-defined types IdNumber and PhoneNumber.
When an attribute is defined by formation rules, as in the case ofidandphone, it is advisable to define a primitive type especially for it, as is done inFigure 6.3.
Theaddress is something special. Is it an attribute or a complex concept? Is it simply a string or complex concept composed of street, ZIP code, number, city, etc.? This case, as many others, is decided by analyzing the information needs of the users. If addresses are used just to print envel- opes and send mail, then they behave merely as strings, and may be represented as attributes typed as strings. However, if addresses are used to calculate distances and routes, or if they are used to group customers that live in the neighborhood, then they behave as complex concepts and should be modeled as a primitive type. Furthermore, if they have a structure of associations between them, then they should be modeled as complex concepts.
6.2.2 Initial values
An attribute may be declared with an initial value, that is, every time a new instance of the concept is cre- ated, that attribute will automatically receive a defined initial value, which can be changed later if necessary.
In the Livir system, an order may be created, for example, with a total value that is initially zero. This can be defined in the class diagram, as shown inFigure 6.4.
The definition of an initial value for an attribute may also be created with the use of theObject Constraint Language (OCL)(Object Management Group, 2010).
Every OCL expression should be declared in acontext that corresponds to a class. Most OCL declarations also have asubcontext, consisting of a class property, that is, an attribute, association role, or even a method. When declaring the initial value for the attributetotalValuein classOrder, the context isOrderand the subcontext istotalValue. Thus, the OCL expression starts as
Context Order::totalValue
Optionally, the type of the attribute may be added:
Context Order::totalValue:Money Customer
+name +id +address +phone FIGURE 6.2
Attributes represented inside a class.
Customer +name : String +id : IdNumber +address : String +phone : PhoneNumber FIGURE 6.3
Typed attributes.
116 CHAPTER 6 Conceptual Modeling: Fundamentals
In order to indicate that the OCL expression is defining an initial value for an attribute, the clauseinit: is used, followed by the expression that when evaluated produces the initial value for the attribute. As in the example the initial value is the constant0, the expression may be defined as
Context Order::totalValue:Money init: 0
The expression may also be simplified by omitting the type of the attribute:
Context Order::totalValue init: 0
An attribute may have its initial value defined by more complex expressions. Later, examples of more complex OCL expressions are presented, which can be used to initialize attributes with values produced by mathematical and logical operations.
6.2.3 Derived attributes
Derived attributesare understood here as derived alphanumeric values only. If a “derived attribute”
refers to objects or data structures, then they are called derived associations (Section 6.4.3).
Derived attributes differ from normal attributes because they cannot be changed directly. In other words, they areread only.
A derived attribute is calculated and must be defined by an expression. In the class diagram, a derived attribute may be represented by a slash (/) preceding the attribute name (and type), fol- lowed by “5” and the (OCL) expression that defines the attribute.Figure 6.5shows an example in whichprofitis defined as the difference betweenpriceandcost.
Derived attributes may also be defined by OCL expressions.1The expression again has a class as context and an attribute as subcontext. It is followed by the wordderive: this indicates that the expression that follows it defines how the value of the derived attribute is calculated. The expres- sion of the example ofFigure 6.5 defines profit by using the values of other two attributes of the same class:profit5pricecost.
For now, we can consider that the OCL expressions after clauses such as init: andderive: start with an expression that denotes an instance of the context class. That instance is referred to by the wordself.
Order +date : Date
+totalValue : Money = 0 +number : Natural FIGURE 6.4
A class showing an attribute with an initial value.
Book +cost : Money +price : Money
+ / profit : Money = price-cost
FIGURE 6.5
A class showing a derived attribute.
1Not necessarily, because many analysts may chose natural language or other specification languages. However, as OCL is part of the UML package, it is advisable to use it.
117 6.2 Attributes
The notation self.property allows one to access the value of a property (attribute, association role, or method) belonging to the object. For example, in the context of the classBook, the expres- sionself.costdenotes the value of the attributecostof a given instance ofBook.
Thus, the OCL expression that defines the derived value for the attributeprofitof classBookis
Context Book::profit derive:
self.price-self.cost
In OCL it is possible to omit the expression self when the context is not ambiguous. In the example above, the expression could be simplified to
Context Book::profit derive:
price-cost
In theBookcontext,priceandcostmay be nothing else but attributes ofBook. Then, the word selfmay be omitted from the expression.
Derived attributes may not be directly updated. In theBook class of Figure 6.5only the attri- butescostandpricemay be directly updated. The derived attributeprofit is read only: it is calcu- lated as the result of its defining expression.2
6.2.4 Enumerations
Enumerations are a balance between concepts and attributes. They are basicallystrings, and behave like that. But there is a predefined set ofvalidstrings that constitutes the enumeration domain. For example, a calendar day can only assume a value in a set of seven possibilities: Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, and Saturday. Thus, an attribute defined as aCalendarDay (typed with that enumeration) would only assume one out of those seven values.
Enumerations may appear in UML diagrams as stereotyped classes. It is suggested that enumerations that are domain independent are not placed in the same diagram that contains the conceptual model, but in a special package intended to contain the enumerations, as shown in Figure 6.6, because domain-independent enumerations (such as CalendarDay) are very reusable from application to application. Only domain-specific enumerations should be kept together with the other classes of the conceptual model so that people can see their meaning more easily.
InFigure 6.6, the attributevalidityof class Offermay have assigned to it one out of the seven possible values for the enumerationCalendarDay.
Enumerations may be considered stereotyped classes. While they may have associations and attri- butes of their own, the analyst is not encouraged to use those features because they could simply turn the enumeration into a complex concept and it would probably lose reusability. For example, consider theCalendarDayenumeration. It is simply a list of seven names. Suppose now that the analyst adds
2At this point, some readers that are also programmers could be worried about performance issues with the code that will be used to implement derived attributes. As they are by definition “calculated,” it seems a waste of processing time to repeat those calculations if the original values of cost and price do not change. However, the readers can stay calm because code optimization mechanisms are available for derived attributes. For example, the value calculated for a derived attribute may be kept in the cache and recalculated only when one of its components is changed. For example, profithas to be recalculated only when the instance ofBookchanges the values ofpriceorcost.
118 CHAPTER 6 Conceptual Modeling: Fundamentals
some attributes to theCalendarDayenumeration, such as, for example, the working hours. Then, for example, Monday to Friday may have working hours defined from 9 am to 5 pm, Saturday from 9 am to noon, and Sunday may have no working hours at all. Different applications could define working hours in a different way. In this case, what is the difference between this enumeration and a complex concept as it also has attributes and possibly associations and even methods later? Instead of creating attributes or associations for an enumeration it would be advisable to create a new complex concept that accommodates the enumeration and the other attributes. In the example, a new conceptworking daycould be created with two attributes:calendar day(still an enumeration), andworking hours(nor- mal attributes as explained above). Thus, enumerations that are thought to incorporate extra functional- ities should be maintained without that structure and included in normal classes.
To remain reusable, an enumeration should not be able to access another class through an asso- ciation, but any other class should be able to access the enumeration. The fact that Offer in Figure 6.6has an attribute labeled with CalendarDay allows the normal class Offerto access the enumerationCalendarDaybut not vice versa. This keeps the enumeration uncoupled from the clas- ses that use it and therefore it is reusable.
Enumeration values in OCL may be represented by the enumeration name followed by “::” and the value name, as, for example,CalendarDay::Tuesday.
6.2.5 Primitive types
The team can and should defineprimitive typeswhen they deal with attributes that have formation rules, as in the case of ISBN. Primitive types may be defined as classes stereotyped with {primitivec, as shown inFigure 6.7.
TheISBNclass, which is stereotyped in such a manner, is atypethat can be used to define attri- butes. It is not a complex concept like Book, Customer, etc. It has a value with public access
Enumerations Conceptual model
+validity : CalendarDay +discount : Percentual
<<enumeration>>
CalendarDay Offer
<<Constant>> +Sunday
<<Constant>> +Monday
<<Constant>> +Tuesday
<<Constant>> +Wednesday
<<Constant>> +Thursday
<<Constant>> +Friday
<<Constant>> +Saturday
FIGURE 6.6
Definition and use of an enumeration.
119 6.2 Attributes
(marked with “1”), and a validation predicate that is private (marked with “2”), meaning that it can be accessed only by methods inside the class itself. That predicate can be called to verify if the ISBN value is valid or not, considering its formation rule.3That predicate can be used in the con- structor (the method that creates instances of the class) to guarantee that only valid ISBNs are cre- ated. Remember that conceptual classes do not have methods, but primitive types are not part of the conceptual model. They are user-defined, reusable low-level components.
Although the value of the primitive type has public access it is normally accepted that it is immutable. That means that the value of the primitive type can be defined only at creation time, and not updated later. This is to make it consistent with the idea of primitive data elements ascon- stants, and not asobjects. Objects may change their internal state, and constants usually do not.4
Some primitive types, such asDateandMoney, are already available in some programming lan- guages and database management systems. Other not-so-common types, such as ISBN, ZIP code, odd numbers, etc., may be created.
The primitive type formation rule must be defined syntactically, that is, by evaluating expres- sions that do not need to consult data managed by the system. If a formation rule depends on consulting attribute or association values, then it is not, probably, a primitive type, but a normal class. For example, the prime number formation rule may be checked without consulting objects and associations, but aregistered customer namemay not be a primitive type, because to check if a string is a registered customer name, it is necessary to query existing names of current customers.
A primitive type usually isapplication independent, that is, its meaning usually is independent from the system or project being developed. An ISBN has the same meaning and formation rule in any application domain that uses it. Concepts such asCustomer,Book, andOrdermay have differ- ent definitions in different applications and cannot usually be reused without some refactoring effort. However, primitive types are usually 100% reusable, without adjustments or modifications.