Identifying Objects - How to be a Successful Technical Architect for J2EE Applications

Identifying Objects

Identify the most important constructs. Nouns in use cases are generally good candidates for classes. Thus a good way to start identifying objects is by reading the use cases and extracting a list of all the nouns. (You can ignore system in the beginning phrase, "The system will," because it's merely part of the use-case format.)

At this point, you should interpret my use of the word object loosely. In the early stages of development, it's impossible to know enough about these objects to understand exactly which classes you will derive from them. Note that my use of the term object differs from some texts that use the term to refer to an instance of a class.

Don't bother with attribution or relationships at this stage. Attribution and relationships are important, but identifying them too early will bog you down in too much detail and will throw the team into frequent tangents. For now, try not to be concerned about process and focus instead on data organization.

As objects are identified, record persistence requirements. Some classes will represent data that your application has to store, usually in a database, and are said to be persistent. In fact, persistent objects frequently appear as entities in the data model. I often record objects with persistent data as entities in the data model as they're identified in the object model. I discuss data modeling in detail in chapter 7.

Objects identified at this stage are high level. You will further refine and expand them later in the process, using objects to determine specific classes.

Object Identification Example

Let's use an example paraphrased from a reporting system I once implemented. The team defined the following uses cases:

The system will provide an interface that will accept report template definitions from an existing MVS/CICS application. A report template consists of an ID, a name, a list of parameters required to run the template, and a list of data items produced by the template.
The system will allow application administrators to control the report templates that users belonging to a trust customer organization can run.
The system will run reports at least as fast as its predecessor system did on average.
The system will restrict reported data for all trust customer users to that of the trust customer organization to which they belong.
The system will allow banking support users to execute all report templates using data from any trust customer organization.

Looking at the nouns in the use cases in order (ignoring system, as mentioned earlier) gave us the list that appears in the first column of table 6.1.

Table 6.1: Object Identification Example
Noun (fromuse case)	Object
Interface	ReportTemplateInterface
Report template	ReportTemplate
List of parameters	ReportTemplateParameter
Data item	ReportDataItem
Application administrator	ApplicationAdministrator
Trust customer organization	TrustCustomerOrganization
Trust customer user	TrustCustomerMember
Reported data	Report
Banking support user	BankingSupportUser

Next we rephrased the nouns to make them self-contained object names, as shown in table 6.1. By self-contained, I mean that object names shouldn't depend on context to provide meaning. For instance, interface from the first use case became ReportTemplateInterface and list of parameters became ReportTemplateParameter. The fact that our use case referred to a "list" of parameters was documented as a relationship. The more descriptive the object name, the better. All the objects were persistent except ReportTemplateInterface. (Note that the word interface in this use case refers to an application interface and may not imply use of a Java interface construct.)

Three types of users appear in the list: application administrator, trust customer member, and banking support user. When we got to attribution, we recognized that there was another object, User, with different subtypes. Inheritance relationships like this are easier to recognize when it comes time for attribution, so let's leave the object list as it is for now.

An alternative to merely identifying nouns is to do the data-modeling exercise first. All identified entities are good object candidates. Many of the objects we identified in this example would make good entity candidates as well. See chapter 7 for details.

Some of these objects were implemented as classes in multiple software layers in the application. This process is the focus of the next section. Defining and illustrating these layers was described in chapter 5.