Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
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.
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
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.