Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Step into the J2EE architecture and process

Develop complete J2EE solutions with an eight-step cycle

By Jian Zhong, JavaWorld.com, 09/28/01

In the commercial world, we use Java 2 Enterprise Edition (J2EE) to solve business problems, to develop commercial software, or to provide contract services to other businesses' projects. If a company wants to build an e-business Website using a multitiered architecture, it usually involves managers, architects, designers, programmers, testers, and database experts throughout the development lifecycle.

For different parties to work efficiently and effectively, they often need a software development process. Some classic development processes include the waterfall model, rapid application development (RAD), and extreme programming. In this article, we will focus on a popular software engineering process, the Rational Unified Process (RUP). RUP provides a disciplined approach to assigning tasks and responsibilities to different roles. Its goal ensures we produce high-quality software that meets user needs within a predictable schedule and budget.

I like to use RUP for J2EE development for three reasons. First, RUP is architecture-centric; it develops an executable architecture prototype before committing resources for full-scale development. Second, RUP is iterative and component-based. The architecture baseline often includes a framework or infrastructure to facilitate adding components through iterations to customize and extend a system's functionality without affecting the rest of the system. Third, RUP employs an industry-standard language, UML, to visually model a system's architecture and components. RUP has four different development phases: inception, elaboration, construction, and transition. This article, however, covers eight essential activities involved in J2EE development from a technical perspective in a manner that maintains the architectural focus.

I. Requirements analysis

The requirements analysis describes what the system should or should not do so that developers and customers can create an initial business contract. You can document functional requirements in business concepts, domain glossaries, use cases, and user interface (UI) mockups. Nonfunctional requirements, such as performance and transactions, you specify in a supplementary requirements document. You can create the high-level UI mockup on paper or in HTML, depending on how deeply you are involved in the project.

Figure 1 shows two sample use cases of a typical e-business system. The viewOrder use case tells us that a user logs into a system through a Web interface, sees an order list, and clicks a link to view order details of a specific purchase order. The addLineItems use case tells us that the user browses a product catalog, selects interesting products, and adds them to a purchase order.

Figure 1. Order use cases

II. Object-oriented analysis

Analysts generate problem domain models: classes, objects, and interactions. Your analysis should be free from any technical or implementation details and should contain an ideal model. Object analysis helps you understand the problem and acquire knowledge about the problem domain. You must maintain a pure domain model without technical details because a business process changes much more slowly than information technologies.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.