02
Sat, Nov
2 New Articles

Object-oriented Design for AS/400 Java Applications: Object Modeling and Basic Java Class Design

Java
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

This article introduces Java through one of its most important features—object- oriented application design. The process of object modeling will be covered, using a sample application and an explanation of the Java code that supports the object model created.

Java is hot, but what makes it so hot? The source of that heat is object-oriented programming. The object-oriented nature of Java is not just a feature—it’s the basic foundation of Java. The realization of long-term benefits from writing business applications in Java will be achieved only through sound object-oriented design. This article is the first in a series designed to teach Java programming in the context of object-oriented design.

The following material introduces the Unified Modeling Language (UML) for use as the standard graphical notation for object modeling. A small purchase order application will be explained from object design to Java code.

Object-oriented Analysis—Use Cases

Just like structured applications, an object-oriented project begins with analysis and then moves into design. The first phase of object-oriented analysis is the development of use cases. A use case is simply a written summary of a typical interaction between a user and a computer system to perform a discrete business task. For example: “The order processor will search for the customer in the system first using the caller ID, as shown on the phone LCD. If the customer information is not found, the order processor will request the customer’s number. If the customer does not know his number, the customer’s company name will be used. If the customer information is still not found, the order processor will assume that the customer is not in the database and will then add that customer to the system.”

Initially, enough use cases are developed to provide an overview into the scope of the application. Use cases should provide a clear understanding of what the user expects from the application. Often, the use cases are used for bargaining chips (“I can get the application done two weeks earlier if I drop this caller ID thing and we just force the customer to know his number”). And, as always, it is good to “get it in writing.”

Object Discovery

Using use cases to provide project scope, the application designer works closely with a domain expert—a user who is an expert in the business area of the proposed application—to model the world by discovering the business objects that form the vocabulary of the problem domain (the application).

A business object is nothing more than a business entity. As a legacy application programmer, you might ask, “Isn’t this process of discovering business objects the same as the first step of relational database design?” Yes, they are similar. A major part of both structured and object-oriented analysis is the identification of business entities. In the design phase, both object-oriented and structured methods define the attributes of entities and chart the relationships between those entities. But with object-oriented design, the behavior of an entity, as well as its attributes, is designed to be an integral part of that entity.

Take a moment to look at the object model of Figure 1. Then look at the entity relation chart in Figure 2. Both of these graphics model the same business entities except for a few extra objects in the model of Figure 1—specifically Consumer and Company. Object-oriented analysis drills down further in the decomposition of entities by classifying them into hierarchies (more on that later). For now, understand that the identification of objects is the hardest part of object-oriented analysis and design. A well-designed object model is elegantly intuitive, but, as Descartes once said, “The discovery of an order is no easy task. Yet, once the order has been discovered, there is no difficulty at all knowing it.” To help clarify objects, you need a graphic design aid. This is where UML comes into play.

The object model of Figure 1 uses the notation specified by UML. For the past decade, each of the half dozen leaders in the object-oriented programming industry had its own published design methodologies, complete with dissimilar notations. In 1997, three of them, Booch, Jacobson, and Rumbaugh (collectively known as “the three amigos”), got together and collaborated on a standard graphical notation—UML. The notation of UML is to be used to graphically express object-oriented designs. In the short time that UML has been available, it has already been widely embraced as the standard for object modeling.

The Purchasing Problem Domain

The purchasing application’s UML in Figure 1 uses boxes to represent business entities or objects. Each object box has three sections: The top identifies the object, the middle lists the attributes of the object, and the bottom shows the operations (a.k.a. behaviors) that are associated with that object. The PurchaseOrder object, for instance, has order number and due date attributes along with operations to add line items to the order and to allocate inventory for the order. It also has an operation that has the same name as the object itself—PurchaseOrder. Operations such as this are special operations known as constructors because they are used to create an object and then set the initial state of that object.

Design with Class

A class is a set of objects that share a common structure and a common behavior. The Java implementation for the class of PurchaseOrder objects is shown in Figure 3. The PurchaseOrder class is the Java code designed to hold the attributes and the behaviors of purchase orders. This Java class contains the attributes that are in the UML object model of Figure 1: orderNumber and dueDate. Two other attributes—lineItems and customer—are

defined in the class but are not explicitly defined in the UML. Those attributes relate the PurchaseOrder object to other objects—POLineItem and Customer. The UML graphically portrays these relationships with links to the other objects. Adding these objects as data members to the attribute section of the object box would be redundant and would also clutter up the object model.

Note that the link from PurchaseOrder to POLineItem has a diamond at the top of the link. The diamond represents aggregation; you have multiple line items for a purchase order. That’s why, in the Java class code, the name of the array of POLineItems (as represented with the Java dynamic array data type—Vector) is plural.

Behavioral Relationships

Let’s compare the object model’s PurchaseOrder to POLineItem and Customer relationships (Figure 1) with the entity relation chart (Figure 2). The attributes of the PurchaseOrder entity are represented with data fields of a record format in Figure 2. The custNumber field of PurchaseOrder is tagged as a foreign key to show the dependency to the Customer entity. The PurchaseOrder entity of the entity relation chart has no POLineItem array as the UML did—that is handled with the relational database design. The POLineItem entity contains the orderNumber foreign key to relate each line item to a specific purchase order.

The UML and the entity relation diagrams appear to be quite similar. The major difference is the object model’s encapsulation of an entity’s behavior to an object. That is the value-add of object-oriented programming—the ability to encapsulate the definition of the procedures that manipulate that state of an entity within the same discrete storage location as its data. The third section of the object box contains the operations of that object. These operations are the names of functions that will be defined in a Java class with the code that implements the computer simulation of the behaviors of an object. The Java class code of Figure 3 shows the function definitions for the operations of a purchase order: allocate, addLineItem, and PurchaseOrder. These functions are implemented to accept specific external parameters and then provide the object’s behavioral code between the function’s curly braces. Unlike RPG and COBOL, there are no global variables in Java. The functions that constitute a class have access only to those fields, those data members, those attributes (these three terms all mean the same thing) that are a part of that class. A class’s only connection to the outside world is from the external parameters that are passed to those functions.

Abstract Data Types

The Java class definition of a purchase order object is what is known as an abstract data type. We are all familiar with a number of general data types—data types like integers, floats, and the ubiquitous zoned-decimal and packed-decimal of RPG. These data types all have attributes: their numeric values, and, for zoned and packed, their decimal count. Just like Java classes, these basic data types have operations associated with them—addition, subtraction, multiplication, division, and, of course, assignment. In RPG, COBOL, or CL, you define a variable as a particular data type. For example, with CL, you might have the following decimal data type variable declaration:

DCL &MONEY *DEC LEN(9 2)

The variable MONEY may then invoke the implicit addition and assignment operations:

CHGVAR &MONEY VALUE(&MONEY + 5.4)

With object-oriented programming languages, you define your own data types (except for a few built-in ones). These abstract data types are designed by you to encapsulate the attributes that represent the state of an entity along with the operations that modify the state of that entity.

Construction

This article’s definition of a purchase order Java class is an abstract data type. That is, the fields and functions that make up a class form an abstraction of an entity. That Java class can then be used as a user-defined data type—hence the term abstract data type. For example, the Java PurchaseOrder class name is used as an abstract data type to declare the type of a Java variable in the following statement:

PurchaseOrder poVariable;

But before you can use this purchase order variable, you must first create it with an object-oriented process known as construction. The poVariable, until it is constructed, is considered a null object—it has not been assigned to represent a particular business entity, and it does not contain any data. It doesn’t even have storage reserved to contain that data. To construct a Java object, you use the class constructor of the abstract data type of the variable to be created. For the poVariable class variable, you use the PurchaseOrder constructor function passing the required parameters, as shown in Figure 3 (remember that a constructor function has the same name as its class). That operation (a.k.a. function) takes an integer order due date value and a customer object. Constructors are special functions because they are used to create an object instance of a class. In Java, an object is created by using the reserved word New followed by the name of the constructor function of the object to be created along with its required parameters:

poVariable = new PurchaseOrder(1298, aCustomerObject);

Java’s New operator handles the storage allocation for the object, and the class’s constructor function is implemented with the code necessary to set the initial state of that object. For example, the purchase order constructor first sets its due date attribute to be equal to 12/98 and then sets its customer attribute to reference the passed customer object. The PurchaseOrder constructor then creates the lineItems vector attribute. Note that the Vector class is a base part of Java and provides an abstract data type of a dynamically sizable array. As you can see in Figure 3, the constructor function for the Vector class takes no parameters, and the New operator returns a reference to the object created by Vector’s constructor. Likewise, when the PurchaseOrder constructor completes, poVariable is set to reference the newly created purchase order object.

Class vs. Object

The terms class and object are being thrown out to you in such a seemingly random fashion that they may appear to be arbitrary. But there is a difference between a class and an object.

A Java class is the code that represents an entity, and an object is a specific instance of an entity. A class is an abstract data type that can be thought of as the mathematical set of all objects of that data type. An object, on the other hand, is one instance of an object of that set. A class is the definition (or pattern or template) for an object, and an object is the physical manifestation of that definition (or pattern or template). An object has its own state, behavior, and identity.

To use an AS/400 database analogy, a class could be compared to a record format. That record format, like a class, has fields for the representation of the attributes of entities. An object could be compared to a single record. The values of the fields in that record contain the state of a specific entity, and the key of that record holds the unique identity of that entity. The behavior of the entity...well, here, the analogy breaks down. This is one of the advantages of object-oriented programming—the behaviors of an entity are encapsulated in the object that represents the entity.

No Object Is an Island

An object interacts with the outside world through its functions. Values and objects are passed as parameters, and the functions return an object (technically, a function can also return a simple data type like an integer or a float rather than an object). The UML notation for operations shows the return data type. For instance, the Customer object’s checkCredit function returns an integer. Some functions return nothing, which is represented with the Java keyword Void.

Remember poVariable? The routine that declared that class variable interacts with the PurchaseOrder object by invoking the desired operation using the Java syntax of the variable name, the dot operator, and the function name followed by any required parameters. For instance, look back at the purchase order class’s addLineItem function in Figure 3. The purchase order’s line items attribute, lineItems, invokes the Vector class’s addElement() function. This function adds an element to the lineItems dynamic array. That element will then reference the purchase order line item object passed to Vector’s addElement() function:

poVariable.addLineItem(289, 3);

This is the first level of object-oriented programming with Java: You use classes as abstract data types to declare class variables. Through those variables, you can invoke the class functions that encapsulate the business rules for the entities represented by that class. A well-designed class encapsulates the operations of a business entity by hiding the complexity of the class implementation from other programmers who merely want to use that class. Realize that the user in this case is another programmer who uses the class as an abstract data type.

As our PurchaseOrder class demonstrates, Java classes themselves may contain other classes and may also receive object references as function parameters. The sequence of object function invocation can therefore become quite complex. To graph the intricacies of nested object function invocations, designers use a different UML notation called sequence diagrams to show how objects interact to support a specific use case. Sequence diagrams will be covered in detail in a later installment of this series.

Three Levels of Object-oriented Programming

The concepts of object-oriented programming are often broken down into three major areas: encapsulation, inheritance, and polymorphism.

Encapsulation was briefly covered above. Inheritance relates to deriving a new class from the definition of an existing class, thus inheriting all the attributes and behaviors of its parent class. The new object definition then has more specific behavior added. The Company and Consumer classes of Figure 1, for example, inherit the address, custNumber, and name attributes from the Customer class, as well as inherit the checkCredit operation. You can think of the parent class as being a generalization of a related business entity and the derived classes as conforming to that generalized API. Polymorphism, the most difficult concept of object-oriented programming to grasp, is

when a program dynamically performs behavior specific to objects from various levels of an inheritance tree. Because inheritance is a kind of generalization of an API, polymorphism acts as a kind of substitution where any object from an inheritance tree that conforms to the same generalized API can be substituted for a class variable of a related data type.

Think Objects

This is but a brief overview into object-oriented design strategies. You have seen how the discovery of business entities in object-oriented design is very similar to the same process in database design. You have been introduced to the use of basic UML for the clarification of an object model. You have also seen how a Java class is coded from the design of that object model, how a Java object is created, and how a Java object interacts with the outside world.

I know that I have only kind of covered encapsulation, inheritance, and polymorphism, but these object-oriented concepts will be covered in detail in a subsequent article in this series. These future articles will continue to expand on the use of UML in object design. They will also continue to show and explain the Java code. For now, go back to your legacy applications, but don’t ever look at a record format again without thinking, “What operations modify the state of this entity?”


Figure 1: The purchasing application’s object model using UML





Object-oriented_Design_for_AS-400_Java_Applications-_...06-00.png 587x562




Figure 2: The purchasing application’s entity relation chart


import java.util.Vector;

public class PurchaseOrder {

// attributes (a.k.a. fields or class variables):

private int orderNumber;

private Vector lineItems;

private int dueDate;

private Customer customer;

// operations (a.k.a. functions or methods):

public void allocate(){

for ( int i = 0; i < lineItems.size(); i++) {

POLineItem lineItem = ( POLineItem) lineItems.elementAt( i);

lineItem.allocate();

}

}

public void addLineItem(int itemNo, int qty){

POLineItem lineItem = new POLineItem( itemNo, qty);
lineItems.addElement( lineItem);

}

// constructor function

public PurchaseOrder(int due, Customer custNo){

// set state of this PO object
dueDate = due;
customer = custNo;

// create (instantiate) a dynamic array to

// hold POLineItems
lineItems = new Vector();

}

}

public class POLineItem { private int quantity;

private int lineNo;

private int itemNo;



Object-oriented_Design_for_AS-400_Java_Applications-_...07-00.png 900x724

private static int lastLineNo = 0;

Item item ;

public void allocate(){
item.allocate(); }

public POLineItem( int itemNo, int qty){

}

}

public class Item {
private int itemNo;
private int allocated;
private int onOrder;
private int onHand;

public void allocate(){/*code */}
public void adjustInv( int amount){/*code */}
}

public class Customer {

private String address;

private String custNumber;

private String name;

public int checkCredit(){

return 10000;

}

}

public class Consumer extends Customer {

private String creditCardNo;

public void invoice() {/*code */}
}

public class Company extends Customer {

private String contactName;

public void invoice(){/*code */}
}

Figure 3: The purchasing application’s Java code

Don Denoncourt

Don Denoncourt is a freelance consultant. He can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..


MC Press books written by Don Denoncourt available now on the MC Press Bookstore.

Java Application Strategies for iSeries and AS/400 Java Application Strategies for iSeries and AS/400
Explore the realities of using Java to develop real-world OS/400 applications.
List Price $89.00

Now On Sale

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: