Columns

Getting where you want to go with objects

• By Tom McDonough
• June 12, 2001

Object orientation (OO) has vast potential, but it isn't a panacea. Even the best new technologies and paradigms are counterproductive if deliverables aren't easily reusable, deadlines or

budgets aren't met, or the desired functionality isn't present. But if you understand the OO life cycle, you can adopt a best-practice development process that will minimize your risk of failure.

While this may sound easy, consider this:

• There are approximately four "worst practices" for each best practice.
• The process must be made independent of the technology, which nowadays changes in "Web time" (weeks, days or even hours).
• There is always legacy code in real-life systems.
• People, teams and organiations may be bound to legacy orientations.
• Virtually all production systems contain elements from each orientation.

Data-oriented systems (relational databases are an example) emphasize fundamental data entities and their interrelations. In function-oriented systems (most legacy systems), the stress is on functional decomposition or what the system does. OO combines the two.

The OO life cycle

Two principles underlie the OO life cycle. The Product Architecture Principle identifies a product's components. The Lifecycle Traceability Principle shows how business requirements are developed and transformed so that what is needed actually gets translated into code.

Because changes in the technology landscape can turn today's best practices into tomorrow's nightmares, the Product Architecture Principle separates business functionality (what you want to do) from underlying technical constructs (how it is done). In OO terms, classes defining business rules and functionality must not depend upon or reflect those used to implement or deploy the system.

The traceability characteristic allows users to ensure that business requirements are transformed into deliverables completely and consistently. That is, the solution implements end users' needs as expressed through business requirements.

In addition, any successful OO approach will be:

• Use Case-driven -- this means that the business requirements for the project are captured via Use Cases. These Use Cases will be translated into artifacts that can be developed against, while providing the basis for testing and quality assurance.
• Architecturally focused -- applying an architectural focus to the development phases will highlight the division between the project's technical and business architectures, and also help ensure the benefits of traceability.
• Artifact- and asset-based -- an artifact is a tangible deliverable necessary to define a system or expand its functionality. Artifacts are created using the constructs of the Unified Modeling Language (UML). Assets define the nature and functionality of the reusable components, schedules and plans used to communicate with senior management, as well as the functional descriptions that sales or marketing need. Assets also reflect applied best practices, and are a tangible result of an organization's successes.
• Incremental, Iterative and Integrative (I3) -- the I3 approach breaks the software development life cycle into successive progressions so that the project consists of mini life cycles, each of which completely develops some system sub-component. Iterations are further process divisions. How the discrete parts are brought back together is the concept of integrative development.

OO life-cycle phases

There are seven phases in the OO life cycle: Requirements Modeling (RM), Analysis Modeling (AM), Design Modeling (DM), Implementation Modeling (IM), Coding (C), Quality Assurance & Testing (QAT) and Maintenance (M).

Requirements Modeling is the foundation for the entire life cycle. Assets and artifacts developed here will be the basis of later development and will enable traceability.

RM captures users' desired business functionality and the business rules for the system. All RM activities and deliverables are expressed in the semantics of the business user. These elements also serve as the input for quality assurance. The business analyst is responsible for eliciting and documenting requirements from the user.

Conceptual User Interface concepts can also be identified, explored and documented. The most important activity is Use Case Modeling, a complete methodology in and of itself. Other techniques facilitate Use Case Modeling deliverables. These include Concept-Responsibility-Collaboration (CRC) modeling, which is also known as Class-Responsibility-Collaboration modeling. This technique identifies basic business constructs, their primary responsibilities and other business constructs involved in satisfying these responsibilities.

RM has three deliverables:

• The Use Case Model, a set of Use Case diagrams showing actors, uses cases and the relationships among them, with textual descriptions.
• The High-Order Concept Model, generally a result of CRC modeling or Noun-Verb analysis, which formalizes fundamental business concepts and their relationships expressed semantically.
• A set of documents that capture the product's capabilities, those aspects of the business system not implicit in the business rules. These can include performance requirements, timing semantics, and space and memory constraints.

Analysis Modeling applies object orientation to the business model defined in RM. In AM, we translate users' requirements into OO representations using modeling techniques like the UML.

Two key AM functions are traceability and the exploration of business requirements. AM also lays the groundwork for the balance of the development activities that specify, enhance and adapt the model to the realities of the production environment to ensure traceability. Thus, AM must accurately reflect the business constructs defined in the RM. The business representatives are responsible for that validation. To maintain traceability, the development team must not alter the AM fundamentals when specifying, enhancing and adapting it to the production environment.

The primary AM deliverables are diagrams expressed in the OO notation of choice, documenting the static and dynamic perspectives of the system. On the static side, the UML provides Class Diagrams that model the classes and their
relationships, and Package Diagrams that organize and group related functionality.

On the dynamic side, Sequence Diagrams and Collaboration Diagrams capture objects' interactions, or the messages they pass to accomplish specified functionality. Additionally, State Diagrams model transformations of an object of a specific class.

On the static side, the transformation of the High-Order Concept Model (HCM) is relatively straightforward. Most of the Concepts in the HCM are modeled as classes in Class Diagrams. Some may become a simple attribute of some other class.

Design Modeling is applying the Technical Architecture to OO business constructs. While RM and AM address "what" to do, DM addresses "how" to do it.

A Technical Architecture is the complete set of technical constructs needed to implement business rules in a system. They can be divided into hardware/software constructs and philosophical constructs. Some specific elements of these aspects are:

• Hardware/Software Constructs such as User Interface Frameworks (MFC, AWT), implementation languages (Java, C++), distributed middleware (CORBA, DCOM), messaging middleware, persistency and frameworks to implement any or all of the previous.
• Philosophical Constructs such as network topologies (OSI model), distributed architectures (two- and three-tier, peer-to-peer), system topologies and design patterns (State Patterns, Factory Patterns).
• DM is a continuation of the work performed in AM, but with a broader and more detailed scope. The processes and techniques used in DM are varied and wide-ranging, but rest on a fundamental understanding of the domain of the solution.

It is in DM where details of classes,
attributes and methods in an implementation language are specified, and where a specific language, such as Java or C++, is first addressed.

Implementation Modeling addresses the deployment or distributed processing issues of the Technical Architecture.

Modern production business applications use distributed computing architectures to allocate functionality to the most appropriate, powerful and cost-effective processing environment. In general, this means different implementation platforms.

Another key issue IM addresses is integrating OO and non-OO (data- and function-oriented) systems. Three flavors of such systems may need to be reflected:

• New systems developed as part of the current effort.
• Heritage systems that have been previously developed, and whose functionality we are incorporating.
• Legacy systems also previously developed and to be incorporated, but from which we plan to migrate.

Each type of non-OO system has a different implication on our object model. Translating OO concepts into their corresponding non-OO representations can be quite involved and messy. Effective encapsulation, which hides the details, is key to maintaining a meaningful object model.

IM and DM activities and deliverables are very similar. The important distinction is their focus.

As with DM, IM can uncover new support classes. This triggers additional modeling activities from the previous phases. However, IM adds one additional form of documentation. The Deployment View is a UML diagram that lays out the processors of a Technical Architecture, the systems running on those processors, and the communication media that link them.

An additional IM element is identifying object/non-object boundaries and specifying the classes, data and functionality that encapsulate that paradigm boundary.

Coding is the biggest phase of the development cycle in most methodologies and most practical experience. In this approach, however, it becomes one of the smallest life-cycle phases because virtually all of the work to define and expand the functionality in this system has already occurred.

Source code generation and round-trip engineering allow the development of a consistent model and code base. The model becomes another form of coding and the code simply a different representation of the model. By maintaining this integration, we establish the last link in traceability from Requirements Analysis through Quality Assurance & Testing.

Again, new classes may be discovered in the Coding process. This means further modeling activities. It is imperative that
developers understand that they shouldn't explore these new classes in the code, but allow them to be modeled first.

Quality Assurance & Testing verifies technical and business functionality.
As the life cycle's components differ, so
do their validation and verification. The goals are the same, but the verification
focus is different.

Finally, Maintenance in the OO approach simply reapplies the life cycle. Its primary concern is identifying when modification and enhancement requests suggest another development effort. The best course is to map those requests to Use Cases, and to assess the implied level of effort.