CSE298 Final ReportIntroduction to Reuse Theory/Importance1.1 Software Waste1.2 Why ReuseProvide a powerful competitive advantage2 Component-Based Reuse and Related Research2.1 Desired Development ProcessFigure 2.1 Development Process2.2 CBD and Supplier/Consumer ModelWork at very low levels of detailTable 2.22.4 Complexity of ComponentFigure 2.4 Component2.5 Managing Components using SELECT productsFigure 2.6 Multi Repository Support2.6 CBD life circleFigure 2.7 CBD life circle2.7 Tools and SoftwareJavaBeansEnabler, Softlab2.8 IDC forecast CBD marketFigure 2.8 Forecast CBD MarketIV. DRE Simulation ToolAppendix A: ReferencesCSE298 Final ReportDesign Reuse ToolDavid MatteiJeff EllisJeff RobkeYi FangMay 4, 1998Introduction to Reuse Theory/Importance1.1 Software WasteThe software tradition is that the best way to serve the user/customer is by building each new system from scratch, without any notice or regard to the amount of "reinventing of the software wheel" that occurs.What has not been realized is the extent of unnecessary reinventing and the enormous waste of resources that occurs in most software projects. Countless software projects have wasted resources developing software components that bear a great similarity to those that already exist. Software waste is a very common occurrence because software systems tend to be more alike than different from one another. Unless specific measures are taken, software waste will continue to occur regardless of the type of technology used or the type of application system built. Newer technologies such as software automation, object orientation and client-server do not change this fact. However, they do make it easier to take advantage of software similarities. Some software similarities can be predefined and built into software tools (such as reusable code patterns in generators); others can be created as reusable components which are stored in software reuse libraries and made available to develop new systems. Because software systems typically are composed of similar parts, the majority of each new software system can and should be assembled from predefined reusable components. Although often overlooked, software reuse is the best answer to the decades-old software crisis.1.2 Why ReuseReuse is the process of implementing or updating software systems using existing software assets. The broader approach includes the reuse of all software items, such as designs, specifications, codes and documentation. Generally speaking, a component can be defined as an element with well-defined interfaces and behavior. The benefits of reusing will directly lead to reducing development costs, including the following:- Increase software productivity - Shorten software development time - Improve software system interoperability - Develop software with fewer people - Move personnel more easily from project to project - Reduce software development and maintenance costs - Produce more standardized software - Produce better quality software - Provide a powerful competitive advantage2 Component-Based Reuse and Related ResearchComponent-Based Development (CBD) is not only different from traditional development process, but also Object-Oriented Development (OOD). 2.1 Desired Development ProcessThe obstacle to reusing is that people in most cases have no idea of reusing in mind when they design the software at the very beginning. The required process should be like this, see Figure 2.1. Using top-down method to determine what is needed, using bottom-up method to determine what is available, and at the same time, take bothconcurrent and future projects into consideration. In fact, this is the critical part of reusing, because when people implement reusing idea, the benefit might not take effect immediately. But in the long run, it will pay back. Figure 2.1 Development Process2.2 CBD and Supplier/Consumer ModelIn the CBD, three roles are involved, they are consumer, supplier and manager, see Figure 2.2. This concept is much like a house-building or car manufacturer.Figure 2.2 CBD rolesCarmakers design and build new models based on components, which they either make themselves or buy from third party suppliers. Through these they assemble into the finished product. Each role, consumer, supplier and manager has his own activities. See Figure 2.3. Figure 2.3 Supplier/Consumer ModelThe Consumer takes existing components and assembles them to meet his demand. The activities of a consumer will include understanding solution requirements, analysis of new solutions based on requirements, design of new solutions based on supplied components, decisions on “re-use, buy or build” of components, overall project management of the new solution, defining extensions to components for suppliers and negotiating new features with suppliers. The Supplier develops new software componentsand makes them available to others in the market. Typical activities associated with suppliers include designing and building new components, advertising and publishing components, providing technical specifications of components, providing service and support, abstracting components from development, ensuring reliability, performance andscalability, and ensuring compatibility with other complementary products. The Managermanages the inventory of components from the supplier, and provides a stores management function, i.e. an interface between the supplier and the consumer. Activities will include storing and cataloging, publishing information about stocks of components held, providing information on compatibility between components, sourcing components from third parties, identifying dependencies between products, communicating and notifying changes to components, and specifications. See Figure 2.3.2.3 Components vs. ObjectsComponents are a higher order manifestation of object technology. Like objects, they are encapsulated. However, unlike objects, they limit inheritance between objects to the component boundary. That is, objects within a component can inherit characteristics freely from one another; however, no inheritance of characteristics can pass between components, except as formally defined by a component’s interfaces. While this difference is subtle, it is also profound and fundamental to the reliability of components to behave exactly as specified. For details, see table 2.1.Components ObjectsBusiness oriented Technology orientedCoarse grained Fine grainedStandards based Language
View Full Document
Unlocking...