Borland Application Lifecycle Management (ALM) for Eclipse

Transcription

1 Borland Application Lifecycle Management (ALM) for Eclipse Extend the Eclipse framework with Borland ALM solutions for requirements, design, development, performance and testing, and change management A Borland White Paper By Ian Buchanan September 2004

2 Contents Introduction... 3 There s more to development than edit-compile-debug... 3 Requirements management... 4 Analysis: Supplementing requirements with Unified Modeling Language (UML ) models... 6 UML modeling for architecture and design... 8 Borland Together makes understanding large code bases easy... 9 Implementation is more than just coding...11 Testing for developers: Coding with confidence Audits and metrics reduce the tedium of code reviews Software remodeling is the realization of iterative development Collaborating on software development...17 Borland StarTeam : Beyond version control Conclusion

3 Introduction Although many teams think of Eclipse as only a free Java IDE, it is much more. Considering the state of development tools today, there is a strong need for tighter integration with other aspects of development than just edit-compile-debug. This paper provides an overview of the Eclipse IDE, the need for a tools platform, and how the Borland notion of synergistic integration is being realized on the Eclipse platform. Using Borland Application Lifecycle Management (ALM) solutions, developers can work more effectively within a software development team, without being locked into a particular platform. If you work in software development, you ve probably heard the buzz around Eclipse. Perhaps you are already using Eclipse in some form. What you might not know is that Borland offers a suite of complementary solutions (plug-ins) for the Eclipse environment that add rich capabilities for requirements management, design, performance and testing, and configuration management. Although many people know that Borland has provided first-rate developer tools for more than 20 years, many software developers have been pleasantly surprised to find that Borland provides a complete set of tools for ALM. Furthermore, by offering solutions for Eclipse, Borland is proving its commitment to platform independence and modular solutions. There s more to development than edit-compile-debug While Eclipse has grown in popularity in the Java development community, it is more than a framework for Java IDEs. Technically, the Java Development Tooling (JDT) plug-in provides Java development capabilities on top of a flexible framework known as the Eclipse Platform. This platform provides capabilities such as basic UI components found in software development, a help system, and team repository support. In this way, Eclipse is a universal, open-source tool platform that can be used for multiple languages and development paradigms. In fact, the managing consortium of vendors, such as Borland, represents a great many platforms and languages beyond Java. This notion of Eclipse as a platform is not just important for vendors to write more tools, it is also important to the enterprise developer who 3

4 must work with many different languages such as HTML, C/C++, PHP, Perl, XML, etc. Today s heterogeneous computing environments can benefit from an IDE that supports multiple languages. Moreover, modern software development takes more than just edit-compile-debug. Requirements are needed to drive the design and testing phases of the application lifecycle and ensure successful deployment. Few applications are purely green field projects without any dependencies on other systems. Effective architecture and design is critical to ensure that applications integrate and meet requirements. Although requirements and design contribute to better-quality software, other techniques are used to assure quality. For Java development, unit testing, refactoring, audit/metrics, and profiling have become industry standard practices for ensuring high quality. Of course, configuration management plays an important role in quality as well. Without a system for managing the digital assets of a software project, it is nearly impossible to balance rapid development with a manageable process. With tools to manage all of these aspects, a developer s world can easily be full of jarring interruptions and duplicated effort. Fortunately, Borland products are both innovative and integrated, bringing best-in-class tools together as a modular solution. Requirements management As a developer, it is easy to dismiss requirements management as something done upstream by someone else. Even if requirements are written by someone else, ineffective requirements management can easily become a burden for developers. 4

5 As an illustration, the following is a well-written requirement: Requirement The system shall be able to identify allocated COTS licenses that will expire within 60 and 120 days. The system shall provide the capability to generate an Expiring License Summary Report that will include a list of the COTS licenses, or associated maintenance agreements, by project/user organization, that will expire in the selected timeframe (either <=60 days, or <=120 days). The list will include the product version/revision, vendor, platform, license expiration date, maintenance agreement expiration date and Point-of-Contact information (name, phone, organization, address, etc.) Although it clearly and unambiguously explains what a developer needs to implement, there is a lot of context missing. To get the additional context, the developer now needs to go back to the upstream role to ask the following kinds of questions: Who owns or is responsible for this requirement? Who created it? What is the current status and priority of this requirement? Is this the most current version of the requirement? Has this requirement changed since I last looked at it? What relationships does this requirement have to other requirements? To other development deliverables? What is the current status of these relationships? Borland CaliberRM is a powerful solution for managing requirements for software projects. Using CaliberRM, developers can view the list of requirements, assigned to them within Eclipse, which help them to correctly implement the requirements without communication gaps. Answering these questions takes more than just a well-written document; it takes a welldefined requirements process that forces business users to provide the correct requirements from the beginning in order to minimize the amount of project rework. 5

6 Borland CaliberRM manages each requirement as an individual object. Each requirement is well defined with its own status and priority attributes, version history, and discussion threads. CaliberRM helps a team work collaboratively on requirements, even in a distributed environment. These requirements can be tied to individual developers who in turn implement them without a communication gap. CaliberRM facilitates communication among project teams, helps to reduce errors, and improves project quality. Designed to promote better understanding and control of projects, CaliberRM is a pivotal definition and design component of the Borland suite of application lifecycle management technologies. With CaliberRM, a developer can answer all of the previous questions from within the Eclipse environment. Figure 1: A view of requirements stored in CaliberRM from within Eclipse Analysis: Supplementing requirements with Unified Modeling Language (UML ) models While capturing up-front requirements as simple text is appropriate when dealing with primary stakeholders, this often leads to a problem of organizing and understanding a large number of requirements. In order to assemble a complete application, developers must understand the big picture. As visual creatures, we are able to comprehend more information faster when it is presented visually. Industry-standard techniques such as use-case modeling 6

7 help structure requirements analysis, put the requirements into context, and ensure that all the important questions get asked. The Unified Modeling Language (UML ) was created for just this kind of purpose providing many perspectives of a business and/or software system in one cohesive model. Although UML has been around since 1996, many people still suffer from a lack of standardization, homegrown design templates, and nonstandard notation. This increases the challenge of effective collaboration and communication among those with different roles on the development team. Leveraging UML as the industry standard for visual modeling ensures that all roles can communicate using UML as the common language. Because UML is commonly taught in universities and used throughout the software development industry, new additions to a team likely already know UML and can become productive sooner. The core problem with the adoption of UML is typically the tooling UML tools are difficult to learn and use. But Borland Together technologies are among the most intuitive, easy-touse modeling tools available. With extensive samples and built-in helpers to aid those new to modeling, UML becomes accessible to everyone. Moreover, Together offers a flexible modeling environment that is not tied to a particular process. Another disconnect from real software development is the nonexistent or poor integration between requirements and design tools. The transition from text documents into UML is frequently a source of rework as the same textual information is re-entered into a model. Once the information has been recreated, tracking the linkages between changing text requirements and changing models can be difficult. Borland Together and CaliberRM help eliminate such hassles. A right-click on a requirement is all it takes to create new diagram elements from existing information. As model elements are created, they can be traced to the appropriate requirements making understanding the impact of a requirements change on the UML model much easier. 7

8 Figure 2: Tracing requirements to UML elements UML modeling for architecture and design One of the advantages of using UML in analysis is the ease with which analysis information can be incorporated into architecture and design. For example, an analysis of the business domain as a class diagram can become the starting point for design. Within Together, hyperlinks between analysis models and design models provide an easy mechanism for representing traceability and providing navigability through the models. One the biggest advantages Borland Together has over other UML modeling solutions is the LiveSource capability that keeps models synchronized with source code. During design, this means the architecture is already being implemented in Java. Extensive support for Gang of Four 1 and J2EE design patterns 2 help create more working code faster. Because Eclipse does 1 Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns (Boston: Addison-Wesley, 1995). 2 Deepak Alur, John Crupi, and Dan Malks, Core J2EE Patterns: Best Proactices and Design Strategies (Upper Saddle River, NJ: Sun Microsystems, 2001). 8

9 incremental builds of the Java code, one can understand any potential compilation errors immediately. Not only is the design already validated against the compiler, but also, Borland Together provides audits and metrics to help ensure quality of design. Together audits provide static analysis of source code that checks for compliance with common coding guidelines such as Sun s Code Conventions for Java. 3 Together metrics provide similar static analysis to quantitatively understand aspects of object-oriented design such as coupling, cohesion, and complexity. Figure 3: Model and code synchronized with LiveSource Borland Together makes understanding large code bases easy Another challenge addressed by LiveSource is the difficulty in keeping design documents current with changes to source code. Because LiveSource keeps the diagrams synchronized 3 Sun Microsystems, Code Conventions for the Java Programming Language, 9

10 with source code, the challenge of creating up-to-date design documents is reduced to clicking the menu option to generate project documentation. Because there is no manual synchronization step, the documentation always reflects the latest as is picture of the system. Changes made to the code by a developer can be seen by the architect in the application model; changes made to the model can be immediately viewed in code. In this way, development stays synchronized with design. Up-to-date design is critical for scalability, reuse, and maintenance. Many other vendors claim to synchronize source with class diagrams; however, LiveSource is a robust and mature technology that makes Together perform far better than most. Even so, class diagrams are only a structural view of the software. To understand the behavior one needs a sequence diagram. The ability of Together to do deep parsing on the source code allows for accurate and efficient generation of sequence diagrams from a right-click option on any method. With this on-demand generation, it is now possible to visualize the sequence of messages between objects as declared in the source code. Figure 4: Generate sequence diagrams from existing code With such powerful synchronization between source code and UML, Together facilitates the understanding of existing projects. For projects that have no design documentation whatsoever, Together eases the reverse-engineering of existing code and the generation of class and sequence diagrams. This can be helpful when you are new to a project or when your 10

11 team has inherited new code. This technique also can help you understand third-party libraries used on the project. Implementation is more than just coding If you are a developer using Eclipse, you might have downloaded it for any number of coding features. For example, by creating navigable snippets of commonly used code, live templates provide great productivity when one is writing code. Borland Together Edition for Eclipse takes this kind of productivity to an even higher level. Source code is generated at the design phase. Class diagrams lead to classes, attributes, and methods. Sequence diagrams provide skeletal code for method bodies. When design patterns are applied, working code implements the behavior of the pattern. With custom patterns, a team can find new ways to reuse common relationships between classes. All of this helps the developer focus more on implementing the critical business logic than on tediously coding the design. Figure 5: Editing code with Eclipse As important as code generation techniques are to enhancing productivity, much more must happen in a team development context. In this context, developers need tools that help them 11

12 work collaboratively on software, in such a way that parallel efforts do not cause quality to slip. Fortunately, Eclipse helps developers use industry-standard techniques, such as unit testing and refactoring, to build quality into an application during implementation. But complementing those capabilities with Borland tools drives quality to the next level without sacrificing productivity. For Together product demonstrations, please visit Testing for developers: Coding with confidence Any team project likely involves more relationships in the source code than any one person can keep in his head. Such complexity makes it difficult for a developer to answer, Did my change break something else? JUnit provides a convenient regression testing framework that allows developers to capture the assertions about how the software should work at the method level. The simple nature of unit testing with JUnit allows developers to run tests frequently to check for defects that might have been caused by a recent change. Eclipse makes writing and running unit tests easy. Although a good unit testing framework goes a long way toward helping developers make changes with confidence, Borland Optimizeit Suite provides more detailed information when a unit test runs. Rather than just pass or fail, Optimizeit Suite provides insight into the runtime characteristics. With Optimizeit Suite, a developer can answer the following questions: What objects are allocated when my method runs? What objects will remain after the method completes? Where are the bottlenecks in the flow of my method? How much CPU time is spent working in methods that I do not control? Have I tested all the branches through a method? If I know my tests are thorough, are there any sections of code that did not get run? Does my method have any common runtime problems such as uncaught exceptions, inefficient sizing of collections, or critical resources that go unclosed? 12

13 While Optimizeit Suite provides considerable insight during unit testing, additional problems arise when the application is brought together for integration in a Java 2 Platform, Enterprise Edition (J2EE ) environment. The application might talk to different back-end databases, have multiple front-end Web containers, and live in a clustered application server. With such complex interactions, the next level of integration testing needs a similar complement to the pass or fail results in order to provide insight into the interactions between these tiers. Borland Optimizeit ServerTrace can aggregate the information from these different locations into one cohesive view of the system and allow a development team to drill down into trouble spots right to the line of source code that might be causing the problem. Figure 6: Understanding application performance across J2EE containers 13

14 Audits and metrics reduce the tedium of code reviews Another approach to source code quality is the code review. Research and industry case studies reveal that code reviews as a part of an overall software inspection might be the most cost-effective technique a team can use to reduce defects. 4 Yet many groan at the thought of a code review because they are often time-consuming and inefficient. As developers argue over the best convention for curly braces, the real issue of implementing the right business logic is easily lost. With Together UML capabilities, code reviews can take advantage of a higher level of abstraction focused on the key aspects of the system rather than on the fine-grained details. In fact, a group from the National Research Council Canada conducted experiments comparing a traditional approach to code review, known as checklist-based reading (CBR), to a UMLbased approach, called perspective-based reading (PBR). 5 4 James H. Dobbins, CQA, Inspections As an Up-Front Quality Technique, Handbook of Software Quality Assurance, Edited by G. Gordon Schulmeyer and James I. McManus, pp (Upper Saddle River, NJ, Prentice Hall, 1999) 5 Oliver Laitenberger, Colin Atkinson, Maud Schlich, and Khaled El-Emam, An Experimental Comparison of Reading Techniques for Defect Detection in UML Design Documents, (National Research Council Canada, December 1999) 14

15 The following indicates some startling results (emphasis added): Our results indicate that PBR is more effective than CBR (i.e., it resulted in inspection teams detecting on average 41% more unique defects than CBR). Moreover, the cost of defect detection using PBR is significantly lower than CBR (i.e., PBR exhibits on average a 58% cost per defect improvement over CBR). This study therefore provides evidence demonstrating the efficacy of PBR scenarios for defect detection in UML design documents. In addition, it demonstrates that a PBR inspection is a promising approach for improving the quality of models developed using the UML notation. Within Eclipse, Borland Together can help in these efforts by allowing developers to rapidly create a domain model around a selected class and easily visualize all dependency relationships. The team can quickly generate sequence diagrams for complex methods. Furthermore, audits and metrics can be gathered to identify problems in the code base. Using audits to find and fix problems before the code review, developers can focus on the logic of the code rather than on conformance to corporate standards. Results from the metrics can help focus the attention of the team on the most complex sections of code. With Together and a projector, the code review becomes as much an active coding session as it is a review. Figure 7: Checking quality with audits and metrics 15

16 Software remodeling is the realization of iterative development Such active modification of existing code driven by audits and metrics need not wait for code reviews. The combination of UML, audits, and metrics found in Together and the refactoring support found in Eclipse provides the basic tools for a technique called Software Remodeling. 6 This technique builds on the notion of refactoring popularized by Martin Fowler from the Extreme Programming community. He defines refactoring as: 7 a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a refactoring ) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it s less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring. In short, refactoring can be described as improving the design of existing code without breaking it. As such, refactoring is the recognition that some aspects of design are driven from implementation not all the details of an applications structure can be planned up front. For Extreme Programming, refactoring is a constant part of day-to-day development. For others, refactoring might occur only at certain points in the development cycle. Whatever the strategy, there is still a question about where to spend refactoring effort. Some refactoring techniques actually might conflict or undo the benefits of another. How do developers know where to focus their refactoring efforts? And how can developers know whether the efforts are effectively improving design? 6 Richard Gronback, Software Remodeling: Improving Design and Implementation Quality Using audits, metrics and refactoring in Borland Together ControlCenter, January ThoughtWorks, Refactoring Home Page, Martin Fowler, 16

17 The Software Remodeling approach recommends using source code audits and metrics to drive refactoring. The results of the audits and metrics point to areas of code that need improvement. After making changes with Eclipse refactoring support, unit tests verify that the changes have not broken the code. Running audits and metrics again verifies the effectiveness of the refactoring exercise. Combined with the refactoring capabilities in Eclipse, audits and metrics make it easy to find and fix design and coding problems. Overall, coding an application is only a part of delivering high-quality applications on time and within budget. With Borland solutions, many additional techniques can be brought to bear on making higher-quality code without sacrificing valuable development time. Collaborating on software development The previous techniques provide developers with a great deal more control over the quality of the software they develop. However, many factors that affect quality involve all the stakeholders. Enterprises have a separate testing team that must report defects back to the development team. For that matter, end users, customers, or other stakeholders might need to report defects found in production. Combined with all of the incoming requirements, these defects must be prioritized, assigned, and worked on. If done in only an ad hoc manner, many defects can slip through the cracks. Or worse fixing one defect can cause many new ones to appear. Most development teams already use version control as a part of configuration management. Many popular configuration management solutions are available, including Borland StarTeam. By providing, rich, full-featured capabilities, Borland StarTeam allows Eclipse developers access to all configuration and change management capabilities. In order to balance development speed and quality concerns, the changes requested of a system also are tracked in a bug tracking tool. Unfortunately, most configuration management solutions offer poor integration between source code version control and change request management. This makes tracking the status of change requests across parallel 17

18 development efforts difficult. In other words, there is no way to answer, What change requests did we address in this branch? Borland StarTeam : Beyond version control StarTeam provides the benefits of integrated version control, requirements, and change management; task and process management; and knowledge sharing. The integration between these capabilities improves performance and communication between distributed, remote teams. Extensive process management and reporting capabilities heighten visibility and control of the application development lifecycle. With StarTeam, development teams are enabled to: Create traceability between file versions, requirements, change requests, defects, discussion topics, authors, and status Gain easy identification of workload Identify each change with a unit of work Ensure that everyone works on approved changes Reduce handoff and approval times between engineering, management, and QA Build knowledge while preserving project context Build, deploy, and maintain critical applications more efficiently Furthermore, with integration in Eclipse, developers have access to all the digital assets from within their development environment. Checking in files directly from Eclipse allows developers to update the files that were checked out and places the changes into StarTeam as a file revision. Developers can get up-to-date status on all their change requests and edit them. By integrating these two products, Borland brings the power of StarTeam configuration and change management capabilities to the Eclipse development environment. Such integration reduces the task interruptions that often affect the engineer who has to launch a separate solution. This integration also permits developers to perform essential configuration 18

19 management tasks, including the creation and revision of change requests activities directly from the Eclipse interface, and ensures that they work on the correct version of the code, thereby increasing efficiency and improving productivity. Figure 8: Viewing the StarTeam repository within Eclipse Conclusion Eclipse as an IDE is just one component of application development. By itself, it is a potent coding environment; however, with solutions from Borland, the Eclipse platform becomes a truly enterprise-ready development environment. The integration of requirements management, design, QA, testing, and configuration management functions enables developers to keep projects on track. Borland solutions represent the latest and greatest from a company with more than 20 years of experience and innovation in tools to enable software development. 19

20 Further information and trial versions of Borland solutions for the Eclipse platform are available on the Borland Web site: Borland Together Borland StarTeam Borland CaliberRM Borland Optimizeit Borland Enterprise Server Made in Borland Copyright 2004 Borland Software Corporation. All rights reserved. All Borland brand and product names are trademarks or registered trademarks of Borland Software Corporation in the United States and other countries. Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Microsoft, Windows, and other Microsoft product names are trademarks or registered trademarks of Microsoft Corporation in the U.S. and other countries. All other marks are the property of their respective owners. Corporate Headquarters: 100 Enterprise Way, Scotts Valley, CA Offices in: Australia, Brazil, Canada, China, Czech Republic, Finland, France, Germany, Hong Kong, Hungary, India, Ireland, Italy, Japan, Korea, Mexico, the Netherlands, New Zealand, Russia, Singapore, Spain, Sweden, Taiwan, the United Kingdom, and the United States