Software reuse

Rapid Application Development (RAD) emphasizes user involvement, prototyping, software reuse, the use of automated tools, and small development teams. The RAD life eyele, sometimes ealled a spiral life cycle, consists of four basic phases ... 

This chapter examines varions validation strategies that can be adopted around organizational roles, outsourcing, standardizing computer apphcations and software reuse, segregating GxP aspects of integrated systems, retrospective validation of legacy systems, and use of statistical techniques to support validation. 

Leveson, Nancy, and Kathryn Weiss. Making embedded software reuse practical and safe. Foundations of Software Engineering, Newport Beach, Nov. 2004. 

Komiya, S. A model for the recording and reuse of software design decisionsand decision rationale. In Proceedings of the 3rd International Conference on Software Reuse Advances in Software Reusability (ICSR 1994), Rio de Janeiro, Brazil, November 1994, pp. 200-201... 

See Commercial Ojf-the-Shelf (COTS), Commercial Off-the-Shelf (COTS) Safety, and Software Reuse for additional related information. 

We have not included any attributes in a molecule to store its name or list of names. Clearly, it would be desirable to store both a common, short name as well as a systematic name for a molecule it would also be desirable to allow for additional names, and provide methods to manipulate these attributes. In our OOP representation of biochemical systems, we will provide a generic mechanism which relies on a superclass called named object . Then, all we need to do is designate the named object as a superclass of molecules all the attributes and methods are then automatically inherited. This is an example of software reuse facilitated by OOP. Once we abstract a very generic behavior in one system, we can use that same behavior in many other systems, through the class hierarchy and multiple inheritance mechanisms of OOP. 

Sutcliffe and N.A.M. 1991] A.G. Sutcliffe and M. N.A.M., Analogical software reuse Empirical investigations of analogy based reuse and software engineering practices, Acra Psychologica, vol. 78, pp.173-197, 1991. 

The key to making a large variety of software products in a short time is to make one piece of development effort serve for many products. Reuse does not mean that you can cut-and-paste code The proliferation that results, with countless local edits, rapidly becomes an expensive maintenance nightmare. 

Make an early architectural decision about how much you will tradeoff performance, seamlessness, reuse, code flexibility, and so on. If your clients shout for little functional enhancements every day (something that is typical for in-house financial trading software), optimize the underlying communications and infrastructure but leave the business model pristine. But if your software will be embedded in a million car engines for 10 years, optimize for performance. 

Components are software artifacts and represent the work of software developers and their tools objects are identifiable instances created in running systems by executing code that is a part of some component. So, in that strict sense, an object is not a component. It is the component code that is reused—the calendar package, perhaps with some customizable properties—rather than a specific calendar instance and its state. 

Something like 70% of work on the average software design is done after its first installation. This means that an approach, such as reuse, aimed at reducing costs must be effective in that maintenance phase and not just in the initial design (see Figure 11.1). 

Some components can be reused more widely than others. Some objects, routines, or patterns might be useful only in several parts of the same software product but if it is a big product or a product family, several teams may need coordinating. 

For developing reusable assets, you would generally want to apply many of the techniques in this book. Reuse means investing in the quality of software the old argument that we don t have time to document can have only a negative effect in a reuse culture. The development of products or applications will also use many of the same techniques, but the process can be quite different (for example, see Section 10.11, Heterogenous Components). 

Reuse of software is not simply a matter of cut-and-paste it should involve the reuse of interface specifications before implementation code is reused. Successful reuse poses many organizational challenges (culture, development processes, and so on) as well as technical ones (designing components that are adaptable to many different contexts and devising techniques for plugging in the adaptations). 

So that users (whether external or software) will have a clear understanding of what to expect from your component. This is especially important for a component that will be reused in different contexts that you are aware of— we are no longer in the days when the designer of the only component that talks to yours is sitting in the next cubicle. 

Importance of Interfaces. At one time, modularity in the software world was principally motivated by the need to divide a big job into manageable tasks. The interfaces of your module worked with the modules of the people in the neighboring cubicles it was easy to discuss any issues about the interfaces. In a culture that reuses the pieces, you are unlikely to know all the components that yours will connect to You must therefore be much more careful about your interface definitions (and about reading those of others). 

Service-oriented architecture (SOA) is a hot topic these days and is considered by many people to be the enterprise computing framework of the future. In SOA, each software unit runs on a piece of hardware as a service that can be called by many different consumers. For example, a compound registration service can be called by a library enumeration tool and a chemistry e-notebook to fulfill compound registration tasks. The most popular SOA is Web services that are based on HTTP and XML or SOAP standards although SOA as a concept has existed for awhile and is not limited to Web services. SOA has a lot of advantages, the most important of which is code reuse and improved productivity. However, it also presents a lot of challenges. 

Please note that layers and tiers are two different concepts. Tiers mean the physical separation of subsystems—each subsystem runs on a different hardware or the same hardware but in different processes. In a multitiered system, the interaction between the subsystems is accomplished through remote procedure calls (RPCs). Any RPC involves network overhead and therefore has a performance penalty whether the remote procedure is on a separate hardware or on the same physical hardware but in a different process. Layers, on the other hand, are logical separations of the subsystems. Each layer can run on a different physical tier, or all layers can run on a single tier. The purpose of physical tiers is to leverage distributed hardware resources or to reuse a piece of software that is deployed on a different hardware that your system wants to leverage. The purpose of layered software architecture is to separate the system into highly cohesive and loosely coupled modules (see Chapter 2 for software development principles). 

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. 

---