Software Engineering - PDF Free Download

Software Engineering chap 4. Software Reuse 1 SuJin Choi, PhD. Sogang University Email: sujinchoi@sogang.ac.kr Slides modified, based on original slides by Ian Sommerville (Software Engineering 10 th Edition) 0 Software Reuse reuse is the use of previously acquired concepts or objects in a new situation. Don t Reinvent the Wheel Software engineering has been more focused on original development but it is recognised that to achieve better software, more quickly and at lower cost, we need a design process that is based on systematic software reuse. There has been a major switch to reuse-based development over the past 10 years. 1 1

Types of Reuse System reuse Complete systems, which may include several application programs may be reused. Application reuse An application may be reused either by incorporating it without change into other or by developing application families. Component reuse Components of an application from sub-systems to single objects may be reused. Object and function reuse Small-scale software components that implement a single well-defined object or function may be reused. 2 Other Types of Reuse Reuse can also include Requirements Documents Design Documents Design Patterns Software Architectures 3 2

Build for reuse, Build with reuse Build for reuse Abstraction: Identify units of reusable knowledge and concisely represent them in abstract form Classification: Store the reusable knowledge into a knowledge base that is indexed and classified Build with reuse Selection: Query the reusable knowledge into parameterized form (e.g. function with formal parameters) Specialization: Modify the reusable knowledge to fit new situations (e.g. function with actual parameters) Integration: Combine the reusable knowledge with your project (e.g. invocation, weaving, etc.) Source : [Krueger92] Software Reuse, ACM Survey. 1992 4 Economics of Software Reuse Build for reuse Build with reuse Economics of Product Lines 5 3

Benefits of software reuse Benefit Accelerated development Explanation Bringing a system to market as early as possible is often more important than overall development costs. Reusing software can speed up system production because both development and validation time may be reduced. Effective use of specialists Instead of doing the same work over and over again, application specialists can develop reusable software that encapsulates their knowledge. Increased dependability Reused software, which has been tried and tested in working systems, should be more dependable than new software. Its design and implementation faults should have been found and fixed. 6 Benefits of software reuse Benefit Lower development costs Reduced process risk Standards compliance Explanation Development costs are proportional to the size of the software being developed. Reusing software means that fewer lines of code have to be written. The cost of existing software is already known, whereas the costs of development are always a matter of judgment. This is an important factor for project management because it reduces the margin of error in project cost estimation. This is particularly true when relatively large software components such as subsystems are reused. Some standards, such as user interface standards, can be implemented as a set of reusable components. For example, if menus in a user interface are implemented using reusable components, all applications present the same menu formats to users. The use of standard user interfaces improves dependability because users make fewer mistakes when presented with a familiar interface. 7 4

Problems with reuse Problem Creating, maintaining, and using a component library Finding, understanding, and adapting reusable components Increased maintenance costs Explanation Populating a reusable component library and ensuring the software developers can use this library can be expensive. Development processes have to be adapted to ensure that the library is used. Software components have to be discovered in a library, understood and, sometimes, adapted to work in a new environment. Engineers must be reasonably confident of finding a component in the library before they include a component search as part of their normal development process. If the source code of a reused software system or component is not available then maintenance costs may be higher because the reused elements of the system may become increasingly incompatible with system changes. 8 Problems with reuse Problem Lack of tool support Not-invented-here syndrome Explanation Some software tools do not support development with reuse. It may be difficult or impossible to integrate these tools with a component library system. The software process assumed by these tools may not take reuse into account. This is particularly true for tools that support embedded systems engineering, less so for object-oriented development tools. Some software engineers prefer to rewrite components because they believe they can improve on them. This is partly to do with trust and partly to do with the fact that writing original software is seen as more challenging than reusing other people s software. 9 5

Open source software reuse Open source licensing The GNU General Public License (GPL) This is a so-called reciprocal license that means that if you use open source software that is licensed under the GPL license, then you must make that software open source. The GNU Lesser General Public License (LGPL) This is a variant of the GPL license where you can write components that link to open source code 10 Reuse planning factors Factor Development schedule Expected lifetime Development team Description If the software has to be developed quickly, use COTS integration rather than CBSE. Even though the fit to requirements may be imperfect, it minimizes the amount of development required. If the system lifetime is long the maintainability of the system is critical. Probably it is better to avoid reuse with unavailable or inaccessible code, such as COTS and systems from external suppliers; suppliers may not be able to continue support for the reused software. All reuse technologies are fairly complex. If the development teams background, skills and experience is related to any of the reuse areas, this is probably where you should turn in to. 11 6

Reuse planning factors Factor Criticality and nonfunctional requirements Application domain Application Platform Description If the systems is a critical system (e.g., has stringent performance requirements) it is probably better to avoid using unavailable or inaccessible source code or generator-based reuse (generate code from a reusable domain-specific representation of a system). If the system is for a specific application domain, such as manufacturing and medical information systems, several configurable vertical application reuse methods may be considered a good solution. There are several generic products that may be reused for configuring them to a local solution. Consider the platform your system is designed for; you may only be able to use specific components. Also, if the component models or generic application systems you are using are platform-specific, such as.net component models are specific to Microsoft platforms, you may only be able to reuse these. 12 Black-box reuse and White-box reuse 13 7

The reuse landscape reuse techniques 14 Approaches that support software reuse Approach Description Application frameworks Collections of abstract and concrete classes are adapted and extended to create application systems. Application system integration Architectural patterns Aspect-oriented software development Component-based software engineering Two or more application systems are integrated to provide extended functionality Standard software architectures that support common types of application system are used as the basis of applications. Shared components are woven into an application at different places when the program is compiled. Systems are developed by integrating components (collections of objects) that conform to component-model standards. 15 8

Approaches that support software reuse Approach Configurable application systems Design patterns ERP systems Legacy system wrapping Model-driven engineering Description Domain-specific systems are designed so that they can be configured to the needs of specific system customers. Generic abstractions that occur across applications are represented as design patterns showing abstract and concrete objects and interactions. Large-scale systems that encapsulate generic business functionality and rules are configured for an organization. Legacy systems are wrapped by defining a set of interfaces and providing access to these legacy systems through these interfaces. Software is represented as domain models and implementation independent models and code is generated from these models. 16 Approaches that support software reuse Approach Program generators Description A generator system embeds knowledge of a type of application and is used to generate systems in that domain from a user-supplied system model. Program libraries Class and function libraries that implement commonly used abstractions are available for reuse. Service-oriented systems Software product lines Systems of systems Systems are developed by linking shared services, which may be externally provided. An application type is generalized around a common architecture so that it can be adapted for different customers. Two or more distributed systems are integrated to create a new system. 17 9

Black-box reuse and White-box reuse 18 Reuse planning factors Factor Development schedule Expected lifetime Development team Description If the software has to be developed quickly, use COTS integration rather than CBSE. Even though the fit to requirements may be imperfect, it minimizes the amount of development required. If the system lifetime is long the maintainability of the system is critical. Probably it is better to avoid reuse with unavailable or inaccessible code, such as COTS and systems from external suppliers; suppliers may not be able to continue support for the reused software. All reuse technologies are fairly complex. If the development teams background, skills and experience is related to any of the reuse areas, this is probably where you should turn in to. 19 10

Application frameworks Frameworks are moderately large entities that can be reused. They are somewhere between system and component reuse. Frameworks are a sub-system design made up of a collection of abstract and concrete classes and the interfaces between them. The sub-system is implemented by adding components to fill in parts of the design and by instantiating the abstract classes in the framework. 22 Application Framework features Security classes to help implement user authentication (login) and access. Database support The framework may provide classes that provide an abstract interface to different databases. Session management Classes to create and manage sessions (a number of interactions with the system by a user) are usually part of a WAF. User interaction Most web frameworks now provide AJAX support, which allows more interactive web pages to be created. 23 12

Application system reuse An application system product is a software system that can be adapted for different customers without changing the source code of the system. Application systems have generic features and so can be used/reused in different environments. Application system products are adapted by using built-in configuration mechanisms that allow the functionality of the system to be tailored to specific customer needs. For example, in a hospital patient record system, separate input forms and output reports might be defined for different types of patient. 24 ERP systems An Enterprise Resource Planning (ERP) system is a generic system that supports common business processes such as ordering and invoicing, manufacturing, etc. These are very widely used in large companies - they represent probably the most common form of software reuse. The generic core is adapted by including modules and by incorporating knowledge of business processes and rules. 25 13

The architecture of an ERP system 26 ERP configuration Selecting the required functionality from the system. Establishing a data model that defines how the organization s data will be structured in the system database. Defining business rules that apply to that data. Defining the expected interactions with external systems. Designing the input forms and the output reports generated by the system. Designing new business processes that conform to the underlying process model supported by the system. Setting parameters that define how the system is deployed on its underlying platform. 27 14

Benefits of application system reuse As with other types of reuse, more rapid deployment of a reliable system may be possible. It is possible to see what functionality is provided by the applications and so it is easier to judge whether or not they are likely to be suitable. Some development risks are avoided by using existing software. However, this approach has its own risks, as I discuss below. Businesses can focus on their core activity without having to devote a lot of resources to IT systems development. As operating platforms evolve, technology updates may be simplified as these are the responsibility of the Commercial-Off-The-Shelf(COTS) product vendor rather than the customer. 28 Problems of application system reuse Requirements usually have to be adapted to reflect the functionality and mode of operation of the COTS product. The COTS product may be based on assumptions that are practically impossible to change. Choosing the right COTS system for an enterprise can be a difficult process, especially as many COTS products are not well documented. There may be a lack of local expertise to support systems development. The COTS product vendor controls system support and evolution. 29 15

COTS-solution and COTS-integrated systems Configurable application systems Single product that provides the functionality required by a customer Based around a generic solution and standardized processes Development focus is on system configuration System vendor is responsible for maintenance System vendor provides the platform for the system Application system integration Several heterogeneous system products are integrated to provide customized functionality Flexible solutions may be developed for customer processes Development focus is on system integration System owner is responsible for maintenance System owner provides the platform for the system 30 Configurable application systems Configurable application systems are generic application systems that may be designed to support a particular business type, business activity or, sometimes, a complete business enterprise. For example, an application system may be produced for dentists that handles appointments, dental records, patient recall, etc. Domain-specific systems, such as systems to support a business function (e.g. document management) provide functionality that is likely to be required by a range of potential users. 31 16

Integrated application systems Integrated application systems are applications that include two or more application system products and/or legacy application systems. You may use this approach when there is no single application system that meets all of your needs or when you wish to integrate a new application system with systems that you already use. 32 Service-oriented interfaces Application system integration can be simplified if a service-oriented approach is used. A service-oriented approach means allowing access to the application system s functionality through a standard service interface, with a service for each discrete unit of functionality. Some applications may offer a service interface but, sometimes, this service interface has to be implemented by the system integrator. You have to program a wrapper that hides the application and provides externally visible services. < Application wrapping > 33 17

Application system integration problems Lack of control over functionality and performance Application systems may be less effective than they appear Problems with application system inter-operability Different application systems may make different assumptions that means integration is difficult No control over system evolution Application system vendors not system users control evolution Support from system vendors Application system vendors may not offer support over the lifetime of the product 34 Component-based development Component-based software engineering (CBSE) is an approach to software development that relies on the reuse of entities called software components. It emerged from the failure of object-oriented development to support effective reuse. Single object classes are too detailed and specific. Components are more abstract than object classes and can be considered to be stand-alone service providers. They can exist as stand-alone entities. (picture : http://article.sapub.org/10.5923.j.se.20120204.07.html) 19/11/2014 35 18

CBSE and design principles CBSE is based on sound software engineering design principles: Components are independent so do not interfere with each other; Component implementations are hidden; Communication is through well-defined interfaces; One components can be replaced by another if its interface is maintained; Component infrastructures offer a range of standard services. 19/11/2014 36 Component characteristics Component characteristic Composable Deployable Description For a component to be composable, all external interactions must take place through publicly defined interfaces. In addition, it must provide external access to information about itself, such as its methods and attributes. To be deployable, a component has to be self-contained. It must be able to operate as a stand-alone entity on a component platform that provides an implementation of the component model. This usually means that the component is binary and does not have to be compiled before it is deployed. If a component is implemented as a service, it does not have to be deployed by a user of a component. Rather, it is deployed by the service provider. 19/11/2014 37 19

Component characteristics Component characteristic Documented Independent Standardized Description Components have to be fully documented so that potential users can decide whether or not the components meet their needs. The syntax and, ideally, the semantics of all component interfaces should be specified. A component should be independent it should be possible to compose and deploy it without having to use other specific components. In situations where the component needs externally provided services, these should be explicitly set out in a requires interface specification. Component standardization means that a component used in a CBSE process has to conform to a standard component model. This model may define component interfaces, component metadata, documentation, composition, and deployment. 19/11/2014 38 Component as a service provider The component is an independent, executable entity. It does not have to be compiled before it is used with other components. The services offered by a component are made available through an interface and all component interactions take place through that interface. The component interface is expressed in terms of parameterized operations and its internal state is never exposed. 19/11/2014 39 20

CBSE processes CBSE processes are software processes that support component-based software engineering. They take into account the possibilities of reuse and the different process activities involved in developing and using reusable components. Development for reuse This process is concerned with developing components or services that will be reused in other applications. It usually involves generalizing existing components. Development with reuse This process is the process of developing new applications using existing components and services. 19/11/2014 40 CBSE Processes 41 21

CBSE Process example - W Model The W Model for Component-based Software Development[online]. Online Available:http://www.cs.man.ac.uk/~kung-kiu/pub/seaa11b.pdf. 42 Software Product Line Engineering The strategic reuse of core assets in the development of individual products Targeted at specific marketing goals Strategic reuse implies preplanning that identifies and exploits commonality over time and space Identifies and manages variation across planned family of products 43 22

Reuse History (source : http://resources.sei.cmu.edu/asset_files/presentation/2007_017_001_24249.pdf) 44 The Real Truth About Reuse Reuse means taking something developed for one system and using it in another. The XYZ System is built with 80% reuse. A statement like this is vacuous. It is not clear what is being reused. It is not clear that the reuse has any benefit. Reusing code or components without an architecture focus and without pre-planning results in short-term perceived win long-term costs and problems failure to meet business goals (source : http://resources.sei.cmu.edu/asset_files/presentation/2007_017_001_24249.pdf) 45 23

Software Reuse Fact And Fiction The Fiction: And then we ll be able to construct software systems by picking out parts and plugging them together, just like Legos The Fact: It s more like having a bathtub full of Tinkertoys, Legos, Erector Set parts, Lincoln Logs, Block City, and six other incompatible kits -- picking out parts that fit specific functions and expecting them to fit together. (source : http://resources.sei.cmu.edu/asset_files/presentation/2007_017_001_24249.pdf) 46 Software Product Line A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. [SEI] 47 24

Software Product Lines Software product lines or application families are applications with generic functionality that can be adapted and configured for use in a specific context. A software product line is a set of applications with a common architecture and shared components, with each application specialized to reflect different requirements. Adaptation may involve: Component and system configuration; Selecting from a library of existing components; Modifying components to meet new requirements; Adding new components to the system. 48 SPL Processes Three Essential Activities All three activities are interrelated and highly iterative There is a strong feedback loop between the core assets and the products Strong management is needed to invest resources in the development [Clements and Northrop 2002. Software Product Line] 49 25

Questions & Answers 50 26