21-05-2013, 03:35 PM
Software Reuse
Software Reuse[.docx (Size: 15.63 KB / Downloads: 24)
Abstract of Software Reuse
Software reusability is the likelihood a piece of source code that can be used again to add new functionalities with slight or no modification. Programmers have always reused sections of code, functions and procedures. Code reuse is the idea that a partial or complete computer program written at one time is being or should be used in another program written at a later time. The concept of software reuse emerged as a recognized area after proposed basing of industry on reusable components. To achieve full potential of reuse, we need to focus our attention on development for reuse.
Organizations implementing systematic software reuse programs must be able to measure their progress and identify the most effective reuse strategies. Metrics and models with various reuse readiness levels can be used to measure reuse and reusability. Current reuse techniques focus on the reuse of software artifacts on the basis of desired functionality. Nonfunctional properties of a software system are also crucial. Quality concerns, therefore, should also be the focus for software reuse. This Mathematical Theory of Intelligence structures objects in such a way that they become maximally reusable, interoperable and archival. The theory claims that reusability of an object is maximized if the object itself is defined as having been produced by maximizing reuse of the operations that were used to produce it. Many metrics and models have been developed for software reuse and reusability
Introduction of Software Reuse
Software reuse is the process of creating software systems from existing software rather than building software systems from scratch. Something that was originally written for a different project will usually be recognized as reuse. Code reuse is the idea that a partial or complete computer program written at one time can be, should be, or is being used in another program written at a later time. The reuse of programming code is a common technique which attempts to save time and energy by reducing redundant work. Software assets, or components, include all software
products, from requirements and proposals, to specifications and designs, high level designs, data formats, algorithms to user manuals and test suites.
Anything that is produced from a software development effort can potentially be reused. Software developed and used repeatedly by the same people on the same project, Product maintenance and new product versions, use of operating systems, database management systems, and other system tools doesn’t amount to reuse. Software engineering has been more focused on original development but it is now recognised that to achieve better software, more quickly and at lower cost, we need to adopt a design process that is based on systematic software reuse.
For systematic reuse to succeed organizations must recognize that good components, frameworks, and software architectures require time to design, implement, optimize, validate, apply, maintain, and enhance. Creating reusable software assets requires a mature organization whose developers and architects can distinguish key sources of variability and commonality in their application domain. Identifying and separating these concerns for complex networked applications requires an iterative development process since it's hard to design reusable artifacts correctly the first time using a topdown “waterfall” software lifecycle model.
Why Software Reuse:
A good software reuse process facilitates the increase of productivity, quality, and reliability, performance and the decrease of costs, effort, risk and implementation time. An initial investment is required to start a software reuse process, but that investment pays for itself in a few reuses. In short, the development of a reuse process and repository produces a base of knowledge that improves in quality after every reuse, minimizing the amount of development work required for future projects, and ultimately reducing the risk of new projects that are based on repository knowledge
Reusing code saves programming time, which reduces costs. If one person or team has already solved a problem, and they share the solution, there's no need to solve the problem again (with some potential caveats see Drawbacks).
• Sharing code can help prevent bugs by reducing the amount of total code that needs to be written to perform a set of tasks. Generally, the more code a system contains the more bugs it's likely to have. The shared code can also be tested separately from the applications which use it.
• Separating code into common libraries lets programmers specialize in their particular strengths. A security library, for example, can be built by securityexperts while a user interface which uses the library can let UI experts focus on
their tasks.
• Repeatedly, separating code into specialized libraries lets each be tuned for performance, security, and special cases. For example, a Python application might delegate graphics functionality to a C library for performance.
Definition
Electronic payment systems come in many forms including digital checks, debit cards, credit cards, and stored value cards. The usual security features for such systems are privacy (protection from eavesdropping), authenticity (provides user identification and message integrity), and no repudiation (prevention of later denying having performed a transaction) .
The type of electronic payment system focused on in this paper is electronic cash . As the name implies, electronic cash is an attempt to construct an electronic payment system modelled after our paper cash system. Paper cash has such features as being: portable (easily carried), recognizable (as legal tender) hence readily acceptable, transferable (without involvement of the financial network), untraceable (no record of where money is spent), anonymous (no record of who spent the money) and has the ability to make "change." The designers of electronic cash focused on preserving the features of untraceability and anonymity. Thus, electronic cash is defined to be an electronic payment system that provides, in addition to the above security features, the properties of user anonymity and payment untraceability
Electronic Payment
The term electronic commerce refers to any financial transaction involving the electronic transmission of information. The packets of information being transmitted are commonly called electronic tokens . One should not confuse the token, which is a sequence of bits, with the physical media used to store and transmit the information.
We will refer to the storage medium as a card since it commonly takes the form of a wallet-sized card made of plastic or cardboard. (Two obvious examples are credit cards and ATM cards.) However, the "card" could also be, e.g., a computer memory.
A particular kind of electronic commerce is that of electronic payment . An electronic payment protocol is a series of transactions, at the end of which a payment has been made, using a token issued by a third party. The most common example is that of credit cards when an electronic approval process is used. Note that our definition implies that neither payer nor payee issues the token.
Conceptual Framework
There are four major components in an electronic cash system: issuers, customers, merchants, and regulators. Issuers can be banks, or non-bank institutions; customers are referred to users who spend E-Cash; merchants are vendors who receive E-Cash, and regulators are defined as related government agencies. For an E-Cash transaction to occur, we need to go through at least three stages:
1. Account Setup: Customers will need to obtain E-Cash accounts through certain issuers. Merchants who would like to accept E-Cash will also need to arrange accounts from various E-Cash issuers. Issuers typically handle accounting for customers and merchants.
2. Purchase: Customers purchase certain goods or services, and give the merchants tokens which represent equivalent E-Cash. Purchase information is usually encrypted when transmitting in the networks.
3. Authentication: Merchants will need to contact E-Cash issuers about the purchase and the amount of E-Cash involved. E-Cash issuers will then authenticate the transaction and approve the amount E-Cash involved