Managing Software Reuse with Perforce

Transcription

1 Managing Software Reuse with Perforce by Jo Woodison, Mandarin Consulting 1. Abstract Software reuse is touted as one of the biggest benefits of object-oriented programming, and indeed we have been reusing software libraries for decades. However, reuse practices have mostly been ad hoc, and the potential benefits of software reuse are still rarely realized. This paper will discuss how Perforce can help manage reusable software components with Inter-File Branching and associated reporting commands. Also explored are some of the elements of reuse-based software development methodologies and best practices. The most recent version of this paper is located at 1. Introduction Reuse can take many forms many items used or generated in software development can be reused. While this paper will introduce some of these, the focus of the paper will more generally address how any artifact that may be reused can be managed in Perforce. As with all things, there are many solutions to the same problem, and this paper serves not to illustrate all possible solutions, but to highlight some of the functionality and flexibility that makes Perforce an ideal tool for managing reusable artifacts. 1. What is Reuse? Software reuse is the practice of developing systems of components of a reasonable size and reusing them [McIlroy], then extending the idea of components beyond just source code to requirements, analysis models, design and test documentation and suites. All stages of the software development process are subject to reuse [Jacobson]. Here we will focus on how to manage the sharing of these items, but will not go into specific details on all areas of reuse. Essentially, we are interested in how to manage files on disk, shared at some level between projects, products and/or development groups Container Based SCM? The term container based SCM has been coined in connection with a process for managing component based development. While it is true that component based development involves a less linear approach to systems development in that each Jo Woodison Page 1 5/5/2003

2 component evolves independently of the others, essentially, the problem is still one of managing files on disk. The simpler and more efficient means of managing files on disk is the one with the greater versatility for handling the new complexity and reducing that complexity to something more easily manageable. 4. Why Reuse? It is not a myth. Reuse has been proven to offer many rewards. When we reuse code, components and other artifacts, our goals are to: Reduce time to market Reduce the cost of developing the product Improve the productivity of the development teams Improve the predictability of the development process Increase the quality and reliability of the product When reuse is mentioned, we often think only of code reuse. This is perhaps one of the lesser productive forms of reuse. That is not to say it is of little or no value, just that there are rewards to be gained in considering inheritance, template, component, framework, pattern and domain component reuse. Additional worthy candidates for reuse are our previously created use cases, standards documents, models, procedures and guidelines. Reuse eventually saves us time and money, and will ultimately lead to a more stable and reliable product. 5. Why not? Despite of all the perceived benefits reuse offers, the practice has yet to be adopted as widely as it might. It is on the increase: perhaps due in part to an increasing body of reusable artifacts whether in-house or provided by third parties; perhaps due in part to the greater awareness of the benefits and the need to gain a competitive advantage. Achievement of reuse has proven elusive, the reasons for which are many: Insufficient means to identify candidates for reuse in the development process Lack of available components to reuse Lack of flexibility in available components Lack of tools to assist with implementing a reuse strategy The software development process does not encourage reuse: o There is no stage where we question what has been done before and whether it can be separated out and reused o Roles are not well defined for architects, domain experts, reuse engineers o Procedures of analysis, design, code, review, inspection, walkthrough all fail to consider reuse Systematic reuse is not established as a best practice Lack of perspective: reuse requires a broader view than that of single project or product Lack of trust, the not invented here syndrome Jo Woodison Page 2 5/5/2003

3 Fear of dependence on others or of own redundancy Lack of capital funding, the return on which is not realized until artifacts are reused and reduce the cost of later development o Initial funding is required to develop systems that are strong enough to be reused o Initial funding is required to train staff in a third-party vendor s systems. Managing the design, code and components is only part of the reuse problem, and from this, you may surmise a small, yet not insignificant, part. 6. What does Perforce Offer? Perforce offers us a variety of features to organize our code, identify what components are located where and to control the publication of components for others to reuse. There are three main type of reuse discussed here. While there are more scenarios, they will mostly fit into one of these three categories: informal reuse, black box reuse, and managed reuse Depot Structure When considering how to structure your depot to best accommodate your reuse needs, it is advisable to ask some questions on how these artifacts will be used. Who will use these artifacts? Who will modify them? Do modifications be need to be distributed to all users/consumers? Immediately? Do all modifications need to be available for others to use? The answers to these questions helps determine the most appropriate approach to take. A combination of these methods may be used within an organization to accommodate varying requirements between different artifacts Informal Reuse The informal approach is perhaps the most common, and something that has been used for some time. Let us suppose that Project A has implemented some functionality, feature 123. Project B needs this functionality. Project B might simply copy the source code files that implement this feature from Project A. Project A will not give any further updates to Project B, and Project B will not give any of its modifications back to Project A. Jo Woodison Page 3 5/5/2003

4 This is perhaps the most common type of reuse. In Perforce this is easily managed with Perforce s Inter-File Branching mechanism. Very simply, in this scenario, integrate is used to branch the appropriate files from Project A to Project B. Those familiar with Perforce will already appreciate this intuitive and lightweight approach. Integrate performs a virtual or lazy copy of the specified files to the new location, simply maintaining a reference to where the files originated from. The files themselves will not be physically created in the Project B area of the source code repository until they start to diverge from where they were branched (aka integrated) from. While the intention is for no further exchange of changes between the projects, the option remains open and valid should it be required Black Box Reuse In the black box instance, a number of projects rely on a given component, comp456. No project will modify this component; it may even be provided by a third party. The projects must use the latest version of the component. Jo Woodison Page 4 5/5/2003

5 In this example, the component is held separately in its own area. Each project that uses that component uses the client workspace view to map the shared component into the appropriate location within the project in the client workspace. If a more recent version of the component is added to the repository, all client workspaces will pick up those changes when they next synchronize Managed Reuse In the managed reuse case, a number of projects may rely on shared artifacts. These artifacts may, at times, be refactored. Each project may or may not want to receive updates to the components they use immediately they become available or perhaps later. Projects may or may not want to contribute their own changes to the shared body of resources. Jo Woodison Page 5 5/5/2003

6 In this case, there is a separate area in the repository (within the same depot or in its own depot), for storing shared code. Dependent projects branch the artifacts they need into their projects. They may update their copies by integrating again if newer versions of shared artifacts become available. Jo Woodison Page 6 5/5/2003

7 If objects in the shared area need to be modified, they are branched to keep the primary sharing area stable. Once amended, tested or otherwise approved, the refactored artifacts are integrated back to the primary shared line and are then available for the other codelines to integrate from. If a project wishes to submit modifications to the shared line, it should ensure that it has integrated the latest version of the shared into its line, make the changes, ensure they successfully complete the appropriate test suites or that appropriate approval is obtained, and then seek approval from the shared line owner. With managed reuse, it is essential to have an owner for the shared area. This owner must clearly define the policies for the shared lines and supervise and approve all submissions to the primary shared line Reporting Commands In the following, command line examples are used for ease of typing. All of these actions can be perforce in the Windows GUI, p4win. Refer to the p4 to p4win Users Guide at the Perforce Software web site ( for the equivalent actions. Perforce offers many reporting commands and these can be put to good use to give us useful information about our components. Jo Woodison Page 7 5/5/2003

8 For example, to find out which version of a component is published to others, you can use the following commands: Informal and Managed reuse: o p4 integrated to show which integrations have been submitted o p4 filelog to show the history of the files, including integrations and merge actions o p4 integ n to show whether a more recent version of the shared code is available Black box reuse: o p4 have to show the revisions of files in the client workspace o p4 sync n to show whether a more recent version of the shared code is available Using the always maintained, reliable integration history in Perforce, we can use these commands to find out what component is used where and how the components are distributed. We can branch (integrate) different components at different revisions into our project code base and Perforce gives the inherent ability to identify the versions and dependent projects or products. We can choose to maintain a refactor or other internal branch and restrict access to it by other projects until it is proven good enough to release. Perforce gives us the ability to control exactly what components are published, and in conjunction with a protections scheme, we can control who it is published to. We have the ability to distribute components in a flexible way that is easy for teams to reuse them and write their own code to join them together or add extra functionality. Perforce tracks and allows us to integrate changes between different users and usages of components as well as the latest original component release. We are able to insulate the environments for different teams, products, or projects as we deem necessary and appropriate. 7. Best Practices 1.1. Reuse If reuse is not a practiced in your organization today, it should be adopted systematically and incrementally. In an existing organization, current operations must be maintained, yet practices need to be kept up-to-date in order for the company and its products to remain competitive. The way to implement a reuse strategy is to be mindful of and balance these two conflicting pressures. There should be some means to measure the progress of reuse in the organization. What percentage of a system is being reused? What are the size, complexity, and Jo Woodison Page 8 5/5/2003

9 interfaces of the reusable components? What is the savings in development time and cost. Use some economic guidelines to set your expectations. Some published rules of thumb are: A component has to be used three to five times to recover its initial creation cost and the ongoing support costs It costs 1.5 to 3 times as much to create and support a reusable component as it does to implement a one use only component It costs a quarter as much to utilize a reusable component as it does to develop a new one It takes two to three product cycles or about three years before the benefits of reuse are realized and cover the initial costs It is all object-oriented technology! It might be, but that alone does not grant you reuse. Keep in mind that it takes a specific reuse agenda, comprising of process and organizational steps and support, to create a reuse program, not just a single programming language or narrow methodology [Pittman] Perforce Best practices in Perforce are well documented in [Wingerd] High-Level Best Practices in SCM. These do not really change when structuring for reuse. To summarize some key points: Give each codeline a policy Give each codeline an owner Have a mainline or parent codeline Branch only when necessary Branch when you need to don t copy instead of branch Branch on purpose Branch late Integrate/merge often Keep it simple Perforce is a very versatile and flexible, yet strong SCM system. It allows all manner of possibilities and depot structures. It is advisable to keep the structure as simple as possible to meet your needs. While clever and tricky set-ups can be designed, one should be cautious with regards to confusing users to the point where they do the wrong thing or do not know how to work with the system, and be wary of creating an environment or structure which is difficult to maintain. 2. Conclusion Perforce is a very intuitive, flexible and strong SCM system. The simplicity yet versatility of its branching mechanism are arguably second to none. It provides us with reliable capabilities to put together any combination of artifacts and manipulate them in isolation or to be shared with other teams. Jo Woodison Page 9 5/5/2003

10 While tools will ultimately advance to support the evolution of our software development practices, at this stage, it is not Perforce that prevents us from reusing software. Leverage the benefits of the SCM system to help improve your productivity by sharing code, components and other artifacts. A. References Jacobson I., Griss M., and Jonsson P. (1997) Software Reuse: Architecture, Process and Organization for Business Success, ACM Press Books/Addison Wesley Longman McIlroy D. (1969) Mass produced software components NATO Conference on Software Engineering Pittman M. (1993) Lessons learned in managing object-oriented development. IEEE Software Wingerd L., Seiwald C. (1998) High-level best practices in software configuration management. Perforce Software The most recent version of this paper is located at About the Author Jo Woodison has been working in the computer industry for sixteen years. Her experience includes roles in product development, consulting, teaching and pre- and post-sales support. She has worked in many different environments across many different platforms, architectures, databases and of course, SCMs. Her SCM of choice is, naturally, Perforce. After working at Perforce Software (the company), Jo continued training and consulting by becoming a Perforce Consulting Partner and Certified Trainer. Originating from England but having spent most of the last decade in the USA, Jo is happy to be back in the US after living in Australia for almost two years. Jo Woodison Page 10 5/5/2003