The UML Class Diagram

Abstraction: Amplify The Essential — Eliminate The Irrelevant

The process of problem abstraction is summarized nicely in the following mantra: Amplify the Essential — Eliminate the Irrelevant . The very nature of programming demands that a measure of simplification be performed on real-world problems. Consider for a moment the concept of numbers. Real numbers can have infinite precision. This means that in the real world numbers can have an infinite number of digits to the right of the decimal point. This is not possible in a computer with finite resources and therefore the machine representation of real numbers is only an approximation. However, for all practical purposes, an approximation is all the precision required to yield acceptable calculations. In Java, real number approximations are provided by the float and double primitive data types.

Abstraction Is The Art Of Programming

When compared with all other aspects of programming, problem abstraction requires the most creativity. You must analyze the problem at hand, extract its essential elements, and model these in software. Also, the process of identifying what abstractions to model may entail the creation of software entities that have no corresponding counterpart in the problem domain. Have you ever heard the term “Think outside the box”? It means that to make progress you must shed your old ways of thinking. You must check your prejudices and pre-conceived notions at the door. Successful programmers have mastered the art of thinking outside, inside, over, under, to the left of, and to the right of the box. With their minds they transform real-world problems into a series of program instructions that are then executed on a machine. (After writing this paragraph and reading it over several times I would add that successful programmers have also mastered the art of reducing real-world problems to a state that can be put inside of a box!)

Like any form of art, the mastery of problem abstraction requires lots of practice. The only way to get lots of practice with problem abstraction is to solve lots of problems and write lots of code.

Where Problem Abstraction Fits Into The Development Cycle

Problem abstraction straddles the analysis and design phases of the development cycle. Project requirements may or may not be fully or adequately documented. (In fact, on most projects, the important requirements that deeply affect the quality of the source code are not documented at all and have to be derived or deduced from existing or known requirements.) Nonetheless, you must be able to distinguish the “signal” of the problem from its “noise”. The abstractions you choose to help model the problem in software directly influence its design (architecture).

Creating Your Own Data Types

The end result of problem abstraction is the identification and creation of one or more new data types. These data types will interact with each other in some way to implement the solution to the problem at hand. In Java, you create a new data type by defining a new class or interface. (Interfaces are discussed in chapter 11) These data types can then be used by other data types, or by an application, applet, servlet, Java Server Page (JSP), Enterprise Java Bean (EJB), etc. This is referred to as design by composition. (Design by composition is discussed in chapter 10) The new data types created through the process of problem abstraction are referred to as abstract data types or user-defined types.

To introduce you to the process of problem abstraction and the creation of new data types I will walk you through a small case-study project. The rest of this chapter is devoted to developing the data types identified in the project specification along with a detailed discussion about the inner workings of the Java class construct.

Case-Study Project: Write A People Manager Program

Figure 9-1 gives the project specification that will be used to build the program presented in this chapter.

                         People Manager Program Objectives:    • Apply problem abstraction to determine essential program ele     ments.    • Create user-defined data types using the Java class construct    • Utilize user-defined data types in a Java application    • Create and manipulate arrays of user-defined data type objects Tasks:    • Write a program that lets you manage people. The program should     let you add or delete a person when necessary. The program     should also let you set and query a person's last, middle, and     first names as well as their birthdate. It should also let you     determine a person's age.    • Store the people objects in a single dimensional array.    • Create a separate application class that utilizes the services     of a PeopleManager class.

Figure 9-1: People Management Program Project Specification

As you can learn from reading the project specification it offers some guidance and several hints. Let’s concentrate on the tasks. First, it says that you must write a program to manage people. A full-blown people management program is obviously out of the question so our first simplification will be to put a bound on exactly what functionality is provided in the final solution. Luckily we are guided in this decision by the next sentence that says the program should focus on the following functions:

• Add a person

• Delete a person

• Set a person’s first, middle, and last names

• Query a person’s first, middle, and last names

• Set a person’s birthdate

• Query a person’s birthdate

• Query a person’s age

The project specification also says that you must store people objects in a single-dimensional array. This is clear enough but where will this array reside? Again, the next sentence provides a clue. It says that you must write a separate application that utilizes the services of a PeopleManager class. This is a great hint that provides you with a candidate name for one of the classes that makes up the completed program.

This will suffice for a first-pass analysis of the project specification. The trick now is to derive additional requirements that are not specifically addressed. You can begin by making some assumptions. I recommend you start by identifying the number of classes you will need to write the program. One class, PeopleManager, is spelled out for you in the specification. Another class is also alluded to in the last sentence and that is the application class. You could name the class anything you want but I will use the name PeopleManagerApplication. That should make it clear to anyone reading your code the purpose of that class.

OK, you have two classes so far: PeopleManager and PeopleManagerApplication. Since you will need people objects to work with you need to create another user-defined type named Person. The Person class will implement the functionality of a person as required to fulfill the project requirements. (You can add additional functionality if you desire to exceed the project specification.)

I recommend now that you make a list of the classes identified thus far and assign to them the functionality each requires. One possible list for this project is given in table 9-1.

Table 9-1: People Manager Program Class Responsibilities

Class Name	Functionality Required
Person	The Person class will embody the concept of a person entity. A person will have the following attributes:
		• first name
		• middle name
		• last name
		• gender
		• birthdate
	The Person class will provide the capability to set and query each of its attributes as well as calculate the age of a person given their birthdate and thecurrent date.
PeopleManager	The PeopleManager class will manage an array of Person objects. It will have the following attributes:
		• an array of Person objects
	The PeopleManager class will also provide the following functionality:
		• add a person to the array
		• delete a person from the array
		• list the people in the array
PeopleManagerApplication	The PeopleManagerApplication class will be the Java application class that has the main() method. This class will be used to test the functionality of the PeopleManager and Person classes as they are developed.

This looks like a good start. As you progress with the design and implementation of each class, especially the Person and PeopleManager classes, you may find they require functionality not originally thought of or imagined. That’s OK — software design is an iterative process. As you progress with the design and implementation of a program you gain a deeper insight or understanding of the problem you are trying to solve. This knowledge is then used to improve later versions of the software. Alright — enough soap boxing! On with the project.

The next step I recommend taking is to examine each class and see what piece of its functionality might be provided by a class from the Java API. Let’s look closely at the Person class. The requirement to calculate a person’s age means that we will have to perform some sort of date calculation. The question is: “Is this sort of thing already done for us by the Java API?” The answer is yes. The place to look for this sort of utility functionality is in the java.util package. There you will find the Calendar class. Take time now to familiarize yourself with the Calendar class as you will find it helpful in other projects as well.

This completes the analysis phase of this project. You should have a fairly clear understanding of the project requirements and the number of user-defined data types required to implement the solution. The next step I recommend you take is to concentrate on the Person class and implement and test its functionality in its entirety. The Person class is the logical place to start since all the other classes depend on it.

Quick Review

Problem abstraction requires lots of programmer creativity and represents the Art in the Art of Programming. Your guiding mantra during problem abstraction is to Amplify the Essential — Eliminate the Irrelevant. Problem abstraction is performed in the analysis and design phase of the development cycle. The abstractions you choose to model a particular problem will directly influence a program’s design.

The end result of problem abstraction is the identification and creation of one or more new data types. The data types derived through problem abstraction are referred to as abstract data types (ADTs) or user-defined data types. User-defined data types are implemented as Java classes. These classes will interact with each other in some capacity to implement the complete problem solution.