This article is a series of articles (as listed below) in a distributed, J2EE-based project (as listed below).
Part 1: Project introduction; high-level plan Part 2: Risk management; demand management
Part 3: Model Creating and Access Control; Demand Analysis Section 4: Use Case Refining; Equipment Report; Tools and Techniques Part 5: System Architecture and Design Part 6: Detailed Design; Early Development; Early Engineering; unit test
Part 7: Continue development; early construction; demo
Part 8: Unit test strategy; functional testing; GUI test script
Part 9: System construction and testing; defect tracking; product delivery
Part 10: Project completion; conclusion; future work This article is fictional. We are a software company Lookoff Technologies Incorporated, our customers AudioPhile Speaker Design, Inc. (ASDI), which hires us to achieve their original IT needs. For more detailed information, see Part 1. This article discusses the progress of the team entered the implementation phase, and thus entered the construction phase of the RUP. We selected most of the technologies used in the first phase of the ASDI project. The design is quite good, although the structure and design of the package discussed in the fifth part of this series will continue to evolve in the next one to two weeks. For example, a portion of the package structure is redefined to reflect the expected Java package name habit.
Part 6 Snapshots in Part 6 Demo:
Rational Rose Enterprise Edition - Supported Bidirectional Engineering Rational Purify - Using Java Memory Rational Quantify - Java Reference Implementation JIKES - IBM High Speed Compiler for Using Performance Bottleneck J2SE (Java 2 Platform Standard Edition) 1.3 - Sun Sun's Javac alternative) CASTOR - data binding framework from Exolab Group, used to bind XML to Java, and vice versa. Products created or updated:
The design model (Rational Rose) - With the development of code, the Java code is updated - Creating a paving road for Command Gateway and other subsystems before we can develop, we must complete the following things on the management and team leaders. :
Establish guidelines and informal training so that engineering teams can comply with the same coding and design conventions. Updating the original team structure (the second part of this series is displayed) to reflect the requirements of different implementations. Establish development strategies and environments to make our developers can effectively cooperate, so that developers can work in their own system and will not affect others, and easily test their code. Appropriate close tracks to ensure that the task can be done and meet their goals as scheduled. The guidelines and standard RUP emphasizes the importance of the same level of review when a product is constructed; we will learn more about more details. The team must agree to the standards of the same level of reviews to avoid going to two extremes: loose review will bring very little value, or excessive strict review will produce a lot of annotation, such as "this is achieved, but Here I am implementing the comment. For our Java code, we created a coding standard document based on Ambysoft Inc. Java coding standard. These standards have been proven to be significant in the same level of review. These standards can also help us produce more consistent and high-quality delivery systems for their customers, but also allow our team members to make adjustments between different subsystems (and projects). We have found that if developers are very familiar with the form of coding and build, they will be able to integrate into a unified team very quickly. By avoiding blurry naming habits, unsightly annotated and bad coding styles, developers can create code that makes other developers easier to take over. Under normal circumstances, engineers are trying to learn the technologies to be competitive in their business; however, some projects will introduce new technologies that need team training. We didn't in this case in the ASDI project, because the architectural and technologies used in this project were what we were familiar. Our training in this project is about the use of Rational Tools, UML, Java Coding Standards, and J2EE design patterns. Although we have a very good knowledge background in these fields, most of these knowledge is in the minds of team leaders. Therefore, training is composed of informal lunch time and the afternoon conference initiated by the team leadership. We have found that these meetings in one hour to a half day are very cost-effective (provided that you must have team members with sufficient knowledge and good communication skills). Because our topic is related to the entire company, we encourage other technicians to participate in these training conferences. We have found that more technicians will involve more valuable thinking exchanges. The most code, we plan to allow all engineers in the ASDI project (whether participating in analytical, design, implementation, or engineers). The structure of the team structure has evolved from the system's analysis to meet the needs of different needs during the system. As shown in Table 1, a large number of time agreed changes, and five new positions have been added. Role analysis period Project Management Project Manager 50% 25% Financial Association Support 15% 25% Quality Assurance 10% 25% Project Project Engineer 50% 25% Team Leading / Senior Analyst 100% 75% Project Support, In addition to configuration management CM) 20% 10% Project support: Configuration Management 20% 40% Support and Review Team 10% 5% Senior Developer 100% 100% Primary Developer 100% 100% Database Architect 25% 25% Senior Developer (Remote) -100% Intermediate Developer (Remote) -100% Primary Developer (Remote) -100% Integration and Test (I & T) Leaders - 50% I & T Junior Member -100%
Table 1: The reasons behind the changes and changes in the evolution team structure of the team structure are summarized:
Project management is reduced, and the focus is on the trace of the client's interface and budget. The support of the Finance increases, because our goal is to be more accurate and low granular reports on each task schedule. Quality assurance has increased. We need this role to confirm that the code review and the engineering notebook is maintained by developer. The project engineering has increased, and the role of advanced analysts plus team leadership roles. Therefore, project engineering and team leadership (decline in 25% and 75% respectively) were combined into a full-time position. In addition to configuration management, engineering support has increased because most of the infrastructure (that is, computer hardware) is time. Configuration management has increased to allow integration and testers to participate in build while also supporting storage for version control configuration management. Support and review teams have increased because we have to make them a big problem. Most code reviews are completed through the team's peers. These positions have been added: advanced, intermediate and primary developers who support increased development work. These team members conduct remote development activities in the headquarters and provide expert advice from "backend systems". (Our original plan moves the management of the project to the headquarters, but the current arrangement is working very well, so we all agree to continue to maintain the coordination method in the project.) A team of integration and testing has a leader and one The primary member is composed. Lead members drafted the initial test instructions to develop advanced test programs, and guide junior members to provide him with support for test data, writing test scripts, and writing test documents. Later, we found that our team structure may be too killing, because our tools are only validated in the first phase of the concept. We may advise the formal process of building and quality assurance in the premise without too much damage, and still need to meet our first phase of goals. Finally, we have established high quality concepts and provide more reusability than our initial expectations for the second phase of work. Developing methods Some previous projects require us to work in a shared development environment and this is often painful. Developers working on public code often interrupt the work of other software parts during development. We sometimes be required to work in a shared environment because of architectural or licensed restrictions, but we want to have an independent environment on each developer's machine. We plan to integrate developers components together with a formal basis. In ASDI projects, providing an independent development environment is easy, even for our remote office. Only sharing is DB2 database, but we can build a separate database plan for each developer, so that any potential problem can be removed. In addition, we set up each class by a single developer "owned" for our engineering team. We found this very good to reduce our merger and modified work. We never believe in the philosophy of parallel development on a source file in a CVS (Concurrent Versioning System), because changes in one way will bring fine but significant impact on other methods. We feel that the safest way is to give each class's responsibility to a separate team member. With regard to our specific development environment, we found that the Orion application server, Rational Suite DevelopmentStudio, J2SE JDK, and DB2 client software can easily comply with P-III 500 and 256 M memory machines. Orion is amazing little footprints and efficient design is the main factor he can run on such low hardware configurations. The basic development cycle is displayed in Figure 1 (it has borrowed the contents of RUP).
Figure 1: Development Cycle Each developer initially developed from baseline design. The first iteration developed includes a framework for generating code using Rational Rose as a starting point. A series of iterations (including small buildings that often occur) start from here. Developers informal unit testing for early iterations, and negotiate with the team's leadership. Small design changes can communicate via email, however, significant changes require a one-to-one discussion to ensure that changes are appropriate and will not have negative impact on other aspects of the system. Obviously, any changes to the interface (even common methods) require special detailed examination and conflict analysis. The design should be regularly updated by reverse engineering, combining any changes back to the ROSE model to maintain the latest screen of the system. Looking back, we hope that we will put more work in the scene. If our scene has demonstrated most of the system, we can use the report in Rose to display the detailed relying on the class. This will enable us to produce more speculated on the effects of specific changes. Instead, we must write the script to perform text search based on the configured code to determine who is relying on a specific method of the given class. When encountering complex things and problems, they will be handed over to the team's leadership. Usually team leaders or personally assist sololis problems, or let developers solve problems, or use help solve problems from other teams or companies. Sometimes we encounter technical needs and subsequent demands that are discussed with customers. For example, some of our security requirements, follow the Change of JSSE (Java Secure Socket Extension) API. Once the code is enriched, developers compile a range of unit tests, integrates a series of component tests, which are designed to test performance, functionality, and reliability. On the completion of the code and unit testing, the developer should assemble a review package for the same level review process (later described) and wait for feedback. The evaluation process sometimes leads to the modification of the design, and other places are just simple to identify some BUGs or need to enhance. Tracking progress Because we just started to achieve work, we are not prepared to use defect statistics from Rational ClearQuest as measurement our progress. Instead, we rely on two main information sources: task reports and small milestones. The task report is submitted by the developer based on weekly basis. These reports can indicate the completion of the last week's task work and the cost of the budget in the task, and can estimate the remaining effort in the task. Any obstacle to the progress of the task will also be reported in a weekly summary. Small milestones are even more critical because they sometimes reveal important issues. Team leaders often require small versions of construction, informal Friday afternoon demonstration, code preview or even code check on the spot. If we find a team or team member to achieve a milestone in a suitable product within a time period, this sometimes means that there is a problem that needs help. Ensuring the goal of the system's quality software engineering is to produce high quality software in a given time and budget. The precise definition of quality is different from the team to the team, which will be different from the project to the project. For engineering teams, quality-related goals include:
Easy-to-maintain code guarantees that all demands are implemented with a reliable operation. Sufficient performance clear document scalable design meets the time plan and budget We find that Rational Tools can help us meet many of these requirements. To illustrate which parts of the Rational tool help us, this part will focus on the Command Gateway section of the customer interface. Just as indicated in the fifth part of this series, this gateway is a B2B (Business-To-Business) interface. This interface allows large companies to query the availability of ASDI parts, submit orders, update their customer information and query. Transport or account status. Update design: The design of two-way engineering Command Gateway has experienced a series of iterations, has become a mature design of the fifth part of this series; however, a situation has triggered a remote senior developer to get synchronization with the design. She raised some excellent ideas in the part of her own, and we can consolidate them through two-way engineering - that is, by reverse engineering her changes into our ROSE model. This simple design and the latest code change synchronization is important for maintaining the quality of our system, because most of our things are carried out around the design model. Command Gateway is developed remotely (at headquarters) because they have rich experience in Java, XML, and JSSE. We sent the latest design to advanced developers on Friday, and plan to discuss design through the conference call in the next week. However, the developer was ill, and did not receive the design; in fact, she did not know any information we have completed, because our initial design is not detailed. On the weekend, she continued to work with her laptop at home, but she didn't realize that she has lost synchronization with Command Gateway design. In the next conference call, senior developers talk about the improvement of her design, and she introduced new technologies and her excellence in the entire development. This makes the team leaders very surprised. Of course, the developers have heard the design updates and very surprised. We agree to ignore the latest design and developers' work to find which approach we should use. When we choose a good way, developers' progress is remarkable, and more deeply thoughtful than our previous work. She uses an open product CASTOR that encapsulates XML data to be mapped to Java, and she merges some better design decisions than we propose. Therefore, we agree to update your design to reflect her good way. Because she started her draft code, so we need to return her design to our model. This is quite easy to complete: We simple offer to developers our latest * .cat files for Command Gateway, and reverse engineering her code into models. At the later part of the project, similar case reverse engineering will bring huge help. Retrograde Engineering Process When we carry forward the reverse engineering, set the ClassPath environment variable in Windows. The location of this environment variable relies on Windows versions, but it is typically found by the control panel of the system. (In Windows 2000, view the panel's advanced tab.) If the ClassPath environment variable is not properly set, Rational Rose encounters trouble between the evaluation code and the external reference class, usually results in failure of class analysis. In our example, we must set this variable to d: /jdk1.3.1/jre/lib/rt.jar; J: /usr/local/lib/xerces/xerces.jar;
J: /usr/local/lib/castor/castor-0.9.3-Xml.jar
This value points to the core J2SE class runtime library and our XML binding class we used to map the Java objects and XML data. Then we define the instructions for the project, use the Tools> Java> Project Specification option in Rational Rose (pop up the dialog shown in Figure 4). We confirm all the paths found, and we pointed out the root of our code in Rose. Figure 2: Instructions for defining items in ROSE Next, we select Tools> Java> Reverse Engineer options, which pops up a dialog (as shown in Figure 3) prompts that we choose the source file that will be analyzed. We chose our package - ASDI class to introduce all the code of the senior developer - then click the Add Recursive button. Then we choose all the files listed and click Reverse to reverse the project.
Figure 3: In Rose, the reverse engineering is in the first few attempts, we realize that we have an error in setting our ClassPath environment variable, resulting in some error messages in the daily file. (It is important to ignore these errors, and they sometimes point out the parsing of the file completely failed). The results of the reverse engineering once the reverse engineering is successful, we can find a package that is named ASDI in the logical view and component view of our model (see Figures 4 and 5).
Figure 4: Class generated by reverse engineering (logical view)
Figure 5: Component (Component View) Reverse Engineering Generated Component (Component View) The relationship between the analysis class is quite effective. When the class variable is declared as a member variable, it is more reliable to find ownership. Some relationships are not obtained (for example, the relationship created by instance variables in our Java code), so some continued check work is necessary. It can be understood that ROSE is not created for the code. In hundreds of categories, Rose has no way to know how to logically group these classes to properly represent the architecture and design of the system. However, the relationship between all classes has been properly generated, and the design and component diagrams are relatively easy. The gateway design modified after the reverse engineering is shown in FIG.
Figure 6: Modified (reverse engineering) gateway design in the design shown in Figure 6 is the interface of introducing and caos to XML binding interface. We don't have to do our own analysis (using Xerces-J or XML4J) to perform XML messages to object transformation, because CaStor apparently provides this mapping capability. The Talker class encapsulates the functions of JSSE, and Java.util.Vector subclasses provide simple management of the entry message. Vectors makes the query of advanced first out (FIFO) through add (...) and remove (0). In general, we choose ArrayList on the Vector, but because the query must be shared between the thread, we agree to keep things simple. (Vector is synchronized, but ArrayList is not, it requires collections.synchronizedlist () to be used) Performance Analysis The risk associated with the new Command Gateway method is uncertain about the performance problem of the serialization API of Cast. With long-term testing XML interpreters, we know that their memory usage and performance is sufficient when the load condition reaches the peak. We need to evaluate Castor products to ensure that it can meet our system performance requirements. In order to accelerate our process, we decided to use Rational Purify and Rational Quantify to observe the behavior of Castor. These tools allow our precision to check the needs of resources and the behavior of CASTOR. For convenience, do not interfere with the code that implements the entire JSSE client and server side, we decide to remove the functionality of JSSE (Talker class in Figure 6) to provide fictional XML messages. Check if the use of Java memory us want to know the level of resources required by the Castor Engine. Products using this open source for our project are slightly adventures, so we need to make sure it is a mitigation and is not seriously phagocytical resources. We have designed some of the annual running unit tests to find out any memory leak or stability. Rational Purify currently has the function of Java memory analysis, so we decided to try it with it. In a C or C project, we have enforced the violation of the PURIFY on the component to prevent the memory access of the product code. Using Java, the problem of reading empty pointers, memory leaks, and array crosses is no problem; however, Purify is still a very useful feature for us in the analysis of Castor. In order to run the purify, we must first set the parameter configuration to use the correct JDK. Apart from the "Pause JVM Console Inster EXIT" option, we use the default settings for our JDK version so that we can see any errors or ends of our app when the Purify test is completed (see Figure 7). Figure 7: Configuring JVM for Rational Purify In order to run the PURIFY test, we select File> Run and name main.class by browsing the main.class file settings. This sets the default option as shown in Figure 8. The only change we did (because the cut display, so you can't see this figure) is an update command line parameter to run asdi.exchange.command.main, so the default setting of Purify is Main.
Figure 8: Java test running a Purify is interesting, we have encountered an exception error in the class form. In the past, we have seen these exceptions when we migrate between JDK 1.1 and JDK 1.3, where * .class verification rules have changed. Since some reasons have encountered this problem, it is only in the purify. If we use J2SE's JavaC.exe instead of jikes.exe (IBM's high-speed compiler) to compile * .class files, the problem disappears. The analysis results of Rational Purify are shown in Figure 9. Figure 9: Purify output for Command Gateway (Click to enlarge) We run this test for hours to make sure it is repeatable and foreseeable. No problem is noted, in addition to the problem of garbage collection. Although memory use has never spread, our application is forced to perform meaningful garbage collection during each second handling and mapping 200 commands. So far, we didn't see performance, because the load of the CPU never became tense at any point of the test. Analysis code Rational Quantify has always been a tool for our favorite in C or C projects. We usually use it to track performance issues to ensure that no code is wasting the CPU or real-time cycle. Quantify is similar to PURIFY in appearance and configuration, and the setting of the JVM is completed in the same way. Quantify is very useful for the CPU and time that CASTOR affects how it affects, and it helps us know where Castor's work is. Figure 10 shows a sample screenshot of the Quantify environment when analyzing our COMMAND GATEWAY code.
Figure 10: QUANTIFY output for Command Gateway code (click to enlarge) is a little clear for us, which is a considerable number of CPUs when the Castor runtime XERCES (under the underlying XML interpreter) is used. We obviously have the same problem because we still have to explain the XML message to extract the content. Quantify enables us to understand the maximum and minimum time of execution of each part in the call stack, is derived, and other useful information. Finally, we feel that in our system contains CaStor to make the right because it shows its robustness and some good features. Unit test unit testing is a vital part of our development work. Most developers are just a formal unit test, and even not required to be tested; however, we have found that consistent accuracy and quality through formal unit testing processes are huge value. Developers usually focus on the wrong conditions in their tests, but unit tests should test several aspects of software. Some resources provide useful information for the team to define roles and unit test specifications, are listed in the "reference and related resources" developers in this article, developers often define their own unit test specification because these tests are very The bottom layer of white box and black box test, they are also very detailed, allowing integration and test teams to understand. In order to force the consistent level of detailed level in the unit test specification, we include them during the same level. At the same level review, we have established the same level review to help us identify them before the system's BUG affects the production environment, and we observe some things very interesting: few BUGs are identified in the review process. Originally, this showed a lack of code evaluation value, so project engineers were not very serious about everything. Here is what they find:
Simple in the same level has improved the quality of the software because developers know that their code will be carefully reviewed. The process of being added in the form of standard, guidelines, pre-arrangements, and better training is reduced by bugs affecting the code. The increase in formal unit test is being given a chance to develop a bug for developers. In the early project, we did not plan this additional unit testing, and developers felt very terrible pressure and rush to enable their code into an integration plan. The same level review has also improved the ability of the entire team through the cross-examination of skills and methods. Developers build good design patterns and coding habits by understanding other ideas of other people. The code review allows discussion of valuable conjunction with various coding strategies using a large number of times; therefore, we will try to make at least one primary developer participation in the review. Our coding standards are more than just a simple problem, but also related to coding habits, coding practices, and performance issues. The standard is presented to the team at three lunch hours, along with the guidelines for the review process. The procedure of the evaluation process is as follows: On the completion of the code and unit test, the developer creates a review package consisting of design descriptions, code, unit test description, and unit test results. The assessment package is distributed to the reviewer - that is, distributing the team leaders and other two developers based on the complexity of the code. Developers perform 1 to 3 hours of code prevention for reviewers. Reviewers separately reviewed and labeled code, and returns the label to the developer. Developers check the comments of reviewers. Developers and reviewers perform 1 to 2 hours of annotation prevention and reach an agreement plan for each annotation. Initially, we have worry about this review process will spend more time, but we found that it is very valuable, it provides:
Everyone is well prepared for every stage. Simply put, the code has few reviewers - sometimes just team leaders. The last pre-session is not a hurry because it provides a lot of discussion, unanimous comments, and conflict discussions. Summarizing that we have paved the way through the guidelines, adjusted the team's structure and well-thoughttful development methods, and we found that development (including refinement of design) is very good. The engineering team began to understand the power of the Rational Suite Developmentstudio tool. It is unusual to learn the learning curve of these tools, but we have been able to use them very comfortable through this time. In particular, we have gained great interest by using Rational Rose's bidirectional engineering, Rational Purify's inspection Java memory use and Rational Quantify code analysis. Using these tools, we have achieved the quality goals of the ASDI system along with the establishment of unit testing and peer review. Planning the future we will make our team habitual buildings, the more benefit of our projects. We expect to establish a build cycle every Friday and establish a subsystem every third Friday. It is also valuable to build a team of these small versions and is also very good for teams to make everyone see what they are merged into a whole to encourage morale. In the next few weeks will be an early demo of internal and external demonstrations. For external demonstrations we will quickly integrate user interface screens together. This is also a very good opportunity for us to get additional demand feedback. Main risks are even in the early stage of development, the challenges of remote development have been knocked us, and we know that this challenge will become more spicy when we start integrating our components and subsystems. Early "practical build" requires a quick start so that we can smoothly achieve integrated processes and solutions to early issues. It is a challenge for us throughout the project. Although we have also done remote development, we have not solved how to integrate teamwork results of teamwork across the separated geographic location. We learned that Rational's tools cannot completely eliminate remote development issues, but they can at least reduce the pain of remote development. For example, we still don't prevent senior developers from disagreement in Command Gateway design, but reverse engineering can help us evaluate and integrate her change through the least work. In order to meet our strict end deadline, development must continue to advance with efficient pace. Since the architecture documentation we provide to the customer software, it has been a period of time, and the customer is eager to see some progress. It is important to provide an integrated demo as soon as possible. Resource
"Writing Robust Java Code: The Ambysoft Inc. Coding Standards for Java V17.01D" Scott W. Ambler is compiled.
About the author Steven Franklin has a very broad background in software design, architecture, and engineering process, which is often used in large, distributed information management and control systems. He started using Rational tools in 1997, his main interest in XML, J2EE, wireless and software engineering technology. You can contact Steven via Steve@sfranklin.net.
