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.