	Sign In Sign-Up

7. Step 5: Domain analysis

7.1. Class diagrams I

A domain class diagram contains objects of the real world [Detsis, 2000; Rosenberg, 1999]. A class diagram describes the types of objects in the system and the kinds of relationships that exist among them. UML class diagrams depict the structural view of the system and capture the classes involved and the static relationships between them. [Fowler, 2000a; UML Class Diagrams].

An object is a concept, abstraction, or thing with sharp boundaries and meaning for an application [Rumbaugh et al., 1991]. An object has: state, behaviour and identity. The state of an object is one of the possible contditions in which an object may exist. State is represented by the values or properties or attributes of an object at a given time. The object state changes over time. Behaviour determines how an object reacts, i.e. how its state changes with interaction with other objects. Behaviour is determined by the set of operations or methods the objects can perform. Behaviour may cause a state change. Finally, identity is the nature of an object that distinguishes it from all other objects. It is normally a unique attribute that characterises the object [Detsis, 2000].

A class diagram consists of the following modelling elements: classes and their structure and behaviour, relationships among classes, multiplicity and navigation indicators and role names.

A class is a set of objects that share a common structure (represented by attributes), a common behaviour (represented by operations) common relationships and common semantics. In other words, a class is a template for creating objects. Every object is an instance of a class. Classes are usually static while objects are dynamic (they can be created and destroyed during program execution).

A class is a collection of objects with similar structure, behaviour, relationships and semantics. A class consists of attributes and operations.
- An attribute is a named property or a data definition held by instances of the class. An attribute has a name and a value. An attribute value is the value of an attribute for a particular object. Attribute names should be unique within the class. Each instance of a class has a value for every attribute defined for that class. The syntax of an attribute expression is:
stereotype visibility name : type-expression = initial-value { property-string }
- An operation is a service that can be requested from an object to affect behavior. Operations access or modify attribute values belonging to an object. All instances of a class can use the operations defined for that class. Operations correspond to methods of a class. However, [Fowler] distinguishes among operations and methods in that, "an operation is something that is invoked on an object (the procedure call), whereas a method is the body of procedure" [2000a:59]. The syntax of an operation expression is:
stereotype visibility name (parameter-list): return-type-expression { property-string }
- Stereotypes for classes: boundary, entity, control, exception, utility, persistent.
Relationships provide a pathway for communication between objects. There are a number of relationships linking classes together:
- Association is a simple bi-directional relationship between classes that describes the set of links between the objects in the related classes. From the conceptual perspective, associations represent conceptual relationships between classes. Each association has two association ends, the classes of the association. Each end can be named with a label called a role.
  - Role names denote the purpose or capacity wherein one class associates with another. It is placed along the association line close to the class it modifies. (e.g. the Trade Administrator plays the role of the manager in the association to the Trade).
  - Multiplicity is the number of instances of one class related to one instance of another class. (e.g. in Figure 8, the class on the left is associated with exactly one instance of the class on the right while an instance of the class on the right is associated with 0 or more instances of the class on the left). Multiplicity is an indication of how many objects may participate in the given relationship. We don't deal with multiplicity at this stage of the analysis but we mention it here for completeness.
- Aggregation illustrates the relationship between a whole and its parts (“has” or “contains” relationship). It is transitive, antisymmetric and knows the location of its parts.
- Composite aggregation is an aggregation that its parts cannot stand on their own (implies exclusive ownership). Additionally, the part object may belong to only one whole, and the parts are expected to live and die with the whole (see fig. 11).
- Navigation restricts association to one direction only. (e.g. an instance of the class on the left can ‘talk’ to an instance of the class on the right but not the other way round). We don't deal with navigation at this stage either. Associations turn into navigations in step 8.
- Dependency: One class (the client) depends upon another class (the supplier) for a particular service (a semantic relationship). The client does not have semantic knowledge of the supplier. This means that when the supplier changes the client may also change. Classes are related via a dependency relationship when:
  - an object of the class playing the role of the supplier is global, or
  - when an object of the class playing the role of the supplier is passed as an argument to an operation of the class playing the role of the client or
  - when an object of the class playing the role of the supplier is declared locally.
- Dependencies are not transitive [Fowler, 2000a]. Again, dependencies normally show up during step 8.
- Inheritance: one class shares the structure and/or behaviour of one or more other classes. It defines a hierarchy of abstractions in which a subclass inherits from one or more superclasses. It is a relationship between a superclass and its subclasses where commonality is held at the superclass level and uniqueness is held at the subclass level (a "is-a" or "kind-of" relationship). There are no multiplicities, roles or names for this type of relationship. Inheritance among interfaces is called realization (a "is-used-as" relation). There are two methods to discover inheritance, generalisation and specialisation [Fowler, 2000a]. In the first method we seek to create superclasses that encapsulate the common behaviour and structure of subclasses. In the second method we seek to create subclasses that are specialisations of the superclasses.
Constraint rules are functional relationships between entities of a class diagram (i.e. classes, attributes, relationships etc.). UML allows you to use anything to describe constraints. The symbol for a constraint is {} (e.g. { top speed < 180 mph }). Typical constraints in UML are: {ordered}, {bag}, {set}, {hierarchy} [Fowler, 2000a].

Figure 8 Components of a class diagram

The next figure shows an example association relationship. The relationship is named with the name employs. On the bottom of the relationship we see the multiplicity (cardinality) of the relationship. A company employs many persons. A person is employed in one company. As we see, a relationship is read from left to right. The relationship also contains role names. The company, as the employer, employs many persons. A person, is employed, as an employee, by one company.

Figure 9 Example association relationship

An association class is a relationship that has structure and behaviour. This happens when the information refers to the link between two objects and not to one of the objects. An example is shown in Figure 10. A student may choose up to 10 courses and 3 to 15 students can participate in each course. Grade class does not belong to the Student class as a student may have different grades for each course. Grade class does not belong to the Course class either, as a course may have different grades for each student. Hence, it belongs to their link.

Figure 10 Example of an association class

The next figure shows an example of an aggregation and a composition. An instance of Polygon consists of 3 or more instances of Point. Composition means that a Point can exist only inside one Polygon only and that when the polygon is deleted all its points will be deleted as well. Multiplicity of one in the composition on the side of the Polygon is implied (a specific instance of a Point cannot exist in another instance of Polygon at a specific time). The aggregation, however, means that a Color may be shared by many polygons.

Figure 11 Aggregation and Composition example

The next figure shows an example of a generalisation and aggregation relationships. A WindowWithScrollbar is a Window but is not a Scrollbar. A Scrollbar is a part of a WindowWithScrollbar. Finally, this is a composite aggregation as a scrollbar can not stand on its own in an application.

Figure 12 A Window with a scrollbar