Home > Articles > Programming > Java

  • Print
  • + Share This
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.

Figure 2.1Figure 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

Figure 2.2Figure 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.3Figure 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.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020