Party, Place, Thing Class Archetype: Typical Responsibilities

The Party, Place, Thing class archetype is one of four class archetypes in Peter Coad's 'modeling in color' object-oriented analysis and design technique.

A Party, Place, Thing class models someone or something who plays different roles.[Coad99]

Like all the class archetypes in 'modeling in color', the usefulness of the Party, Place, Thing class archetype in reviewing and building object models is due to its typical responsibilities, and the lists of typical attributes, operations and associations that represent those responsibilities.

Typical attributes, operations, and associations of Party, Place, Thing class archetypes

Typical Attributes

The typical attributes of Party, Place, Thing classes include:

The identityNumber Attribute

Party, Place,  Thing objects are responsible for being able to be matched with their real-world counterpart. For places, this is often an address, lot or bin number, or a set of coordinates.

For things this normally means remembering a serial number of some sort. Occasionally, however, we might need to generate a separate identity number for Things. These may be needed in the absence of a suitable externally supplied identity number or as a much simpler identifier if external identifiers for the objects involved are complex or vary in format. One example might be producing simple bar code values for videos, CD's and DVD's in a media rental shop so that returned items can be identified and processed quickly.

However, when it comes to uniquely identifying individual people, we can rapidly find ourselves in a quagmire of political sensitivity, regulations, and policies. Unfortunately, from a software design perspective, people and organizations do not come with a simple serial number stamped on them by their manufacturer.

Of course, we can always have our system assign each party a unique identity number but that is only part of the problem solved. Firstly, that identity number may only be recognized within our system, or if we are lucky, across our organization. It does not necessarily help us match information about our party in other systems or other organizations with which we might need to interface. Secondly, it does not help us determine if the person talking or writing to us is who they say they are or represents the organization that they claim they do.

In many countries, government agencies assign people various identity documents, at birth, when they are old enough to start full-time work (for taxation or social security purposes), or when they become permanently resident in that country. Then there are documents issued to people that prove they are entitled to do something. Driving licenses are a good example. All these types of document carry unique numbers or character strings that we could use instead of or in addition to an identity number generated by our software.

However, it is not always considered politically correct to demand that a person provide a government issued number to identify themselves. Therefore, some organizations prefer to use date of birth in addition to the person's name to provide a 'unique enough' identifier. Of course, asking someone their date of birth is also considered impolite in many cultures. Also some types of document are not considered proof of identity by themselves. For example the Council of Mortgage Lenders in the UK recommends two lists of different types of document that prove identity. The entries in the first list, such as passport and military identity card are considered proof of identity alone but entries in the second list, like credit cards, bank cards, and local government tax or rental bills, require two examples to be considered an adequate proof of identity.

Fortunately, the situation with organizations is a little better. Most countries, regions or states require an organization to register with a suitable government agency before it is legally recognized. When an organization does register itself with the appropriate government agency, that agency assigns it an identity number that is unique for that kind of organization in that country, region or state.

Note: [Coad99] calls the attribute representing this responsibility in the Party-Place-Thing class archetype, serialNumber. I feel this name is far too specific to the Thing flavor of this archetype. I prefer the more general name, identityNumber for the archetype as a whole but remembering that this often translates to serialNumber for Things.

For the vast majority of systems, generating the values for Thing object reference numbers is somebody else's problem.  Another example might be a reference number used only within an organization to simplify the identification of individual customers. See again Party Time: Modeling Legal Id's.

Related Operations: None
Related Associations: None

The name Attribute

People use names to identify themselves. The name attribute can be used by a Party object to answer the question 'Which real world person or organization do you represent?'. Unfortunately, as many of us know all too well, names do not necessarily uniquely identify people. Therefore, name attributes also play an important part in search services that locate possible matching objects given a real world party's name or part of that name. It should comes as no surprise then that the Party,Place,Thing and Description archetypes suggest operations that list sets of Party,Place,Thing objects satisfying various criteria.

For Things  names are often no more complex than a single, simple string of characters.  For parties,  it is not always that easy:

• Organizations and people usually have a single legally registered name.

  To be legally recognized, a new organisation has to register their name and other information with a government agency. People also register a name to receive a birth certificate or as part of gaining residency status in another country. For example, my legally registered name is Stephen Richard Palmer.

• Day-to-day people and organizations often use shortened versions, nicknames, aliases or abbreviations of their registered name.

  I use Steve Palmer or Stephen Palmer instead of Stephen Richard Palmer most of the time. Some people use their second given name in preference to their first name. For example my co-author on A Practical Guide to Feature-Driven Development  is known to friends and colleagues as Mac rather than John Felsing. Volkswagen is often called VW. Hewlett Packard are often referred to as HP ... and so on. Many software address books provide a nickname field for this reason but some people use more than one variation of there official name.

• There are common mistakes such as the problem of confusing Stephen and Steven with which I am all too familiar.

• Both people and organizations may have names in a language that uses a radically different character set and may therefore have an English language equivalent.

  Tan Ah Teck is the English equivalent of a Chinese name. In Singapore people often pick and use a traditional English christian name. For example, Ah Teck might be known Jonathan Tan to all his friends and colleagues.

Therefore we need to allow for multiple names, indicating which one, if any, is the legally registered name. To add to the complexity:

• a person's name can usually be split into family name and given names, the order and number of which differs depending upon culture.

The family name comes first in Chinese names but last in English names. Also Ah Teck is two words (two Chinese characters) that form a single name. In contrast the Richard part of Stephen Richard Palmer is seldom used. If names are to look natural on computer generated letters, e-mail messages, faxes, etc then the software needs to be aware of these differences. Mr. Stephen or Dear Palmer is not a helpful start to a message that is trying to sell me some product or service for example.

• some people append a number or other indicator that distinguishes them from others of the same name in their family

e.g. John Smith II or John Smith Junior.

• a person's name may be decorated by a title, honorific or string of academic and professional qualifications such as Doctor, Lord, BSc, MBCS, etc. Some of these precede the name and others are written after the name depending again upon culture.

So as well as possibly needing a multi-valued attribute, a person's name attribute may need a more complex structure than a simple string of characters.

Related Operations: None
Related Associations: None

The address Attribute

Another typical responsibility of a role-player class like a party, place or thing, is to remember information that helps locate and contact their real-world counterparts. This is recognised by the presence of the address attribute in the list of typical attributes of the Party, Place, Thing class archetype.

The address could be a postal address of some sort that enables a party to be contacted using traditional mail services.  The address could also represent an e-mail address used to contact a party by e-mail. It can also represent other forms of electronic address such as phone numbers, fax numbers, and instant messaging names.

The address can also specify the location of a place, such as a building in a city, a storage bin in a warehouse, and so on.

Related Operations: None
Related Associations: None

The customValue Attribute

A Party, Place or Thing object often represents a specific member of a set of items all of which have some similar characteristics. The customValue attribute reminds us to look for attributes that store values that differ from the norm for that set.

For example, the set of  all the cars of a specific make and model all have similar characteristics. However, the owners of specific members of that set may have chosen to add some optional extras that differ from the standard fittings. For example, alloy wheels with low profile tyres instead of the steel wheels that come as standard. A Thing class modelling the car for insurance purposes would typically need to include attributes to track any of these custom values that might affect the insurance premium.

The set of times itself is often modelled by a Description class and this typically holds the default values for all the members of the set.

Related Operations: getCustomElseDefaultValue
Related Associations: Party, Place, Thing - Description

Typical Operations

The typical operations of Party, Place, Thing classes include:

The assessAcrossRoles Operation

To make intelligent decisions about the performance of a Party, Place, Thing there is typically a need to compute some sort of assessment across all the roles a Party, Place or Thing currently plays or has played over a given period time. The assessAcrossRoles() operation reminds us to look for this sort of responsibility when considering role-player classes.

Related Operations: None
Related Associations: Party, Place, Thing - Role

The getCustomElseDefaultValue Operation

Given that a Party, Place, Thing object often holds custom values that differ from default values stored in an associated Description object,  a party, place, Thing class typically needs operations that check to see if there is a custom value in a particular attribute returning that its result if indeed there is one, or returning instead the relevant default  value from the associated Description object.

Related Operations: customValue
Related Associations: Party, Place, Thing - Description

The listRoles Operation

It is frequently necessary to be able to list all, or subsets that match certain criteria, of the Role objects played by a Party, Place or Thing object. The listRoles()  operation reminds of this typical responsibility.

Related Operations: None
Related Associations: Party, Place, Thing - Role

The listInstances Operation

The listInstances() operation is a class scope operation. It reminds us that a typical responsibility of a role-player class, like those of any of the class archetypes, is to be able to search for, find, and list subsets of its instances that match some set of criteria.

Related attributes: None
Related associations: None

The assessAcrossInstances Operation

The assessAcrossInstances() operation is a class scope operation. It reminds us that a typical responsibility of a role-player class, like those of any of the class archetypes, is to be able to assess the performance of a subset of its instances that match some set of criteria.

Related attributes: None
Related associations: None

Typical Associations

The typical associations of Party, Place, Thing classes include:

 The Party, Place, Thing - Role Association

A Role is a way in which someone, some place or some thing participates, so there is typically an association from the Role to the Party, Place, Thing class that is playing the role.

Roles often provide a view of the role-player that is customised for the Moment-Intervals in which the Role participates. For example,  a Role might contain proxy operations for those of its role-player that are used by the Moment-Interval so that the Moment-Interval classes do not need to know anything about the role-player class itself. The Role class will also typically have attributes for information about the role-player that is only relevant when that role is being played.

Related attributes: None
Related operations:  listRoles, assessAcrossRoles

 The Party, Place, Thing - Description Association

Related attributes: customValues
Related operations: getCustomElseDefaultValue