A Matlab Implementation of The Back-Propagation Approach for Reusability of Software Components

8/6/2019 A Matlab Implementation of The Back-Propagation Approach for Reusability of Software Components

http://slidepdf.com/reader/full/a-matlab-implementation-of-the-back-propagation-approach-for-reusability-of 1/5

(IJCSIS) International Journal of Computer Science and Information Security,

Vol. 9, No. 5, May 2011

A Matlab Implementation Of The Back-

Propagation Approach for Reusability of Software

ComponentsMeenakshi Sharma1

Sri Sai College Of Engg. & Tech., Pathankot2

HOD CSE2

[email protected]

Priyanka Kakkar2

Sri Sai College Of Engg. & Tech., Pathankot2 Mtech CSE

4th sem2

[email protected]

Dr. Parvinder Sandhu3

Rayat and Bhara College OF Engg. And Tech.3

HOD CSE3

Abstract- Before the age of the computer, there were many

mathematical problems that humans could not easily solve,

or more precisely (and this distinction is extremely

important) humans were too slow in solving. Computers

enabled these often simple but slow and tedious tasks to be

performed quickly and accurately. The first problems solved

with computers were calculating equations to resolve

important physical problems, and later displaying a nice

GUI, making word processors and so on. However, there are

many common tasks which are trivial for humans to perform

(without even any conscious effort) yet which are extremely

difficult to formulate in a way that a computer may easily

solve.Keywords:- Reusability,JISC,GUI, back-propagation

algorithm.

I. INTRODUCTION (H EADING 1)

Generalising the Widrow-Hoff learning rule to multiple-layer

networks and non-linear[1][2] differentiable transfer functions

created back propagation. Input vectors and the corresponding

output vectors are used to train a network until it can

approximate a function, associate input vectors with specific

output vectors, or classify input vectors in an appropriate way

as defined by you.

Networks with biases, a sigmoid layer, and a linear output

layer are capable of approximating any function[3] with a

finite number of discontinuities. Standard back propagation is

a gradient descent algorithm, as is the Widrow-Hoff learning

rule. There are a number of variations [4][5][6]on the basic

algorithm, which are based on other standard optimisation

techniques, such as conjugate gradient and Newton methods.

The term back propagation refers to the process by

which derivatives of network error, with respect to network

weights and biases, can be computed can compute derivatives

of network error. This process can be used with a number[7]

of different optimisation strategies. The architecture of a

multilayer network is not completely constrained by the

problem[2] to be solved. The number of inputs to the network

is constrained by the problem, and the number of neurons in

the output layer is constrained by the number of outputs

required by the problem. However, the number of layersbetween network inputs and the output layer and the sizes of

the layers are up to the user.

A unit in the output layer determines its activity by following

a two step procedure.

298 http://sites.google.com/site/ijcsis/ISSN 1947-5500




Vol. 9, No. 5, May 2011

• First, it computes the total weighted input xj, using

the formula:

where yi is the activity level of the jth unit in the previous

layer and W ij is the weight of the connection between the ith

and the jth unit.

• Next, the unit calculates the activity y j using some

function of the total weighted input. Typically we use the

sigmoid function:

Once the activities of all output units have been determined,

the network computes the error E, which is defined by theexpression:

where y j is the activity level of the jth unit in the top layer and

d j is the[8] desired output of the jth unit.

The back-propagation algorithm consists of four steps:

1. Compute how fast the error changes as the activity of anoutput unit is changed. This error derivative (EA) is the

difference between the actual and the desired activity.

2. Compute how fast the error changes as the total input

received by an output unit is changed. This quantity (EI) is the

answer from step 1 multiplied by the rate at which the output

of a unit changes as its total input is changed.

3. Compute how fast the error changes as a weight on the

connection into an output unit is changed. This quantity (EW)

is the answer from step 2 multiplied by the activity level of the

unit from which the connection emanates.

4. Compute how fast the error changes as the activity of a unit

in the previous layer is changed. This crucial step[9] allows

back propagation to be applied to multilayer networks. When

the activity of a unit in the previous layer changes, it affectsthe activities of all the output units to which it is connected. So

to compute the overall effect on the error, we add together all

these separate effects on output units. But each effect is simple

to calculate. It is the answer in step 2 multiplied by the weight

on the connection to that output unit.

By using steps 2 and 4, we can convert the EAs of one

layer of units into EAs for the previous layer. This

procedure can be repeated to get the EAs for as many

previous layers as desired. Once we know the EA of a

unit, we can use steps 2 and 3 to compute the

[10]EWs on its incoming connections.

2.Methodology:

A. Pilot interviews

Early interviews were conducted with three projects on a pilot

basis to allow us to refine our interview structure and to

develop and modify our explicit methodology.

B. Detailed Evaluation Criteria document

In close consultation with JISC programme staff, we drafted,

amended, and agreed this document, which defines the

software evaluation criteria to be used to evaluate the 22

DeLeTools projects. This document, which is available on the

JISC website, is closely related to the accompanying

Evaluation Methods and Tools document mentioned below:

the criteria document describes the tasks to be done and what

criteria we use to [11]approach them, and the methods

document describes how we should do it.

C. Detailed Evaluation Methods and Tools document

Similarly, we prepared this document, which details the

methods used to assess, test, and evaluate the software outputs

of the 22 projects in the DeLeTools strand of the JISC e-

Learning Programme. Using the Software Quality Evaluation

299 http://sites.google.com/site/ijcsis/

ISSN 1947-5500




Vol. 9, No. 5, May 2011

Criteria[12] Document as a high level guide, the Detailed

Evaluation Methods and Tools document outlines the specific

methods proposed and references the criteria that these

methods address. The latter document states:

Our approach is based not only on the quality standards to

which JISC require the 22 projects to adhere and the

individual standards which have been identified by theprojects themselves, but also the maintainability, extendibility

and the general robustness of the 22 projects' code and

software. Code review will be a key focus of the evaluation of

each project. Other evaluation and testing methods will vary

according to the project and its outputs.

D. Summary of methods used

We used the following methods:

1. Brief Online Study.

2. Face to face interview with project staff and follow up by

email and phone (full accounts of interviews appear in

Appendix).

3. Selective checking of sections of code (per-project

summary of code checking results appears below). [13]

4. Lab testing the software on various platforms and in various

conditions (per-project summary of test results appears below

– full results have been made available to projects and to

programme staff).

5. Usability walkthrough and application of heuristics (per-

project summary of usability results appears below – full

results have been made available to projects and to programme

staff).

6. Brief and selective desk audit of project documentation,

version tracking, and testing procedures (the results of the

audit were fed into the software evaluation and gave the testers

insight into which areas of the tool might need particular[14]

attention, also alerting the testing team to any issues and bugs

prior to testing and informing some project-specific questionsasked during the interviews).

II. CRITERIA USED IN EVALUATION

The criteria used in the evaluation[15] and a brief summary of

the measures or "questions asked" appears below.

A. Match of actual software output to planned output

Measures

Are the outputs materially different from those planned? Are

they so delayed that the project will not, or is unlikely to,

deliver those outputs?

B. Use of quality plan Measures

Has the quality plan been completed and followed? Has it

been used to aid implementing the JISC Software Quality

Assurance Policy? Has it been updated? Has it been used in

creative[16] and unforeseen ways?

C. Compliance with the JISC Open Source Policy Measures

The (draft) JISC Open Source Policy (May 2004) itself details

the necessary areas of compliance.

D. Compliance with Open Standards Measures

Have the Open Standards outlined in the quality plan been

used? If not, have other Open Standards been used?

E. Quality control procedures Measures

Are there any documented formal or informal quality control

procedures? Is there evidence of them being used? Can we

reproduce testing procedures? Are issues and changes being

documented?

F. Project specific documentation Measures

In addition to the project plan and quality plan, we asked each

project to give us access to:

• The technical specification of their product

• a summary of their testing procedures

• a copy of their test plan

• reports from version tracking software

• code documentation. [17]

It was anticipated that there would be little or no end-user

documentation, and that few projects would have a complete

technical specification document.

3.Results:


ISSN 1947-5500




Vol. 9, No. 5, May 2011

Figure 6.1- Main Menu

Figure6.2- choosing Option

Figure6.3- Selecting Source File

Figure6.4- Final result.

4.CONCLUSION

Despite some reservations stated above about the ESI

questionnaire, the survey has achieved its goal of providing

benchmark information about adoption of best practice by

software developers in Queensland. At the time of writing,

about 40 responses have been received by SEA in WesternAustralia and the WA findings will provide interesting

comparisons against those from Queensland. The proportion

and best practice adoption level of COTS developers will be of

particular interest in relation to the Queensland findings.

Although all the follow-up meetings for the Process

Improvement Program[18] have not yet been completed,

feedback from the participant organisations has been positive.

Thompson (1994) is concerned that technology transfer of

appropriate software engineering practices is inhibited by

management and developers because they often have poor

attitudes towards change. He advises that the software

development community needs a[19] much better

understanding of the practices, their use and potential benefits.

It is hoped that through the publication of these success stories

from the Process Improvement Program, local developers will

appraise such information in an impartial manner and adopt

best practice willingly and with enthusiasm.

A valuable outcome of the Process Improvement Program is

the development of the RAPID evaluation tool which provides

a realistic option to very small development organisations

which traditionally lack the resources to undertake full-blown

software process assessments. With the Australian software

community dominated by very small organisations (88 percent

have less than five staff), this program may provide valuable

opportunities for such developers to evaluate and improve

their processes, thereby achieving success in domestic and

global markets.

Funding has been made available to provide full SPICE

assessments and mentoring for two of the Process

Improvement Program participants. It is anticipated that case

studies, in a similar format to the SPIRE (Software Process

Improvement in Regional Europe) Case Studies will be

compiled and published. The Federal Government's support

for software incubators, such as the one operating at SEA Qld,

promises an opportunity for small start-up companies to

overcome traditional[20] resource limitations. These stepsmay facilitate the achievement of the goal of improved global

competitiveness for the Australian software industry.

5.REFERENCES

[1] Sandhu P. S. and Singh H., "A Reusability Evaluation

Model for OO-Based Software Components", International

Journal of Computer Science, vol. 1, no. 4, 2006, pp. 259-264.

[2] Neural Networks at Pacific Northwest National Laboratory

http://www.emsl.pnl.gov:2080/docs/cie/neural/neural.homepa

ge.html

[3] Artificial Neural Networks in Medicinehttp://www.emsl.pnl.gov:2080/docs/cie/techbrief/NN.techbrief

.ht

[4] A Novel Approach to Modelling and Diagnosing the

Cardiovascular System

http://www.emsl.pnl.gov:2080/docs/cie/neural/papers2/keller.

wcnn95.abs.html

[5] Electronic Noses for Telemedicine

http://www.emsl.pnl.gov:2080/docs/cie/neural/papers2/keller.c


ISSN 1947-5500




Vol. 9, No. 5, May 2011

cc95.abs.html

[6] G. Caldiera and V. R. Basili, Identifying and Qualifying

Reusable Software Components, IEEE Computer, (1991) 61-

70.

[7] W. Tracz, A Conceptual Model for Mega programming,

SIGSOFT Software Engineering Notes, 16( 3, July 1991) 36-

45.

[8] Stephen R. Schach and X. Yang, Metrics for targeting

candidates for reuse: an experimental approach, ACM, (SAC

1995) 379-383.

[9] J. S. Poulin, Measuring Software Reuse–Principles,

Practices and Economic Models (Addison-Wesley, 1997).

[10] W. Humphrey, Managing the Software Process, SEI

Series in Software Engineering (Addison-Wesley, 1989).

[11] L. Sommerville, Software Engineering, 4th edn.

(Addison-Wesley, 1992).

[12] R. S. Pressman, Software Engineering: A Practitioner’s

Approach, 5th edn. (McGraw-Hill, 2005).

[13] G. Boetticher and D. Eichmann, A Neural Network Paradigm for Characterizing Reusable Software, Proc. of the

1st Australian Conference on Software Metrics (18-19

November 1993).

[14] S. V. Kartalopoulos, Understanding Neural Networks and

Fuzzy Logic-Basic Concepts and Applications (IEEE Press,

1996)153-160.

[15] Parvinder Singh Sandhu and Hardeep Singh, “Software

Reusability Model for Procedure Based Domain-Specific

Software Components”, International Journal of Software

Engineering & Knowledge Engineering (IJSEKE), Vol. 18,

No. 7, 2008, pp. 1–19.

[16] Parvinder Singh Sandhu and Hardeep Singh, "AutomaticQuality Appraisal of Domain-Specific Reusable Software

Components", Journal of Electronics & Computer Science,

vol. 8, no. 1, June 2006, pp. 1-8.

[17] Parvinder Singh Sandhu and Hardeep Singh, "A

Reusability Evaluation Model for OO-Based Software

Components", International Journal of Computer Science, vol.

1, no. 4, 2006, pp. 259-264.

[18] Parvinder Singh Sandhu and Hardeep Singh , “Automatic

Reusability Appraisal of Software Components using Neuro-

Fuzzy Approach, International Journal Of Information

Technology, vol. 3, no. 3, 2006,pp. 209-214.

[19] Parvinder S. Sandhu and Hardeep Singh, “A Fuzzy Based

Approach for the Prediction of Quality of Reusable Software

Components”, IEEE 14th International Conference on

Advanced Computing & Communications (ADCOM 2006),

NIT Suratkal, Dec. 20 – 23, 2006, pp. 761-764.

[20] Parvinder S. Sandhu and Hardeep Singh, “A Neuro-Fuzzy

Based Software Reusability Evaluation System with

Optimized Rule Selection”, IEEE 2nd International

Conference on Emerging Technologies (IEEE ICET 2006),

Peshawar, Pakistan, Nov. 13-14, 2006,

pp. 664-669.


ISSN 1947-5500

A Matlab Implementation of The Back-Propagation Approach for Reusability of Software Components

Documents

Transcript of A Matlab Implementation of The Back-Propagation Approach for Reusability of Software Components