Domain models -- Classes and Objects

In an OO system, one of the most important elements of documentation is the class diagram

The class diagram shows:

• The static structure of the system
• Important entities within the system
• The relationships between the entities within the system

As discussed in earlier lectures, objects are analytic entities. They are entities which are identified as part of analysis which exhibit:

• State: They have a state of being
• Behavior/Function: They do things
• Identify: Objects are distinguishable from each other because they exist. They do not have to be distinguished because the have different state.

In the real world, objects exist. In an application, objects are "instantiated". That is, they are created from a blueprint called a "class".

Classes are identified by "classifying" analytic objects. That is, in the process of analyzing a problem, the analyst creates an "object model" which represents the problem. The resulting objects must be further analyzed for classification purposes. Objects which exhibit the same behavior and state structure belong to the same class.

Classes are abstractions

In the real world, objects may have many things which are different. However, when we model objects in software, we can often ignore much of an object's state of being. That is, we are only interested in modeling those components which are relevant to our system. When we classify objects, we remove all of the details which are not relevant to our system. As a result, a class is derived from a series of objects and its definition only contains those aspects of the original objects which is relevant.

Abstraction: The act process of leaving out of consideration one or more properties of a complex object so as to attend to others; when the mind considers the form of a tree by itself, or the color of the leaves as separate from their size or figure, the act is called abstraction. So, also, when it considers whiteness, softness, virtue, existence, as separate from any particular objects.

- Webster's Dictionary

Because classes are abstractions (ie. they are lacking details), it's possible that different programmers may have different impressions of what a class represents. It is important that classes be documented unambiguously. That is, each class should have accompanying documentation which describes what the class's purpose is.

Representing Classes in UML

Classes are rectangles with up to three compartments. The compartments are:

• The class name (required)
• Attributes (optional)
• Operations (optional)

When classes are rendered (ie. drawn), one must always show the name of the class, but showing the attributes and operations is optional.

Attribute Syntax

When rendering an attribute, the following syntax should be observed:

Name: Type = Initial-value

Name: required Type: optional Initial-value: Optional

Operation syntax

When rendering an operation, the following syntax should be observed:

Name (ParameterList): Return-Type

Name: required ParameterList : optional Return-Type: optional

Parameter List Syntax

When rendering a parameter list (for an operation), the following syntax should be observed:

Name: Type = Default-Value [, ...]

Name: Required Type: Optional DefaultValue: Optional

For multiple parameters, separate parameters by using commas.

Some Examples

Representing Objects in UML

Objects are rendered similar to classes. They are rectangles (the same as classes). There are maximum 2 compartments:

• ObjectName:ClassName
• State

When giving an object a name, one can specify the Object's Name, the class from which it is instantiated or both. NOTE: The main distinguishing feature between objects and classes is that the NAME is underlined when drawing objects.

When showing state, this is typically accomplished by showing the names of attributes and the values they hold.

The process of classifying objects

Analysis defines what the system does. From that analysis, we can identify entities (objects) which are part of the problem. These objects are "classified" so that they can become part of the solution. Similarly, as more analysis and design is completed, more and more objects are identified and then classified.

How does one develop the object model? There are various places one can look:

• Use Cases
• Requirements
• Business environment

Typically, nouns represent objects, but be aware that verbs can also represent objects as well:

A guest indicates that he wishes to reserve a room

In the above sentence, there are 2 nouns, but there are three objects:

A guest indicates that he wishes to make a reservation for a room.

Do actors become classes within our system?

Sometimes they do and sometimes they don't. The question is, do we need to maintain state information about the actor within our system. For example, if you buy a sandwich from any fastfoods, they don't know who you are. Your identity is not recorded within the Point-Of-Sale system. So, even though you are an actor in their system, no object represents you within their system. However, if you buy a DVD player from cooperative store in your working place and you have an ID over there, an object will represent you within the system. That is, the system needs to track your purchases for the purposes of computing refund cheques at the end of the year (among other things).

How do we know when we have identified the right objects?

Later in the course, we will discuss in detail good design practices. For now, good objects are those which exhibit high cohesion. Cohesive objects:

• Have a single responsibility or set of responsibilities which are tightly related to one another
• Have a set of attributes that are all functionally related to the object and not some other object

Relationships between classes

Associations worth noting usually imply knowledge of a relationship that needs to be preserved for some durationit could be milliseconds or years, depending on context. In other words, between what objects do we need some memory of a relationship?

For example, do we need to remember what SalesLineItem instances are associated with a Sale instance? Definitely, otherwise it would not be possible to reconstruct a sale, print a receipt, or calculate a sale total.

And we need to remember completed Sales in a Ledger, for accounting and legal purposes.

Because the domain model is a conceptual perspective, these statements about the need to remember refer to a need in a real situation of the world, not a software need, although during implementation many of the same needs will arise.

In the monopoly domain, we need to remember what Square a Piece (or Player) is onthe game doesn't work if that isn't remembered. Likewise, we need to remember what Piece is owned by a particular Player. We need to remember what Squares are part of a particular Board.

But on the other hand, there is no need to remember that the Die (or the plural, "dice") total indicates the Square to move to. It's true, but we don't need to have an ongoing memory of that fact, after the move has been made. Likewise, a Cashier may look up ProductDescriptions, but there is no need to remember the fact of a particular Cashier looking up particular ProductDescriptions.

Guideline

Consider including the following associations in a domain model:

• Associations for which knowledge of the relationship needs to be preserved for some duration ("need-to-remember" associations).

• Associations derived from the Common Associations List.

Common Associations List.

Category	Examples
A is a transaction related to another transaction B	CashPaymentSale CancellationReservation
A is a line item of a transaction B	SalesLineItemSale
A is a product or service for a transaction (or line item) B	ItemSalesLineItem (or Sale) FlightReservation
A is a role related to a transaction B	CustomerPayment PassengerTicket
A is a physical or logical part of B	DrawerRegister SquareBoard SeatAirplane
A is physically or logically contained in/on B	RegisterStore, ItemShelf SquareBoard PassengerAirplane
A is a description for B	ProductDescriptionItem FlightDescriptionFlight
A is known/logged/recorded/reported/captured in B	SaleRegister PieceSquare ReservationFlightManifest
A is a member of B	CashierStore PlayerMonopolyGame PilotAirline
A is an organizational subunit of B	DepartmentStore MaintenanceAirline
A uses or manages or owns B	CashierRegister PlayerPiece PilotAirplane
A is next to B	SalesLineItemSalesLineItem SquareSquare CityCity

There are three relationships which can exist between classes:

• Association
• Generalization
• Composition

Relationships Between Classes

In a class diagram, obviously you can't have classes just floating around; you need to see the relationship between them. The following table shows the kinds of relationships between classes, their notation, and what they mean.

Sr. No.	Relation	Symbol	Description
1	Association		When two classes are connected to each other in any way, an association relation is established. For example: A "student studies in a college" association can be shown as:
1 a.	Multiplicity		An example of this kind of association is many students belonging to the same college. Hence, the relation shows a star sign near the student class (one to many, many to many, and so forth kind of relations).
1 b.	Directed Association		Association between classes is bi-directional by default. You can define the flow of the association by using a directed association. The arrowhead identifies the container-contained relationship.
1 c.	Reflexive Association	No separate symbol. However, the relation will point back at the same class.	An example of this kind of relation is when a class has a variety of responsibilities. For example, an employee of a college can be a professor, a housekeeper, or an administrative assistant.
2	Aggregation		When a class is formed as a collection of other classes, it is called an aggregation relationship between these classes. It is also called a "has a" relationship.
2 a.	Composition		Composition is a variation of the aggregation relationship. Composition connotes that a strong life cycle is associated between the classes.
3	Inheritance/Generalization		Also called an "is a" relationship, because the child class is a type of the parent class. Generalization is the basic type of relationship used to define reusable elements in the class diagram. Literally, the child classes "inherit" the common functionality defined in the parent class.
4	Realization		In a realization relationship, one entity (normally an interface) defines a set of functionalities as a contract and the other entity (normally a class) "realizes" the contract by implementing the functionality defined in the contract.

Association

It would be possible to create an application within a single object. That object, however, would be very difficult to maintain and understand. To make dealing with complex systems easier, we break them down in to smaller pieces. When we break an application, we try to break them down in to the smallest possible pieces called objects. Each object as a single responsibilities or a set of responsibilities which are functionally related (this is called cohesion). Since individual objects do very little in isolation, it is necessary for objects to associate with other objects.

Association is shown on the class diagram as a line connecting two classes (example in lecture)

Assocations can have a label and multiplicity. The purpose of the label is to make understanding the association easier (example in lecture). Multiplicity shows how many objects are going to be associating (example in lecture).

Basic multiplicity

• lower..upper - (between lower and upper)
• 1 - exactly 1
• 0..1 - either 0 or 1
• * - 0 or more
• 1..* - 1 or more
• 4,5,6,8..* - 4, 5, 6, 8 or more than 8

Constraining a class diagram

It is possible to add constraints to a class diagram. Constraints are shown using braces {}. Similarly, one can add notes to the class diagram to help elucidate the meaning if the diagram is ambiguous. (Examples in lecture)

Generalization

As you would have learned as part of a Java or C++ course, object oriented programming makes use of inheritance. With inheritance, attributes defined as part of a super-class may be inherited by a subclass. Inheritance defines the basis for a programming technique called polymorphism.

Generalization is shown with an unfilled, closed-headed arrow pointing from the subclass to the superclass.

Composition

When one class has an association with another class, that association may be a weak association. However, when that association is strong, it can be represented as a composition on the class diagram. Composition represents a whole-part relationship.

Composition is shown as a filled diamond on the whole side of the relationship. (example shown in lecture)

Navigation

As you are probably aware, associations are implemented as attributes in Java and C++. When two objects associate with each other, this means that each object will have to maintain a reference to the other object in the relationship. In this case, this is called a bidirectional association. That is each side knows about the other side. However, it is not always necessary for both sides to know about the existence of the other side of the relationship. It is possible that when two objects have a relationship, only one of those objects maintains the relationship. This is called a unidirectional association. In this case, an arrow is placed on the association in the class diagram to indicate the unidirectional nature of the relationship. If there is an association between two classes and no arrow is shown, the relationship is bidirectional.

Association classes

Sometimes, the association between two classes requires more than just maintaining a reference between two objects. Specifically, if that association also has state, then an association class should be used instead.
Managing Complexity of class diagrams

An application may consist of thousands of classes. When rendering the class diagram for an application, it is often not feasible to show all of the classes at the same time. So, UML has a mechanism for managing the complexity of classes and their relationships. This mechanism is called "Packaging".

A package is an entity which contains classes or other packages. Packages represent logical structures which can be used to group related classes together. (example in lecture).