Attributes and Constraints

Abstract

In essence, without attribute values, objects and business events cannot be identified by human users. In order to make objects and events identifiable for the outside world (including the user), we have to adorn them with values by which we can recognise them. For example, a customer becomes identifiable through his/her name, address and telephone number. An account becomes identifiable through its account number, and a deposit event becomes identifiable through the amount deposited, the account number of the account to which the money is to be deposited and the date and time at which the deposit took place. To this end, in a domain model, the definition of a business object type includes a number of attributes (called static features in UML). In terms of a relational database, the attributes will correspond to the columns of a table definition. Each object will have a value for each of the attributes in the definition of its object type. Together, all these values form the ‘state vector’ of an object. The range of values an attribute can take can be constrained to a particular type such as a numerical value, a date, a time, text and so on. This is called the data type of the attribute. For example, a customer may have a street name that is of data type ‘text’, and a ZIP code of that is of data type ‘numeric’.