Chapter 13       The Logical Model

The logical model captures a realization of the information used by use case model. It comprises a set of classes that completely encompass the scope of the system; data that is input to and output from the system, in the form of attributes; a set of relationships that demonstrate how information is passed between classes; and a complete set of operations that capture the functionality used to satisfy the steps of the use cases.

The purpose of the logical model is to:

1.      Analyze the use case model in order to determine that the requirements are complete, and consistent.

2.      Identify a potential high level design of the system.

1 might be called an analysis model, and 2 a design model. In reality it is impossible to draw a distinct line between the 2, because in order to analyze the requirements with a logical model, it is necessary to include some high-level design decisions[1]

13.1Notation

The graphical representation of a logical model primarily consists of a set of class diagrams. Class diagrams contain classes, connected by relationships (and sometimes classes may be represented by subsystems[2]). Classes comprise attributes, operations and relationships.

·        Relationships have a direction[3] and a cardinality[4] at each end of the relationship. Sometimes a relationship includes an additional symbol, indicating the type of relationship that it is. The relationship may include an aggregation, a composition, supertype or associative symbol.

·        Class – The class is represented by a rectangle containing 3 horizontal compartments.

·        The top compartment contains the class name (and optional stereotypes[5]).

·        The middle compartment contains the attributes that describe the class and its relationships.

·        The lower region contains the class operations (or methods, if specifically building a design model).

13.1.1  Relationships

As noted, a relationship always connects exactly 2 classes; that is with the exception of the associative relationship, which connects a class to a relationship. Types of relationship are as follows:

·        Association – All relationships are one of 3 types, association, associative or supertype/subtype. The association relationship is always between 2 classes and indicates that instances of the two classes, may communicate with each other. An association consists of:

·        Direction – indicates which way to read the relationship name. For example, Figure 1: shows that the Customer class communicates with the Table class. The direction of the relationship indicates that the Customer ‘SeatedAt’ the Table, (as opposed to the Table being ‘SeatedAt’ the Customer).

                                                                                          Figure 1:    SeatedAt relationship

·        Cardinality – located at each of the relationship, identifies how many instances of each class may participate in the relationship. Figure 1: shows that customers may be seated at exactly 1 table. One table may be occupied by 0 to 6 customers at any time. Types of cardinality notation are:

·        0..* - indicates zero to many (or any positive number). The relationship is optional[6] and a class instance does not have to participate. Often simply represented by *

·        1 – indicates one and only one.

·        0..1 – indicates one, but the relationship is optional. I.e. both class may have instances that are not in the relationship.

·        1..* - means that one or more instances must participate in the relationship (it is not optional).

·        x..y – the preferred method for specifying cardinality, where x and y are integers. If possible state exactly how many instances participate in the relationship. Use * when x and y are unknown.

The aggregation and composition relationships are special types of association[7].

·        Aggregation – This relationship is used to indicate that one class ‘contains’ another class, but that the contained class instances may exist by themselves. I.e., the relationship is optional. For example a car has wheels. A wheel may be associated with only one car at any point in time, but a wheel may exist independently of the car, and may be transferred between cars. The wheel takes the identifying attribute of the car, but this attribute may be ‘null’. An aggregation relationship always has cardinality of 0..1 at the containing class end of the relationship..This is represented by a hollow diamond symbol, as shown in: Figure 2:

                                                                                      Figure 2:    Aggregation Relationship

·        Composition – The composition relationship is similar to the aggregation, but in this case the contained class may not create an instance without the relationship being in place. . One cannot exist without the other. A driver without a car is very limited in their driving capabilities. The system might assume that if the car is moving then it has a driver. A composition relationship always has cardinality of 1 at the containing class end of the relationship. This is represented by a filled diamond symbol, as shown in: Figure 3:

                                                                                      Figure 3:    Composition Relationship

An important thing to note is that composition and aggregation relationships are not universal across all models. In one project, the ‘Car->Wheel’ relationship may be an aggregation, but in another the same ‘Car->Wheel’ relationship may be a composition. It is an aggregation if we need to track wheels independently of cars, but a composition if we are not interested in tracking wheels, only cars. It depends on the scope of the model.

·        Supertype – The supertype/subtype relationship allows us to abstract similar classes into a generalization class that contains all the information common to its subtype classes. The supertype class contains relationships, attributes and operations, just like any normal class, but with the exception that the supertype class does not ever create class instances. Think of the supertype class as a template from which its subtypes draw their information and then add their own specifics to the class. A spuertype/subtype relationship is shown in Figure 4:.

                                                                               Figure 4:    Example Supertype Relationship

Taking our automated restaurant example; we identified 3 types of person associated with the restaurant. The Customer, the Head Waiter and the Table Waiter. All 3 of these types of person have some attributes in common; namely, a Social Security Number and a Name. These attributes are identical for each person type. Instead of repeating these attributes for each class, we can abstract these attributes into a supertype class named Person.  Now then, each of the 3 subtype classes, Customer, Head Waiter and Table Waiter, inherit these attributes as attributes of themselves, whenever an instance of each is created.

The actual classes, without the supertype relationship, are shown in Figure 5:.

                                                                                   Figure 5:    Expanded Subtype Classes

Notice that in addition to the common attributes, some classes also contain attributes that are specific to that subclass. (table# and shift.)

Similarly, we can abstract class operations into a supertype class, as shown in Figure 6:.

                                                                                  Figure 6:    Abstracted Class Operations

All classes may execute the ‘enterRestaurant’ operation, but ‘payBill’, ‘assignTable’ and ‘clearTable’ are operations specific to an individual class.

Although not recommended, it is possible to build a hierarchy of suprtype classes, such that a subtype class may also be a supertype class, with subtypes that inherit both its attributes and the attributes of its supertype, and so on. (No example is shown, because this modeling behavior is discouraged in an analysis model.)

Finally, the subtype classes also inherit any relationships that are connected to the supertype class. For example, a Person class may have an association with the Restaurant, as either ‘Available’ or not available, as shown in Figure 7:.

                                                                                        Figure 7:    Supertype Relationship

All subtype classes must also be available to the Restaurant. Associating the Person class to a Table class for example, would be incorrect because; although the Customer class has a direct association with 1 table, the Table Waiter class has an association to many tables, and the Head Waiter is associated with all or none of the tables. No single relationship can be used to associate all of the supertype/subtype classes with a Table class.

·        Associative – The associative relationship is different; in that it does not connect 2 classes, but 3, via a relationship. The associative class and the relationship to it are described in detail in Figure 13:.

13.1.2  Classes

An example class representation is shown in Figure 1:.

                                                                                                Figure 8:    Example Class

The class name is Custmer. It is defined by 2 attributes; tableId and #OfPeople. It is responsible for 3 operations; displayMenu, makeOrder and payBill.

Notice that the class attributes and operations take on their own attributes. These are as follows:

13.1.2.1 Attributes

Attributes represent the data that is managed by and referenced from the class. Attributes are defined by a ‘name’, a ‘description’, a ‘type’ and an (optional) initial value. The name of the attribute must be unique amongst the class attributes. The description is textual and describes the purpose for the attribute. Types are described in section 13.2 and identify all the possible values for the attribute. The initial value is the value that is assigned to the attribute upon creation of an instance of the class (if undefined the value is ‘null’). The format of the attribute is, ‘name’:’type’=’initial value’. Referenced attributes are used to identify an instance of the class. Each class has one or more identifying attributes.

·        Identifier – One (or more) attributes are used to uniquely identify each instance of the class. Once the instance has been created the value assigned to these attributes does not change. For example, the tables in a restaurant may be identified by a table number. Once an instance of the table is created its number never changes. In order to re-assign a new number to a physical table, the table instance is deleted and a new one created with the new number. (If table numbers are prone to change, then it is suggested that another attribute is chosen for the table identifier.) Suppose that it becomes necessary to indentify each person seated at a table (perhaps for billing purposes). The Customer class may be assigned a second identifying attribute named ‘seatId’, as shown in Figure 2:.

                                                                                   Figure 9:    Example Customer By Seat

Both the ‘tableId’ and ‘seatId’ will now allow every individual restaurant customer to be identified.

·        Relational Attribute – whenever 2 classes are involved in a relationship, one class is assigned the identifying attribute(s) of the other. The purpose of which is to allow an instance of a class to know which instance of the other class it is in a relationship with. Consider the ‘tableId’ attribute in Figure 3:.

                                                                                 Figure 10:   Example Relational Attribute

The ‘tableId’ attribute is not controlled by the Customer class. Instead it is pulled from the Table class instance and assigned to the Customer instance. Since a Customer instance must always be assigned to a table, the ‘tableId’ is always available when the customer is created. the tableId attribute is called a relational (or foreign) key of the relationship.

Since an attribute may only take a single value at any moment in time, if a class instance is in a relationship with many instances of another class (for example 1 Table may seat many Customers), it is the class with the many instances that is assigned the relational attribute. The example shown in Figure 4: is not valid/

                                                                                    Figure 11:   Illegal Relational Attribute

Since a Table may have many Customers, if more than 1 customer is seated at the table, we do not know what value to assign to the ‘customerId’ attribute.

When the relationship is a ‘1-to-1’

·        Associative Attributes -  What happens if both classes are in a ‘many-to-many’ relationship, as shown in Figure 5:.

                                                                      Figure 12:   Customer Selects Items For Their Order

In this example a Customer instance may select many items for their Order AND an OrderItem instance may be selected by many customers. Which class takes the identifying attribute of the other? The answer is; neither. Since the OrderItem may not contain many values for a ‘customerId’, nor may the Customer include many values for an itemName’, we create a new class to resolve the relationship. This new class is called an ‘associative class’, and its purpose is to show which menu items are being ordered by which customers. The associative class is assigned the identifying attributes of both classes in the relationship, as shown in Figure 6:.

                                                                      Figure 13:   CustomerOrderedItem Associative Class

The an instance of the CustomerOrderedItem class is created each time a relationship is required between a Customer and an OrderItem. The CustomerOrderItem may also take additional attributes, for example ‘course’ (indicating whether to serve as an entrée, starter or desert), and operations, such as addItemToCustomerOrder, removeItemFromCustomerOrder. Note that a CustomerOrderedItem instance is only required when a customer has ordered an item. If a Customer instance exists without any ordered items, then mo instance of CustomerOrderedItem is required.

13.1.2.2 Operations

Operations describe the functionality that is performed by an instance of the class. For example, assignCustomerToTable, or payBill, shown in Figure 6:. Optional parameters may be assigned to the operation indicating the parameters used by the operation and the information that is returned by the operation.For the purposes of the analysis model, the operation need only take a name describing the function that it performs[8]. Detailing operations is described in Chapter 16.

13.1.3  Analysis Data Types

A typical set of data types that you might be used to seeing are of the order; boolean, byte, character, decimal, double, float integer, long, etc.

These are (for the most part) not applicable to an analysis model. They are system specific, in that they are dependent upon the architecture of the hardware and the software that will be used to execute the application. The definition of each may change if the source language changes and will definitely change if the hardware architecture changes.

For our analysis model, we need a set of well-defined data types that are hardware and software implementation independent. Types are the building blocks that go towards making up the attributes of the classes, and they also allow us to specify a range of values (upper and lower bound). Let’s start with the following basic types, each of which is defined as follows:

·        lowercase_characters – the 26 letters from a to z.[9]

·        uppercase_characters – the 26 letters from A to Z.

·        punctuation_characters - ~!@#$ .. etc.

·        numbers – 0 to 9.

Those are the characters on a typical keyboard. From these definitions we are able to build some basic types for use with our attributes.

·        positive_integer – one or more ‘numbers’, or to write it in shorthand; 1[number]*.

where x[..]y means between x and y instances of what is inside the brackets in any order, and ‘*’ means any number >0.

For example; 1[number]3 is the range of positive integers from ‘000’ to ‘999’.

·        negative_integer – one or numbers beginning with a ‘-‘; ‘-‘1[number]*

where characters inside quotes ‘..’, mean exactly what is inside the quotation marks.

For example; ‘-‘3[number]3 is the range of negative integers from ‘-000’ to ‘-999’.

·        integer – is the range of all positive and negative integers; or [negative_integer+positive_integer]

where ‘+’ indicates the concatenation of the two sets of values and [..] without delimiters, indicates any number in any order..

·        real - is any integer followed by a decimal point followed by a positive integer; or [integer]+’.’+[positive_integer].

For example; -01230.01230.

·        letter – is the combination of lowercase and uppercase characters; [lowercase_character+uppercase_character].

·        character is one of any combination of letters, punctuation characters and numbers; or 1[letter+punctuation_character+number]1.

·        text - is any number of characters; [character].

We can build up explicit definitions of our data types using a regular expression language such as that described above[10]. Use any language that you wish, so long as it explicitly defines the groups of data that your attributes may take.

One final example. That is of a date (in the form yyyy/mm/dd):

·        date – in terms of a 4 digit year followed by a 2 digit month, followed by a 2 digit day; or 4[positive_integer]4+’/’+[‘0’|’1’]+[number]+’/’+01{2_digit_integer}31, where; the ‘|’ symbol indicates an exclusive OR (1 or the other, but not both) and curly braces ‘{..}’[11] indicate a range of values. The type 2_digit_integer needs to be defined .. I leave it up to the reader to find their own definition. There is no single ‘right’ answer.

Now that we have a way to define data types, the class attributes may be assigned a type. For example a person class might have attributes named, name, address, city and postcode as shown in Figure 14:, where

                                                                                         Figure 14:   Example Data Types

‘personName’, ‘streetName’, ‘usCity’ and ‘zip’ have all been defined using the above notation.

13.2Class Diagrams

The class diagram is a ‘static’ diagram primarily used to capture the data of your system. [It also assigns operations to classes, as described in subsequent chapters.]

As you build class diagrams, resolve duplicate classes into a single class, and remove insignificant classes by absorbing them into an existing class.

13.2.1  Classes

An initial set of classes is obtained by capturing the objects discovered in the detailed use case activity diagrams, on a class diagram. (Each object translates into a potential class).

1.      Create a package to house the classes.

2.      For each object found in the use case details, create an equivalent class in this package[12].

3.      Describe each class with an overview of its scope, functionality, data and purpose (draw this information from the use case steps).

4.      Create identifying attributes for each class that may be used to explicitly and uniquely define each instance of the class.

5.      Add attributes to the class to represent the information used by the class and data that is returned by the class. Add a textual description of the attribute’s purpose.

6.      When all classes have been identified, create a class diagram to capture a pictorial view of the classes.

7.      Starting with a significant[13] class, add this to the diagram.

8.      For each class that has a direct relationship with a class on the diagram, place it on the diagram and draw a line between the 2 to  represent  the relationship between them.

Continue until all objects have been converted to classes. If your diagram becomes cluttered, create another diagram, place  a copy[14] of a significant class onto that diagram, and continue building your class relationships.

13.2.2  Relationships

9.      As you identify a relationship, give the relationship a name, and add an arrow to indicate which direction the name implies.

10.  Identify the cardinality for each end of the relationship. Add aggregation and composition adornments to the relationships, as necessary.

11.  If the cardinality at both ends of the relationship is >1, create an associative class and connect this to the relationship.

12.  Group similar classes and create a supertype type class from which they may inherit attributes. Connect the subtype classes to the supertype using the inheritance relationship. [It might be a good idea to collect supertype/subtype relationships on their own diagram, in order to prevent clutter of the analysis class diagrams.]

13.  For each relationship, identify the attributes that are relational keys of the relationship. Add these to the appropriate class in the relationship. Remember that the relational key always passes from the class with the least instances to the class with the larger cardinality. If the cardinality is 1 to 1 then the direction of the relational key is optional. So give the controlling class identifiers to the least important class in the relationship. If the cardinality is 1 to 0..1. then give the relational key to the class on the 0..1 side of the relationship. In this manner, if the class on the 0..1 side of the relationship does not exist then there is no problem with resolving a value for the relational key.

Note that a relational key attribute of a class may also be an identifying attribute of that class.

In an associative relationship, assign keys from both classes in the relationship to the associative class, as identifying attributes.

In the supertype/subtype relationships, no foreign key is required. The subtype classes automatically inherit all the attributes of the supertype class, including its identifying attributes.

13.2.3  Attributes

14.  Create a package to house data types.

15.  Define class attributes in terms of datatypes. If the datatype does not exist, create it in the datatypes package and reference it form the attribute definition.

13.2.4  Example Class Diagram

An example to the above steps is shown in the diagrams that follow.

1.      Create a package to hold your classes.

                                                                                         Figure 15:   Visio Model Explorer

 The package in the Visio model explorer is named ‘Classes’, as shown in Figure 15:.

2.      Create classes in the ‘Classes’ package.

                                                                                   Figure 16:   Potential Analysis Classes

Figure 16: shows a set of potential classes for the automated restaurant example.

3.      Detail the properties of the class.

                                                                                    Figure 17:   class Properties Dialogue

For each of the classes, in the ‘Classes’ package, a description has been added to the class properties. Figure 17: shows the description for the Table class in Visio.

4.      Add identifying attributes to the class.

                                                                                   Figure 18:   Identifying Class Attributes

In Figure 18: the ‘table#’ has been dded to the ‘Table’ class as an identifying attribute. Within a single restaurant it is assumed that every table number is unique for that table.

5.      Add other attributes as defined by the use cases.

                                                                                             Figure 19:   Class Attributes

From the Use Case Model, we can determine that we will need to know the number of seated customers, the location in the restaurant, the maximum number of customers and whether the table is available. This have been added to the ‘Table’ class as attributes in Figure 19:.

6.      Create a class diagram, and

7.      Add significant classes to the diagram.

                                                                                         Figure 20:   Initial Class Diagram

Figure 20: shows a Visio class diagram with the Table class and classes that are gong to interact with the Table class.

8.      Draw relationships between classes.

                                                                         Figure 21:   Relationships Between Initial Classes

9.      Add names and cardinality to the relationships.

In Figure 21: relationships have been drawn between the Table class and classes that it interacts with. The relationships have been named to describe the relationship and arrowheads added to the relationships to show which way to read the named relationship. Cardinality has been added to the relationships to define how many instances of each class participate in the relationship. The relationships may be read as:

A single Restaurant Contains one or more Tables.

Zero or more Customers Sits At  a single Table.

What this also tells us is:

A Restaurant cannot have zero Tables. A Table may not be allocated to more than one restaurant. If a person is not seated at a Table then they are not a Customer. A Table is still a Table even with no Customers.

10.  Add aggregation and composition adornments to the relationships. (Personally, I find that these are not necessary, but some people like to see them on the class diagram.) Where one class is part of another class, add an aggregation symbol to the relationship, as shown in Figure 22:.

                                                                                        Figure 22:   Example Aggregation

Since the restaurant ‘Contains’ tables within it, we may consider the table to restaurant relationship to be an aggregation. Furthermore, since the table does not exist unless it inside the restaurant, the relationship may be also considered a composition, as shown in .

                                                                                        Figure 23:   Example Composition

If the cardinality on the Restaurant end of the Contains relationship was optional (begins with 0), then a composition adornment would not be appropriate. In a composition relationship, the child instance may not exist without the parent instance.

Note: the adornments are for display, and help to clarify the model to some readers. It is the cardinality at each end of the relationship that is important, not the symbol.

11.  Identify associative relationships. When the diagram is complete, look for many-to-many relationships and create an associative relationship to a class, in order to resolve multiple instances of each class in the same relationship.

                                                                         Figure 24:   Example Many-To-Many Relationship

Let us assume that in our restaurant, that a waiter may be assigned to many tables, but also that a table may have many waiters (perhaps there is one for drinks, one for food and one for the bill). In Figure 24:,neither the ‘Table Waiter’ class can take the identifying attribute of the ‘Table’ as a relational key, nor may the ‘Tables’ class take the ‘Table Waiter’ identifier as a relational key.

An associative class is created, as shown in Figure 25:, to capture which tables are assigned to which waiter.

                                                                                   Figure 25:   Example Associative Class

The ‘Waited Table’ class takes the identifying attributes of both classes in the IsAssigned relationship. Notice that it also takes a ‘service’ attribute that identifies the type of service being performed by that waiter at that table. (Note that the ‘service’ attribute could not be assigned to either the ‘Table’ class, nor the ‘Table Waiter’ class.)

12.  Can you make the more efficient by creating supertype/subtype classes? The Automated Restaurant example has no inheritance relationships, but an example of one for future consideration is shown in Figure 4:.

13.  Check that all relational key attributes have been assigned to appropriate classes in every relationship. As classes are added to the diagram, some additional identifying attributes may have been included in the model. Propagate this across all relationships. For example, Figure 26: shows that a restaurant identifier has been added to the Restaurant class, in the case that the system will manage multiple restaurants.

                                                                                   Figure 26:   Restaurant Identifier Added

The ‘restaurantName’ attribute is propagated to the Table and the Customer classes, in order to indicate which restaurant they are associated with.

14.  Finally, although not necessarily the last step in the process, Figure 27: shows that a ‘Types’ package has been created to house the datatypes, used by the attributes in the logical model.

                                                                             Figure 27:  

13.2.5  Operations

Operations are added to classes in the next 2 chapters.

13.2.6  Normalization

Finally, a word on normalization of the logical model. I am not an expert on database development (which is where the term normalization comes from), but a systems analyst should be able to normalize their logical model to 3^rd normal form. The logical model, without operations is no more than an Entity Relationship Diagram (ERD), and can be treated like any other database.

From Wikipedia: a relational database table (the computerized representation of a relation) is often described as "normalized" if it is in the Third Normal Form. The 3^rd normal form (3NF) includes the 1^st and 2^nd normal (1NF and 2NF) forms. These are described in Wikipedia as follows:

·        A table[15] that adheres to 1NF is one that is free of repeating groups. In the analysis class model, this means that for every instance of every class, each attribute takes one and only one value at any time.

For example, the table class has associated customers. If we were to combine the Table and Customer classes into a single Table class and add an attribute to the Table named ‘customerId, then for every instance of Table, there would be multiple values for the customerId attribute. This is an example of a repeating group, and should be removed from the logical model.

·        A table is in 2NF if and only if, given any candidate key and any attribute that is not a constituent of a candidate key, the non-key attribute depends upon the whole of the candidate key rather than just a part of it. In the analysis class model, this means that for every attribute which is not an identifying attribute, its value is dependent upon which instance of the class we are talking about. The purpose is to reduce repeating attribute values by putting them into their own class.

For example, consider the ‘capacity’ attribute of the Table class, shown in Figure 19:. Let’s assume that all tables in a restaurant are of the same size, but tables in a different restaurant may be a different size. Then the ‘capacity’ attribute should be assigned to the Restaurant class, and not the Table class, since its value never changes by table.

·        Requiring that non-key attributes be dependent on "nothing but the key" ensures that the table is in 3NF. For the analysis class model, this means that all attributes of a class are dependent upon the identifying attributes of that class, and no other attribute.

Consider for example the Table class in Figure 28: with a tableTpye attribute added.

                                                                                    Figure 28:   Table With Type Attribute

Table types may be ‘big’, ‘medium’, or ‘small’. Big tables have a capacity of 8 people, medium 6 and small 4. The ‘capacity’ attribute is no longer dependent upon the ‘table#’, but upon the ‘tableType’. 3NF demands that a separate class (Table Type say), is created that defines ‘capacity’ against the ‘tableType’, as shown in Figure 29:

                                                                                             Figure 29:   Example of 3NF

Not being an expert on database normalization, it appears that satisfying the rules for 1/2/3NF will also satisfy 4/5NF rules.

The purpose of normalization is to reduce repetition of information in the class model. Anywhere this can be achieved in an analysis model is a good thing. Although when it comes to design, the complexities involved with database normalization often outweigh the efficiency that can be gained by having some duplication within the data.

13.3Summary

This chapter was not intended to be an all inclusive education on class modeling. There are plenty of books that go into the logical model in much greater depth than was detailed here. It is expected that the reader already has an understanding of the concepts of modeling data, and that this chapter provided a notation and process for using that knowledge.

UML includes a wide variety of notations for specifying class diagrams. What this chapter presented was a minimal notation that allows complete specification of a class diagram as part of a logical model. Any of the notations; (arrowheads, cardinality, relationship names), etc may be substituted for another UML (or even non-UML) supported notation and work just as well.

The notation presented here allows us to take the objects that were identified in the use case model and normalize them into classes that encompass the scope of the problem under consideration.

Following chapters will explain how to use the class diagrams to analyze the use case model for consistency and completeness.