Lesson 1

Logical View of the Object Model

Earlier in the course, we defined four views of the software development lifecycle:

the use case view,
the logical view,
the component view, and
the deployment view.

This module begins our coverage of the logical view.

Module Objectives: After completing this module, you will be able to:
1. Describe the purpose and function of the class diagram
2. Define attributes and operations
3. Model a class
4. Model associations between classes
5. Model aggregation and composition
6. Model generalization
7. Model composition context
In the next lesson, you will learn about the function and purpose of the class diagram.
Object-oriented (OO) Terminology: During the development of the object-oriented (OO) terminology, three very similar terms came into use: "object model," "class diagram," and "object diagram." Some people use them interchangeably, not realizing that they describe very different concepts.
Object model and class diagram typically refer to a class-level model. The class-level model is the one implemented by all OO CASE tools. The object diagram literally models objects and their connections, or links. This diagram is very useful but is rarely included in a CASE tool. We cover the object model or class diagram in this module and the object diagram later in the course.
Object-oriented methodology is a way of viewing software components and their relationships. Object-oriented methodology relies on three characteristics that define object-oriented languages: encapsulation, polymorphism, and inheritance. These three terms are elaborated below.

Objects and Methods

An object is an encapsulation of data together with procedures that manipulate the data and functions that return information about the data. The procedures and functions are both called methods.

Encapsulation: Encapsulation refers to mechanisms that allow each object to have its own data and methods. The idea of encapsulating data together with methods existed before object-oriented languages were developed. It is inherent in the concept of an abstract data type. Objects can be implemented in classical languages such as C using separate compilation or structs to provide the encapsulation. This is a common technique for implementing abstract data types in procedural languages. Object-oriented languages provide more powerful and flexible encapsulation mechanisms for restricting interactions between components. When used carefully, these mechanisms allow the software developers to restrict the interactions between components to those that are required to achieve the desired functionality. The management of component interactions is an important part of software design. It has a significant impact on the ease of understanding, testing, and maintenance of components.

UML Distilled

Polymorphism and Overloading

Polymorphism refers to the capability of having methods with the same names and parameter types exhibit different behavior depending on the receiver. In other words, you can send the same message to two different objects and they can respond in different ways. More generally, the capability of using names to mean different things in different contexts is called overloading. This also includes allowing two methods to have the same name but different parameters types, with different behavior depending on the parameter types. The capability of using words or names to mean different things in different contexts is an important part of the power of natural languages. People begin developing the skills for using it in early childhood.

Inheritance: One important characteristic of object-oriented languages is inheritance. Inheritance refers to the capability of defining a new class of objects that inherit from a parent class. New data elements and methods can be added to the new class, but the data elements and methods of the parent class are available for objects in the new class without rewriting their declarations. For example, Java uses the following syntax for inheritance:
```
public class B extends A {
	//declarations for new members
}
```
Objects in class B will have all members that are defined for objects in class A. In addition, they have the new members defined in the declaration of class B. The extends keyword signals that class B inherits from class A. We also say that
1. B is a subclass of A and that
2. A is the parent class of B.
Access Modifiers: Access Modifiers
In Java the programmer has control over which members are inherited. In Java, a member is defined with a keyword indicating its level of accessibility.
The keyword private indicates that the member is not inherited by subclasses.

The Logical View

Once you define the expectations of the users in the use case view, you then do most of your work in the logical view. Six different diagrams are included in the logical view:

the class diagram,
the object diagram,
the dynamic models,
the sequence diagram,
collaboration diagrams, and
the activity diagram.

Each diagram is a tool for discovering and describing different aspects of the system. Together they provide a complete description of your software solution. The class diagram is the most important by far, but every model needs to be tested. Use cases provide the high-level test plan. The object diagram is ideal for testing the class diagram. The dynamic models, sequence, and collaboration diagrams are excellent for describing object interactions. The activity diagram is very good for describing the functional behavior implemented by objects.

The Class Diagram: This module will describe the class diagram and its notation and usage. We'll cover how to define individual classes and how to assemble classes to build models. Remember that although the notation and techniques may be standard, their application in real-world projects may vary widely.