Use Rational Tools to simplify the architecture and design of J2EE-based projects (5)

Part 1: architecture and design

Steven Franklin
Software designers and Process experts
April 2004

When this ongoing J2EE sample project using the rational and other rational tools is transformed from a use case to an architecture and design (including data modeling and building a testing design hypothetical prototype ), this project has entered a more technical stage.
Part 1 of this series first checks the project time and progress, and then when we enter the architecture, design, data modeling, and prototyping, we are already refining the process in the next phase.

Part 1 snapshots

The tools and technologies demonstrated in part 1 are as follows: Rational Rose Enterprise EditionUsed to create a design model (including using rose data modeler for Data Modeling) Rational requisitepro-Added or refined requirements. Products generated or updated: Rational Rose)-Added the architecture and design information (including the database Plan (schema )) Requisitepro Database-Updated to add or refine architecture-based and design-based exploration needs

Project Progress

Before proceeding to the detailed architecture and design, let's check the overall progress of the ASDI project. Just like you canPart 1In retrospect, this series consists of multiple partsArticleCovering 1st phases of the project: with a series of requirements, a reference architecture andCode(Ideal reusable) is the validation of the results concept. So far, we have used about 1st of the budget for the entire 1/3 phase, but we are close to half of the project schedule. This is what we expected, because we intentionally slowed down the progress. Analysis and planning activities are always moving slowly, and teams should gradually build them at the beginning of the project.

Because Stage 1 requires evidence of a relevant structured and formal concept, we treat it as a small project, through testing and QA (peer review) on evolving products) to complete it. RUP has mechanisms for developing conceptual evidence, which are basically involved in the synthesis of the execution architecture of analysis and design workflows. We are further converting conceptual evidence into available beta products. We can put more functions, lower risks and product maturity into this stage. The more we use skills and knowledge in the product version of the system, our customers will be happier.

This subsequent series of tasks will be more technical than the previous activities. We are working on a good architecture. Design, data modeling, and prototype advances. InPart 1We have discussed some prototype and evaluation methods for selecting our tools; now our prototype focuses on testing the needs, system descriptions, and design of our ideas.

Transition to architecture and design

Architecture and design activities are the most pleasant and creative task in the ASDI project. We are proud of the efficiency, security, simplicity, and elegance of our system plans. The vision of the technical solution was finally formed during several exciting meetings, free discussions, and technical explorations.

To put it simply, the architecture is intended to capture technically flexible solutions that cover the system requirements we defined last month. The architecture team is under great pressure whether it is looking forward (for design) or backward (for demand. The integrated development environment of Rational Rose simplifies this challenge by allowing us to do the following:

• Using soda to generate documents to allow distribution of architecture and design elements simplifies inspection and keeps everyone consistent with the current vision.
• Directly update the class signature (methods and attributes) from the scenario, so that we do not have to go back to the class description to add the missing method.
• Generate rosescripts for automated tasks, such as generating the skeleton of the class, checking the naming conventions of the model, and testing the integrity and effectiveness of the model (which can be obtained through accessing the Tools menu ).
• Use Rose's RUP template to provide a model framework with the RUP guide.
• Drag a class from the provided J2EE framework in Rose.
• The "unit control" feature of Rose splits the model into fragments that can be used by the team for version control and parallel work.

Note that because the system we created in past projects is similar to the current system, our architecture will benefit from Referencing some reference architectures. However, we cannot find any reusable opportunities in existing packages or design patterns, so we just reference ideas and classes that may be used in the future in existing systems.

Conversion from use cases to design classes
The conversion from use cases to design classes is slow and requires multiple iterations. This involves analysts and designers, because we have very few people who can discuss business areas with customers comfortably and use specific tools to analyze and refine design products.

Objectives of this activity

Sometimes it is tempting to directly convert requests into code. In fact, we did this in our previous projects (because we have very detailed requirements), and we are very confident in our understanding of the project. In this way, an error occurs. Demands are missing, scope is difficult to track, and a large amount of work and rework are useless. It is important to use design models to connect the gaps between requirements and code. design models can capture errors and problematic assumptions long before development and testing.

In the process of converting from use cases to design classes, we hope to achieve the following:

• Pass on the knowledge of the analysis team to the engineering team.
• Identify the technical solutions that can meet all the requirements-or, where it is not possible, identify the requirements that conflict with the technical solutions, and determine whether they are important, changed, or deleted.
• Identifies the interfaces that can help determine the team structure, architecture level, and candidates for purchasing software.
• Specify technical solution details and start planning how to allocate work to the team.
• Plans and budgets are estimated based on the detailed time of the design model.
• Allocate classes to platforms, products, and private code.
• Generates Software Architecture documents for feedback and synchronization purposes. Software Architecture documents can be distributed to internal and external team members.

Stable Design

The conversion from use cases and analysis classes to design and design classes is inevitable. We need to do a lot of work before we can have a design that we are satisfied. Figure 1 shows the main activities of defining a stable design in our way.

Figure 1:Conversion from case model to design model

The previous article discussed most of the activities and products (especially sow requirements, use cases, business object models, and analysis classes) prepared as "architecture" in Figure 1 ). In addition, these other activities are also important to the design:

• Determine the Package Structure
• Modeling data (Creating Database plans)
• Create prototype and screen Simulation

These will be discussed in the following sections together with how to handle new and changing needs.

Packaging and subsystem structure

Before considering the design class, the entire team should reach an agreement on a good package structure. No matter what our final decision is, it should be a guideline in the design process, and all team members should follow this guideline.

Package Structure Selection
We have been arguing whether to divide packets by subsystem (Figure 2) or by architectural hierarchy (Figure 3 ). Table 1 lists the disadvantages of each method.

Figure 2:Package defined by Subsystem

Figure 3:Package division by architecture hierarchy

Method	Advantages	Disadvantages
Package defined by Subsystem	It simplifies model management. A complex subsystem can use a single*. CatFile or*. CatThe file layers are allocated to large teams. Dependencies between subsystems can be easily tested. It simplifies the project increment plan. It encourages the reduction of subsystems to make the architecture easier to understand. It increases the possibility of sub-system reuse.	The consistency and shared relationship between subsystems will be more difficult to coordinate. For example, DBA may have to work harder to understand the data layer blueprint, or the dependency between the data abstract class and the planned entity. It promotes the discouraged reuse philosophy from general service packages.
Package by architecture hierarchy	Consistency between layers must be maintained. It isolates different technical fields: the assumerver pages (JSP) at the user interface layer; the enterprise ans (EJB) and servlets at the business logic layer; tables in the bean, class, and data layer. It increases the possibility of reusing the system architecture.	Not all code exactly fits the layer-3 architecture. For a sub-system, the team leader or remote team must check out several*. CatFile to update or obtain all permissions for the subsystem model. If you do not check all models, it is usually difficult to report or present a specific subsystem.

Table 1:Comparison of packaging methods

Finally, we used the first method to divide the design model by subsystem. We think the system is small enough. We can maintain the consistency between subsystems.

Subsystem Structure Design
An initial draft of our top-level package structure is like Figure 4. You can see the identified subsystem from the top-level package (therefore, the prototype < > Assigned to every subsystem ).

Figure 4:Structure of top-level package

We had a lot of discussions before we turned this early draft into a final stable package structure. The following are some of our concerns:

• How do we organize common services?
  A: The Public Service is separately placed in a sub-package (Log service, data synchronization and backup service, access control service, and login service ).
• Should we draw lines between shipping and part management?
  A: We don't need to connect them two.
• Do we define subsystems by domain or architecture?
  A: architecture can be combined with fields in most places.
• Can we allow bidirectional dependencies between packages?
  A: No. This is a poor design practice that violates our internal design guidelines.

As an example, we will focus on the command gateway subsystem. Although the system is centered on an internal and external web interface, we plan to provide a secure and XML-based command gateway ), this command gateway allows the ASDI system to form a B2B (business-to-business) interface between its major customers. This feature allows these customers to query, submit, and update information about ASDI from their existing systems. This is very important, because some companies require that they cannot access them through web interfaces. On the contrary, they need batch or behind-the-scenes submission from the company code.

In each package, our original class diagram comes from our use cases, business object models, annotations, and interviews. Figure 5 shows the evolution of the command gateway subsystem from the early thought to the detailed design.

Figure 5:Initial Design of command Gateway

In this first round of design, we simply identified the main part of the command gateway sub-system. At this level, there are issues that must be concerned:

• Are we using XML? (Problems include the maturity of broadband consumption, stability, and interpreter ).
• Do we want to send and receive data to customers?
• Do we need to provide the client software for the command or just the specification for issuing the command for this?
• Do we need to transmit XML through SSL (Secure Sockets Layer), HTTP or private socket communication?

In the subsequent design (figure 6), we identified more dependencies in the system and began to identify things that look like implementation classes. We are still arguing about high-level concepts, so we are not interested in signatures of documents and classes (methods and attributes ). The document and class signature should be filled in when we feel that the design is stable.

Figure 6:Mid-term Design of command Gateway

As shown in figure 7, we later refined some of our identified dependencies, appropriate methods, and attributes (hidden in the diagram to save space ), and added some technical details. For example, by establishing a prototype, we can identifyJSSE(Java Secure Socket Extension) is a solution for SSL connections between customers and servers. JSSE is directly integrated into JDK 1.4. It is only an additional part for versions earlier than JDK 1.4.

Figure 7:Mature command Gateway Design

This design is not final. Although the design has been tested using a large number of scenario diagrams, in the next few weeks and months of coding, we will find incorrect places or missing details in the design.

Manage changes to requirements

During our architecture and design, we identified the need to add new requirements or refine existing system requirements. It is tempting to ignore some small changes, but we can see that a considerable amount of budget is required to complete the changes. A small gap in budget will increase the time needed and give the customer a bad precedent. We found that tracking all the additions and changes will help us maintain expectations with checks and force us to ask, "Do we really need this in the future ?" This is a key point we usually ignore: If a requirement is not important enough to enter the system, it is not worth implementing.

Sometimes, the introduction of demand has a negative impact on the existing evolution and budget. This requires us to sit down and discuss options with our customers-but first, we should discuss them internally so that we can propose alternatives to our customers in a credible manner, rather than simply "impromptu performances ". The selection usually includes the following:

• Delay demand.This usually occurs when the demand is not both important, or other requirements are less important than the requirements currently being built.
• Remove the requirement.This occurs when the demand is less important.
• Replace an existing requirement with a new one.If an existing requirement is not important or at least not urgent, we can postpone or remove it to free up time and budget for the new requirement.
• Add requirements to the current work.This option is taken into consideration only when unacceptable risks are not introduced to existing requirements and the overall system plan. Adding any important demand naturally requires additional time and budget.

Changing use cases is not a problem, because we strictly control the use cases and update them directly in the model. In addition, it is easy to use rational requisitepro to integrate programming into sow. However, what we want to be traced back is that we have spent time building Rational ClearQuest to manage changes to demand. Sometimes changes are identified internally, but more often there are external requests. Our change management process is very clumsy, including monthly meetings and hardcopy files. A more seamless change request process will almost bring more opportunities for increasing the control scope and generating better systems and higher peace value.

Data Modeling

When we started the design work described above, we also started modeling data. In previous projects, we used Rational Rose for design, and the division between the current persistent class and the temporary class is a bit clumsy: Once we identify a class for persistent storage, we set its persistence property and start modeling it with other tools. In the ASDI project, we used data modeler integrated in Rational Rose enterprise for data modeling, and found that it was too mature.

In fact, we initially set an error in using the old method-placing persistent objects in their own folders and forgetting them-, we discovered them and used rose to convert these objects into data models. Put all the collected persistent classes into a package. We can right-click the package, and convert them into data models (Select data modeler> transform to data model from the context menu ).

The data modeler creates a database plan in the Rose model. We later converted these plans from its logical representation into a physical DB2 installation and gave the engineering team access to tables and test data.

Prototype

As the basis of architecture and design, good analysis is important, but prototype is also very valuable. A lot of ideas look good on paper, but we assume that only prototypes can provide evidence.

The engineering team enjoys prototype activities very much. The typical schedule for these activities is very confident, the goal is vague, the technology is new, and QA is easy, therefore, prototype is often interesting-a great waste of money. We found that if the prototype does not have a clear, measurable goal, it will soon fall into the "What can I do..." situation, rather than the risk reduction task.

We usually try our best to be consistent with the evolution product theory of the RUP, which can guide us to evolve all our prototypes into the final product. In fact, we retain the term "prototype" for fast exploration ". In order to release the greatest value from the prototype, we often ignore code standards, same-level checks, and similar processes. Some aspects of the prototype (Class description, design patterns, or coding habits) may be reused, but we put a lot of pressure on the team to reuse it. On the contrary, the results of our prototype are generally summarized as technical notes or sample applications that can be used for reference by live projects.

Immediately, a work package must be drafted. For its developers, this package can summarize the target of a specific prototype. We allocated a budget and schedule for each prototype, including the interim check before the task is completed.

We do not always create a prototype through direct encoding. Sometimes we perform tool evaluation by learning before writing any code. When evaluating databases, for example, we remove some candidate tools from the class table based on our experience, information provided by suppliers, and third-party checks.

We found several good methods for prototyping and tool selection:

• Review (read, review, interview)
• Coding (in-depth code snippets can detect specific interfaces, requirements, or performance problems, and clear and concise code snippets can display connectivity, workflows, and availability)
• Prototype installation and demonstration
• Tool provider demo

The key to making good use of the prototype is to determine the degree of implementation of the prototype. Few Original models can be designed to give people 100% confidence in recommendations. Instead, the prototype must demonstrate sufficient results to reduce the risk to an tolerable level.

Table 2 lists some specific prototype activities we have used in this project.

prototype activity	result
Research (covering features, costs, and performance)	selection of Orion Application Server (for more information, see Part 1 )
oobd evaluation (covering features and market share) to satisfy customers' preferences	decided to discard OODB (for more information, see Part 1 )
Research on relational databases (covering features, costs, and performance)	select DB2 (for more information, see Part 1 )
JSSE evaluation (covering complexity, stability, and security)	include JSSE In the B2B solution
User Interface simulation (test availability, workflow, and "external view")	for "external view, User Interface Guide and standard development"
Data Modeling in Rational Rose enterprise (using Rose's data modeler)	familiar with the use of Rose data modeler; generate database textbooks for creating tables, triggers, and other early prototypes
XML exploration (see related resources ) and create a B2B interface prototype	unanimous acceptance of XML in good format is more important than trusting third-party interpreters or adding more importance to XML with rich tags
comparison between EJB and JSP and servlets	we decided to use JSP and Servlet in Stage 1

Table 2:Prototype Activity

Summary

Our system architecture and design have been quite mature; our prototype has achieved great success and we will soon begin to implement the work. This means that tracking the project process is more important than maintaining the project vision in the defined direction and carefully planning each iteration and increment.

So far, we have tested and selected all major technologies and third-party tools, and we are very satisfied with the tools provider's ability to do their work. We made this decision through the prototype we planned, and we don't just want or trust the silver bullet. Prototype also helps our engineering team to provide us with the knowledge and skills needed to complete our work.

Plan the future
In the near future, we will enter the implementation of the system. We plan to achieve the following goals:

• Command gateway, which causes some of the greatest technical risks
• Graphical user interface, which provides customers with useful inspection Products
• Some common services required by many subsystem Functions

Before any implementation, we must prepare for the project stage in multiple aspects, including updating the structure of our team to meet our new needs, documented code and design agreements and exchange of effective development methods (including unit tests and peer checks ). The engineering team will need to fully understand two-way engineering, debugging, analysis and other things.

Major Risks
The JSSE prototype indicates that JSSE is a more complex api than we originally expected. In particular, security creates great opportunities for the spread of project scope, so we must work closely with ASDI to accurately understand what security they need. The work from the requirement does not involve the key length, encryption mechanism, and other underlying details.

Finally, we select JSP and servlet on top of EJB. We know that our architecture may need to be reworked in stage 2nd. We are willing to keep it as a risk at that stage, because we have completely submitted this technical choice.