This chapter is from the book
This chapter is from the book
This chapter is from the book
The term methodology is one of those terms that can mean different things to many people. In the context of developing software, however, there should be one simple interpretation—"A Methodology provides a methodical roadmap, framework, or guidance for developing software solutions derived from business needs."
The term Software Development Lifecycle (SDLC) sometimes gets confused with a methodology. The two terms are interrelated, but have different implications. A Software Development Lifecycle describes a defined set of phases or events that occur in the development of software solutions, as illustrated in Figure 2.1.
){kind=small}
Figure
2.1 The Software Development Lifecycle has several distinct phases.
A methodology, as illustrated in Figure 2.2, encapsulates an SDLC, and describes a general philosophy for developing the software solution, as well as what is expected from each of its phases in terms of inputs, outputs, and the respective coordination of any activities.
Methodologies are not technology-bound, and in essence, they cannot afford to be. Methodologies are engineered to be open frameworks that can apply to a variety of business and technical challenges. However, with the explosion of Web-based n-tiered applications, as represented by the BEA WebLogic Server 7.0 united with the J2EE platform, methodologies have become driven by the following three factors:
Features or functionality of your system solution
Web-based interface
Architecture that will be used in the construction of your system solution
){kind=small}
Figure
2.2 The methodology with respect to a SDLC describes a general philosophy
for developing a software solution.
These methodology drivers will be discussed in more detail in the "Selecting a Software Development Methodology" section of this chapter. In the meantime, it is important for you to begin to relate to these factors, as this chapter systematically describes the development process of J2EE solutions.
The methodology spectrum can range from pure philosophies, or best practices on what is needed in each phase of the SDLC, to a fully specified roadmap, providing complete guidance on the whys, whats, and hows of developing software solutions.
There is no rule or guiding authority that specifies you have to use a particular methodology. However, working without rules or guidance can be a costly exercise. The merits of using existing methodologies generally include the following:
Proven and successful methodologies are available to be used, and thus you do not need to reinvent the wheel
Optimism that the requirements of the solutions have been captured correctly
Reduced risk and errors in the development and deployment of the software solution
Improved documentation and communication during the SDLC
Easier project management
Straightforward maintenance and upgrade of the deployed (production) software
However, the true realization of benefits depends on the methodology you have selected, and how it is implemented and executed within your organization.
There is no doubt that J2EE solutions are being developed through a catalog of methodologies, each providing a unique approach. However, if you take a closer look at the methodologies at a very high level, there are certain core activities or phases that span them all; the only disparity is that they are fine-tuned or enhanced in their exact implementation and how they are practiced.
Methodology types have evolved from the early Structured Systems and Analysis type methodologies to Object-Oriented type methodologies, which are more gauged to develop object- and component-based software. Structured methodologies do not support the concept of looking at the real world in terms of objects. Object-Oriented type methodologies are more appropriate for developing J2EE solutions.
What Is an Object-Oriented (OO) Methodology?
An Object-Oriented (OO) methodology is in essence a strategy for observing the business world as a suite of objects (for example: people, desks, pens, computers), and deriving an object-oriented software system from it. This is accomplished by mapping real-world objects to software business objects, which are written in an object-oriented programming language such as Java, C++, and now C#.
NOTE
J2EE is not a language—Java is the implementation language for the J2EE services.
The primary difference between Structured and OO methodologies is in their underlying concepts. Instead of defining systems as two disparate parts—data and functionality—OO methodologies require systems to be defined as a collection of interacting objects. These objects possess characteristics (data) and behavior (functionality), which are mapped from the real world to Java classes or J2EE objects, such as EJBs and Beans.
Major Motivations for Using OO Methodologies in J2EE System Developments
The methodology you use to construct your J2EE system needs to be addressed very early on, before the project begins, as it affects every aspect of your system development effort. Depending on the culture and skill sets of your project staff, either you can embrace a complete OO approach, including the tools you use, or you can embrace a mixed-bag approach using structured approaches for certain phases of the SDLC; for example, for the Requirements phase. Even though a complete OO approach is favored and more conducive toward J2EE systems development, a decision will need to be made on which approach will yield a more successful return for your project, and not what the industry beckons.
CAUTION
Best practices are not always the most practical practices if they do not provide any benefits to your organization or are too challenging to implement, thus causing resistance to their use.
The following sections illustrate a few influential points you should consider if you are in the position to decide whether you should use the OO or mixed bag approach.
Object-Oriented Approaches Produce Solutions Which Closely Resemble Their Problem Domains
One of the axioms of systems development is that a solution should closely resemble the original problem. The only way to do this is if you observe your problem domain in its natural state, which is in terms of objects interacting with each other.
If you take this natural perspective, you will better understand your requirements, and more importantly be able to easily refer back to your problem domain to validate the Analysis and Design phases of the SDLC.
Object-Oriented Approaches Promote OO Thinking
There is no better way to understand the object-oriented paradigm than to be involved in a project that encourages and practices it. Software developers and architects who are already familiar with one of the OO programming languages will be familiar with the concepts. If you are a project manager or business analyst, there are plenty of books that discuss OO concepts and even provide case studies, but the true test is if you live the experience, because things are never what they seem.
For those who are new to OO, the following are key OO areas that will assist you to further understand the OO paradigm.
Objects and Components Are "Black Boxes"
The "black box" concept means that implementation details of objects and components are hidden from their consumers. This concept is formally known as information hiding and is a key element in OO thinking.
You should not worry if you do not understand how an object or component is implemented in your J2EE solution. The main emphasis should be that you understand its purpose: What functionally does it provide and what data does it possess?
Objects and components are seen as black boxes because they are designed with the concepts of abstraction, encapsulation, and concurrency.
Abstraction Abstraction is the process of suppressing or ignoring inessential details, while at the same time putting focus on the more important or essential details. Abstraction is typically spoken of in terms of levels, the higher levels addressing why the object exists, and the lower levels leaning more to how it is implemented. There are many types of abstraction, but in terms of objects, the following are important:
Functional abstraction, which deals with hiding the functionality within an object, while only exposing the interfaces on how you can interact with it.
Data abstraction, which hides the details on how an object's functions and data are implemented.
Process abstraction, which manages internal processing of operations.
Encapsulation Encapsulation is the process of logically or physically wrapping together functionality and data that pertains to a unit, business need, or concept into a class or component; that is, information hiding.
This concept acts as a software wall or protector, allowing interaction only via specified interfaces; the internals being hidden. Hence, if a change needs to be made to the data or functionality within a class or component, it can take place without cascading changes to the other parts of the system that interact with it.
Concurrency The biggest difference between OO and procedural systems is how they manage concurrency—the capability to process an operation.
Non-OO systems will tend to create a broker object or central routine that will take the responsibility of managing how other aspects of the system receive processing requests. OO systems, on the other hand, will tend to leave this process management to the object itself or the environment that object exists within. For example, in the case of EJBs, concurrency is managed by the EJB container.
Object-Oriented Approaches Promote Reusability
Reusability does not only apply to the concepts of class inheritance or component reuse, which without a doubt are the primary beneficiaries in an OO software development effort. Since OO approaches focus on delivering OO systems without a bias on the implementation language, the whole software development lifecycle and the artifacts can be reused on other projects.
TIP
As in the case of J2EE systems, non-technical aspects of a system development effort, such as templates for Requirements, Analysis, and Design artifacts; application development tools; and even project plans; can be used as springboards for subsequent J2EE projects to use.
Object-Oriented Approaches Support Interoperability
OO systems, such as in the case of J2EE, are not designed to be monolithic self-satisfying systems. OO methodologies promote systems to be loosely coupled, but very cohesively designed. Even though J2EE systems can be dispersed throughout an organization regardless of the location (for example, hosted on WebLogic Servers), as interoperability increases, the concept of a network and any system interconnections slowly begin to disappear.
Object-Oriented Approaches Possess Traceability Capabilities
When you are developing a system, requirements play a key role in every aspect, from the development through to deployment efforts. By reviewing the deployed system, it can become be very difficult to reverse-engineer a production feature to its root source.
The term traceability defines the degree of ease with which a concept, idea, or feature item may be traced from one point in a SDLC to either a succeeding or a preceding point in the same SDLC. For example, you may want to verify how a specific requirement actually becomes implemented, or trace how a feature actually was implemented in the production release of your software.
OO software development is a very illustrative process, as opposed being textual. Depending on the OO methodology you select, you will need to develop models to illustrate the real world as it exists, how you want the real world to behave in the software solution, and lastly, how the solution will translate to object-oriented source code in Java using the J2EE architecture.
The Challenges of Using OO Methodologies—"Object Blindness"
Object blindness is a technical term for those involved in OO software projects who fail to recognize the concept of an object, and thus are not able to think in the OO paradigm. The failure again arises from lack of either exposure to OO-type projects or technical education.
In the past, universities and other educational institutes had been slow to introduce OO into their curriculum. Also, OO software projects were less frequently initiated by organizations. For these reasons, there are many people in the computing industry with object blindness. This is slowly changing with better educational curriculums and the speed at which Java and Web-based applications are being developed with Java and J2EE architectures.
Object blindness has contributed toward the poor adoption of OO methodologies in the past. However, today object blindness is one of the many reasons that explain the challenges that OO methodologies must overcome, which are discussed in the following touchpoints:
The software development tools used within OO projects are still centered on structured methodologies—data and functionality (process). The solution is simple: If you are going to develop objects, use tools that are object-oriented. The benefit is huge.
Mixed methodologies do not provide a consistent OO perspective to the J2EE software development effort. For example, if you execute the Analysis and Design phases in a structured manner, your software developers will use the Java language and the J2EE architectures poorly. Thus, they will render a system that is not scalable, suffers from performance bottlenecks, and which may not even behave in an OO manner.
There is a stigma that OO methodologies will add complexities to an already challenging project. Such perception typically originates from a lack of understanding of OO techniques, and can hence close any opportunities for using OO methodologies.
With J2EE projects typically having a fast time-to-market stigma around them, not enough investment is being made to prepare for J2EE projects. With lack of training and know-how, J2EE projects will take considerably longer than originally anticipated.
Most J2EE projects are composed of a small number of developers who prefer informal development approaches that they have been exposed to in their past experiences. Hence, any formal methodology that requires documentation is considered overhead.
Project staff who are in the process of developing J2EE systems for the first time tend to apply methodologies composed of unrelated technologies that have worked for them in previous projects. As a result, the only way for them to realize that an OO methodology is required is by experiencing failure and learning from it.
Many Java developers do not understand the J2EE architecture, and thus it is inappropriately used and implemented.
Business analysts do not understand the OO modeling technique using the Unified Modeling Language (UML), which does have a learning curve. Consequently, the design of the system may be good, but it will fit a poorly analyzed system.
NOTE
UML will be discussed in detail in Chapter 3, "A Developer's Guide to the Unified Modeling Language (UML)."
The benefits or Return of Investment (ROI) from using an OO methodology is not apparent immediately, as expected by most organizations. Object reuse typically becomes an attractive proposition after a few J2EE projects have been implemented.
The Traditional Waterfall Methodology
It is true that Waterfall and Object-Oriented type methodologies are being used to develop J2EE solutions in organizations today. Some organizations may even place a wrapper around the waterfall methodology, by renaming it or adding some overlap in some of the phases. However, in essence, it remains a waterfall methodology and it is still prone to the failures associated with it when developing J2EE solutions.
In order to understand object-oriented methodologies, this section will also discuss the Waterfall Methodology and the associated reasons as to why you should not use it to develop J2EE solutions.
The traditional Waterfall Methodology is an early software development methodology created by Dr. Winston Royce, who described the methodical and sequential phases for developing software solutions. As you can see in Figure 2.3, this methodology resembles a waterfall for one main reason—each phase must be complete by a specified date before entering into the next. With the forces of gravity acting on each of the phases, the Waterfall methodology in practice does not encourage revisiting any previous phase once it is deemed complete.
)
Figure
2.3 The traditional Waterfall Methodology does not encourage the revisiting
of any phase once it has been passed through.
The Waterfall Methodology suffers from two major problems that can cause the quality and schedules related to software development to be adversely affected:
There are no feedback mechanisms between each phase.
There are completion dates imposed on each phase of the software development lifecycle.
Each of these failures will be discussed in the following sections.
Feedback Failure Between the Phases
The most important phases of a software development lifecycle, where you develop the building blocks of your system, are the Requirements, Analysis, and Design phases. Since there are no feedback mechanisms between the phases, Requirements must be complete before Analysis can begin, which will need to be completed before Design can begin, which will need to be completed before Development can begin, and so on.
So why does this methodology fail? It is because these activities cannot be measured complete purely by a scheduled end date; an organization itself, as well as its needs, change over time. Since this type of methodology was not engineered to have a short lifecycle, there is no way to feed in any changes to the software development effort that will be needed to deliver a successful information system.
Even though the software is delivered, the duration it takes from inception to final delivery is huge. Typically, by the time a system is deployed it will not fully meet the needs of its initial customers, since
The customer needs may have changed over time, which is known as requirements drift.
The system does not function in a manner that truly represents the real-world flow of business operations.
The system is not intuitive to use, thus facing resistance to its adoption.
CAUTION
Raise the flag if you are in a project that does not allow the Requirements, Analysis, and Design to provide each other feedback. Such projects are prone to failure.
Requirements, Analysis, and Design Milestones
When following the Waterfall methodology, project managers tend to impose end dates to the Requirements, Analysis, Design, and Development phases. This is an unfavorable situation because the phases are tightly coupled processes during the development of object- and component-based systems.
Practicing a linear model does not encourage creativity or flair to add value to the underlying system being built among the project staff. Business analysts, architects, and developers need the freedom to discover and rediscover what they are building through continuously revisiting their dependent phases. Establishing sequential end dates will cause these phases to be executed independently of each other. Such projects, also known as stove-piped projects, have one common failure within them: They always deliver a dysfunctional or out-of-date system from the perspective of the customer.