The iteration after overall planning is concerned with demonstrating feasibility through prototypes and experiments. In particular, the application (re)engineering decision made in planning (i.e., what needs to be built from scratch and what needs to be reused/restructured) is revised, if needed, based on the additional insights. In this iteration, the four generic activities of analysis, architectures, implementation, and deployment/support are repeated with particular emphasis on hands-on discovery instead of endless paper and pencil analysis. Although the details of this iteration depend on what is being engineered or reengineered, we adopt an OO view as an overall framework for discussion. In particular, the object life cycle shown in Table 3.4 serves as a general approach that we will customize as we go along. The basic idea is to develop and use an object model in this iteration and then refine and expand it in later iterations as production systems are built.

Why the emphasis on OO so early in life cycle? The main reason is that an early adoption of OO concepts leads to increased reuse, which in turn results in improved productivity and rapid deployment/re-deployment of applications as the business changes. Extensive data on productivity have been gathered by Capers Jones of Software Productivity Research, Inc. Analysis of over 5,000 products by Capers indicates the following [Sutherland 1994]:

This section assumes that the reader has a very basic understanding of OO concepts. The short tutorial on OO concepts at the end of Chapter 2 (Appendix 2A) will get you started. The discussion here is intentionally brief since a large body of literature is readily available on this topic [Booch 1994], [Rumbaugh 1994], [Jacobson 1992], and [Nerson 1995]. The focus is on the underlying principles and not on diagramming techniques (e.g., Booch’s diagrams). Once the principles are established, the reader may employ any diagramming technique and associated tools.

Table 3.4 Object Life-Cycle Checklist

The generic object life cycle shown in Table 3.4 is a good starting point.

The objective of OO analysis is to capture the key requirements and then translate these requirements into an object class model and a system dynamic model. Development of the object class model, discussed in Section 3.4.2.2, is at the core of the OO analysis and design approaches and is vital to application (re)engineering. The system dynamic model, reviewed in Section 3.4.2.3, is useful in most types of applications (see Section 3.4.3.1).

Object-oriented architecture/design casts the results of the OO analysis into a specification that can be implemented. This activity consists of translating object and system dynamics models into modules, allocation of modules to processors, specification of interprocess communications, and pseudo-code and database design. You exit this activity when you have enough details for implementations. Most of the current OO approaches assume development of software for a single machine (i.e., distributed objects are not considered). Due to this reason, we will need to extend and modify this activity considerably for distributed applications (see Sections 3.4.3.1 and 3.4.3.2).

Object-oriented implementation involves developing and testing user interfaces, programming logic, and databases. Typically, OO programming languages are used to implement features such as classes, inheritance, polymorphism, methods, and messages. The implemented system may use OO user interfaces (i.e., view systems as objects, present operations on objects) and OO databases (i.e., store objects in databases, perform operations on objects in databases).

Figure 3.9 shows how the OO analysis interrelates with overall planning and architecture/implementation. We discuss the shaded blocks in the next two sections within the context of second iteration (i.e., prototyping/experimentation).

Figure 3.9 OO Analysis

Specification of these requirements somewhat depends on the nature of applications being engineered/reengineered.We will discuss this topic in Part II and Part III of this book.

An object model represents the functional requirements of a system in terms of objects and classes in a tool and implementation independent fashion. The object model is developed by using the following activities:

Consistent and complete notation is needed for representation of knowledge and communication of knowledge gained about the object model. Many CASE (computer aided software engineering) tools are based on notations to generate code. Notations should allow different views to be represented such as logical models, physical models, static semantics, and dynamic semantics. Common notations used in OO analysis and design are due to Booch and Rumbaugh, among others. Although we do not recommend any specific notation (you can choose a notation of your choice), we will use Booch’s notation for illustration (see Figure 3.10).

Figure 3.10 Notation Used in OO Analysis (Booch)

Step 1: Identify Object Classes

Development of object classes, commonly known as classes, is at the core of OO analysis and design. Basically, a class is a template that represents the properties that are common among similar objects. For example, the class customer can be used to represent the common properties of all customers. The common properties include attributes such as name, address, customer id, et cetera and methods such as add, update, query, and the like. The relationship between an object and a class is straightforward–an object is an instance of a class. For example, if Buick is a class then all Buick cars can be viewed as objects (i.e., instances) of the class Buick. Due to this relationship, many people do not differentiate between objects and classes in this stage of analysis, because either way you are specifying the core components of the object model. To avoid confusion, the term object class is used sometimes to represent an object or a class (we will use the term class, because it is more commonly used).

How do you identify classes? Classes can represent real-world things such as a person, a building, a laptop computer, or a text editor. It can also represent concepts such as schedules, pay scales, or algorithms. We strongly recommend to start with objects that represent business entities and not with programming objects such as GUI interfaces, stacks, queues, buttons, and the like (see the sidebar "Business Objects: The Key to Reuse"). Here are some guidelines (see Fingar [1996], Baster [1997], and Gale [1997]):

For database designers, the process of identifying classes is very similar to identifying the entities in an entity-relationship data model.

Figure 3.11 shows the classes identified in a customer information system in which customers buy a variety of products such as TVs, radios, and their parts. We will expand this example as we go along.

Figure 3.11 Customer Information Object Model–Classes

Identification of classes in large scale problems is an extensive undertaking (you can easily come up with hundreds of classes). Most methodologies for identifying object classes utilize English descriptions (nouns are classes/objects) and "use-cases" that exercise various scenarios. Many start with domain analysis, that is, rely on domain experts to help in identifying the classes and their behaviors. The domain analysis procedure for identifying classes starts with abstracting the things that are used in the domain and proceeds to representations of real-world objects such as an employee, machine, product, facility, or an organizational unit (e.g., a department). In addition, groups of users can be modeled as an object class. You may use the following guidelines:

The output produced by this step is a list of classes that may be stored in a dictionary for later use. Additional details to these classes will be added later. We will see later that once you have identified a class, then you can easily translate it into code and can create any number of instances (objects) of each class (object-oriented programming languages provide statements to define classes and create objects).

Step 2: Specify Relationships (Associations) between Object Classes

Relationships, also known as associations, between object classes show how the objects of an application collaborate with each other to satisfy user needs. Interacting objects collectively describes behavior of a system. Basically, any dependency between two or more object classes is an association. For example, the dependency between an employee and a company is an association (the works-for association) and the dependency between a customer and a product is also an association (the purchasing association). Associations between objects can be one-to-one, one-to-many, and many-to-many.

As we will see in a moment, associations can be of different types. In the first iteration of building an object model, it is enough to identify associations without categorizing the association types. However, in later stages of an object model, the following types of associations (relationships) play a key role:

A use relationship between two object classes indicates that the two classes collaborate by sending messages to each other. For example, the statement "sales clerk updates a customer account" shown in Figure 3.12, indicates three pieces of information: (1) the salesclerk class uses the customer account class, (2) an "update" operation is supported by the customer class, and (3) an "update" message is sent from the salesclerk class to the customer account class. Notice the use of notation in this example.

Use relationships focus on the dynamic behavior of classes and objects. By collecting all the use relations to and from an object, you will have a good idea about behavior of the object and the system requirements. Given a collection of objects involved in use relationships, each object may play one of three roles:

Figure 3.12 A Simple Using Relationship

The container relationship, also known as parent/child relationship, represents subparts of an object class. For example, container relationships exist between a car and the car engine, wheels, seats, and the like. Container relationships are very useful in reducing the number of objects that are visible in a system. For example, if an application does not need it, all parts of a car can be contained in a car class. Thus, the details of car parts are encapsulated in the car class. However, container relationships do lead, if needed, to coupling between objects that cannot be distributed among machines.

The inheritance relationships, an important part of an object model, represent the common properties (attributes, operations) between classes. For example, all cars have some common properties. The notion of inheritance is borrowed from an artificial intelligence "ISA" relationship. For example, "Sun ISA computer" represents that the common properties of a computer are inherited by a Sun workstation. In some cases, only a subset of properties is inherited. This can be represented through "a kind of (AKO)" relationship. For example, "computer is a kind of electronic machine" shows that computer only inherits a small number of electronic machine properties. A class hierarchy can be constructed where lower level classes (subclasses) inherit the properties from higher-level classes (superclasses). For example, we can set up a class hierarchy for an employee class with subclasses such as managers, technical support, administrative support, consultants, visiting residents, and part-time staff.

Figure 3.13 shows a refinement of the customer information object model we introduced earlier. We have basically added use and container relationships between the classes and also have added a class "product" from which the TV and radio classes can inherit properties.

The main activities involved in developing the associations are as follows:

Figure 3.13 Customer Information Object Model–Relationships

Step 3: Identify Attributes and Operations

Attributes are properties of individual objects, such as name, age, weight, height, or color. Attributes should not be used for associations (e.g., do not use product-purchased as an attribute of a customer; use it as an association between a customer class and a product class). It is important to identify only those attributes that are important for the problem domain (i.e., use abstraction principles). For example, if you are designing an airline reservation system, then you only need to define a very few attributes of each city (e.g., number of airports, distance to the main city, etc.). However, if you are designing a travel guide, then many more attributes of each city are needed.

An operation is an activity performed by or on an object. The operations performed on each object are listed as a starting point. In addition, the information associated with each operation (inputs needed, outputs generated, preceding and/or subsequent activities, sequence restrictions) is specified. You should also list security restrictions associated with the operations being defined. The following guidelines can be used:

Figure 3.14 illustrates the results of identifying attributes and operations for the simple customer information system we have been reviewing. We have shown an object (customer), four operations performed on this object, and the input/output of each operation. We have not specified any pre- and postconditions and any other sequencing information that could have been identified here. A method is a set of software instructions that is invoked when an operation is invoked. Thus the customer object must provide four methods (software instructions) that are invoked when operations such as add a customer, view a customer, update customer information, and delete a customer are invoked. The information produced as a result of this step can be represented by any of your favorite representation tools (text, formal languages, graphical tools, Booch diagrams, etc.).

Figure 3.14 An Example of Object Operations

Figure 3.15 shows the customer information object model with attributes and operations identified. Recall that the notation we are using identifies class names with underlines, operations with "()" and attributes just as items. We have only identified a few key attributes and operations.

Figure 3.15 represents a complete object model–it shows the classes, the relationships between classes, the attributes, and the operations. This object model can be easily translated to code by using OO programming languages (we will see this later).

Interface of an object is the collection of operations and their signatures (signature of an operation defines the operation’s name, its arguments, and argument types). For example, the following statements could be used to specify the interface for a customer object that supports two operations: create customer and view customer (the language is illustrative):

The interface specification at first attempt can be at a high level by omitting some of the information about argument types.

One or more interfaces may be defined for an object. Interfaces are essentially declarations of how an object can be used by other objects. Although interfaces are defined for most object models, interface definitions have become an essential aspect of distributed object applications. This is because distributed objects can reside on different machines with different character and numeric representations. Interface definition languages (IDLs) are provided by middleware (e.g., OSF DCE IDL and CORBA IDL) for defining interfaces formally. The interface definitions are compiled by using vendor-provided IDL compilers and can be stored in an Interface Repository for other objects to utilize. We will discuss IDLs in more detail in Chapter 7. In addition, modern OO languages such as Java provide constructs for interface specifications.

Figure 3.15 Customer Information Object Model–Attributes and Operations

We should note that interface specifications are not typically considered as part of developing an object model at the time of this writing. However, as distributed objects become more popular, the notion of interface specification will become an important aspect of developing the object model. In essence, interface specification formally describes certain aspects of the requirements of a system and should be considered as part of formal requirement specification–an area of considerable research activity in software engineering [Finkelstein 1996], [Ramamoorthy 1996], [Ng 1990], [Nicol 1993], and [Pankaj 1991].

Dynamic behavior of objects deals with issues such as synchronization of messages and event notification. The objects involved in using relationships must synchronize the messages. Synchronization is essential for the server object that may need to manage multiple threads of control. In general, objects can interact with each other in two manners:

Synchronous communication may be sufficient for many real-life systems. In addition, many middleware packages only support synchronous communications (e.g., DCE RPC is strictly synchronous). However, it may be desirable to exploit asynchronous interactions for some applications. Asynchronous communications require more effort by programmer’s because code must be provided to handle unscheduled events. Asynchronous interactions can be achieved by generating (local) concurrent synchronous interactions. For example, a client can initiate three "threads" for three synchronous interactions and thus achieve desirable parallelism.

Event handling is a crucial aspect of object-oriented applications. Most GUI applications are event-driven, that is, they must respond to a large number of mouse clicks, window activations, function keys, key strokes, timers, and various other scheduled as well as unscheduled events. In particular, multimedia applications are intensely event-driven with events from remote control, voice input, and mouse [Rosenberg 1995]. It is essential that a comprehensive event model be specified. A wide variety of techniques can be used to specify and analyze events (e.g., directed graphs, message sequence charts, timing diagrams, Petri nets, discrete event simulations). Details about these techniques can be found elsewhere [Booch 1994], [Rumbaugh 1994], and [Rosenberg 1995].

The object model and other information gathered during OO analysis is used to develop architectures and build prototypes of new applications and experiment with restructuring of existing applications. The knowledge and experience gained is used to refine the object model and build production systems.

There is no "one-size-fits-all" approach for prototyping all new applications in the modern environments. For example, decision support applications mainly require a database design with almost no software development. These applications rely heavily on off-the-shelf query and browse tools and use the object model to design the database. (We will see later that the object model is very similar to the data model that is typically developed by the database designers.) There is virtually no reason to develop a system dynamics model for decision support applications (most activities are queries). On the other hand, enterprisewide mission- critical operational support applications may require extensive software development and may require, in addition to the object model, a great deal of information about the system dynamics and flow. The real-time applications rely, for obvious reasons, on a very extensive system dynamics model.

Figure 3.16 suggests the main activities in prototyping different classes of applications. The rows of this table show the four generic activities (analysis, architecture, implementation, deployment) and the columns represent the three broad application categories (i.e., decision support, operational support, and real time). We introduced these application categories in Chapter 1 and discussed them in terms of span (i.e., departmental, enterprisewide, interenterprise).

You can extend this discussion to other cases that require mixtures of the cases discussed here (e.g., applications that are operational support at corporate level but provide decision support capabilities at the departmental/group level) for these classes of applications. We will explain the entries in this table in Chapter 4.

The object model and other information gathered during OO analysis can be used to experiment with (re)engineering of a wide range of existing applications, including legacy. The exact activities depend on the type of reengineering strategy chosen. For example, access and integration of legacy applications requires selection of appropriate surround technologies that "wrap" the legacy functions and data ("object wrappers" are increasingly being used for this purpose at present). In this case, the object model can be used to represent various legacy functions and data as object classes. Data warehouses, a popular approach to deal with legacy systems, are decision support applications that require database design and data warehouse tools. Design of data warehouses uses the object model to represent the database design as discussed previously in decision support applications. For migration, the object model can be used to encapsulate the application components that will be transitioned, thus making the migration transparent to the users (see [Desfrey 1996] for a case study).

Figure 3.16 New Application Prototyping Activities

Figure 3.17 suggests the main activities for different application reengineering "experiments." The rows of this table show the four generic activities (analysis, architecture, implementation, deployment) and the columns represent the three main application reengineering strategies (access/integration, data warehouses, migration). We will explain the entries in this table in Part III of the book in the chapters on access and integration, data warehouses, and migration, respectively.

Figure 3.17 Application Reengineering Activities