Design Verification and Validation

8/3/2019 Design Verification and Validation

1/22

Principles of Software Testing

What is not Software Testing? Test is not debugging. Debugging has the goal to remove errors. The

existence and the approximate location of the error are known. Debuggingis not documented. There is no specification and there will be no record(log) or report. Debugging is the result of testing but never asubstitution for it.

Test can never find 100% of the included errors. There will be always arest of remaining errors which can not be found. Each kind of test will finda different kind of errors.

Test has the goal to find errors and not their reasons. Therefore the

activity of testing will not include any bug fixing or implementation offunctionality. The result of testing is a test report. A tester must not modifythe code he is testing, by no means! This has to be done by the developerbased on the test report he receives from the tester.

What is Software Testing?

Test is a formal activity. It involves a strategy and a systematicapproach. The different stages of tests supplement each other. Tests are

always specified and recorded. Test is a planned activity. The workflow and the expected results are

specified. Therefore the duration of the activities can be estimated. Thepoint in time where tests are executed is defined.

Test is the formal proof of software quality.

Overview of Test Methods

Static testsThe software is not executed but analyzed offline. In this category would be codeinspections (e.g. Fagan inspections), Lint checks, cross reference checks, etc.

Dynamic testsThis requires the execution of the software or parts of the software (using stubs). It canbe executed in the target system, an emulator or simulator. Within the dynamic teststhe state of the art distinguishes between structural and functional tests.


2/22

Structural testsThese are so called "white-box tests" because they are performed with the knowledgeof the source code details. Input interfaces are stimulated with the aim to run throughcertain predefined branches or paths in the software. The software is stressed withcritical values at the boundaries of the input values or even with illegal input values.

The behavior of the output interface is recorded and compared with the expected(predefined) values.

Functional testsThese are the so called "black-box" tests. The software is regarded as a unit withunknown content. Inputs are stimulated and the values at the output results arerecorded and compared to the expected and specified values.

Test by progressive Stages

The various tests are able to find different kinds of errors. Therefore it is not enough torely on one kind of test and completely neglect the other. E.g. white-box tests will beable to find coding errors. To detect the same coding error in the system test is verydifficult. The system malfunction which may result from the coding error will notnecessarily allow conclusions about the location of the coding error. Test thereforeshould be progressive and supplement each other in stages in order to find each kindof error with the appropriate method.

Module testA module is the smallest compilable unit of source code. Often it is too small to allowfunctional tests (black-box tests). However it is the ideal candidate for white-box tests.These have to be first of all static tests (e.g. Lint and inspections) followed by dynamictests to check boundaries, branches and paths. This will usually require theemployment of stubs and special test tools.

Component testThis is the black-box test of modules or groups of modules which represent certainfunctionality. There are no rules about what can be called a component. It is just whatthe tester defined to be a component, however it should make sense and be a testableunit. Components can be step by step integrated to bigger components and tested assuch.

Integration testThe software is step by step completed and tested by tests covering a collaboration ofmodules or classes. The integration depends on the kind of system. E.g. the stepscould be to run the operating system first and gradually add one component after theother and check if the black-box tests still run (the test cases of course will increasewith every added component). The integration is still done in the laboratory. It may bedone using simulators or emulators. Input signals may be stimulated.


3/22

System testThis is a black-box test of the complete software in the target system. Theenvironmental conditions have to be realistic (complete original hardware in thedestination environment).

Which Test finds which Error?

Possible errorCan be best

found by Example

Syntax errors Compiler, LintMissing semicolons, Values defined but notinitalized or used, order of evaluationdisregarded.

Data errorsSoftwareinspection, module

Overflow of variables at calculation, usage ofinappropriate data types, values not


4/22

tests initialized, values loaded with wrong data orloaded at a wrong point in time, lifetime ofpointers.

Algorithm and logical

errors

Softwareinspection, moduletests

Wrong program flow, use of wrong formulas

and calculations.

Interface errors

Softwareinspection, moduletests, componenttests.

Overlapping ranges, range violation (min. andmax. values not observed or limited),unexpected inputs, wrong sequence of inputparameters.

Operating systemerrors, architectureand design errors

Design inspection,integration tests

Disturbances by OS interruptions or hardwareinterrupts, timing problems, lifetime andduration problems.

Integration errorsIntegration tests,system tests

Resource problems (runtime, stack, registers,memory, etc.)

System errors System tests Wrong system behaviour, specification errors

/======================================/

Metrics Used In Testing

In this tutorial you will learn about metrics used in testing, The Product Quality Measures -

1. Customer satisfaction index, 2. Delivered defect quantities, 3. Responsiveness

(turnaround time) to users, 4. Product volatility, 5. Defect ratios, 6. Defect removal

efficiency, 7. Complexity of delivered product, 8. Test coverage, 9. Cost of defects, 10.

Costs of quality activities, 11. Re-work, 12. Reliability and Metrics for Evaluating Application

System Testing.

Ads

The Product Quality Measures:

1. Customer satisfaction index

This index is surveyed before product delivery and after product delivery

(and on-going on a periodic basis, using standard questionnaires).The following are

analyzed:


5/22

Number of system enhancement requests per year

Number of maintenance fix requests per year

User friendliness: call volume to customer service hotline

User friendliness: training time per new user

Number of product recalls or fix releases (software vendors)

Number of production re-runs (in-house information systems groups)

2. Delivered defect quantities

They are normalized per function point (or per LOC) at product delivery (first 3 months orfirst year of operation) or Ongoing (per year of operation) by level of severity, by category

or cause, e.g.: requirements defect, design defect, code defect, documentation/on-line help

defect, defect introduced by fixes, etc.

3. Responsiveness (turnaround time) to users

Turnaround time for defect fixes, by level of severity

Time for minor vs. major enhancements; actual vs. planned elapsed time

4. Product volatility

Ratio of maintenance fixes (to repair the system & bring it into compliance with

specifications), vs. enhancement requests (requests by users to enhance or change

functionality)

5. Defect ratios

Defects found after product delivery per function point.

Defects found after product delivery per LOC


6/22

Pre-delivery defects: annual post-delivery defects

Defects per function point of the system modifications

6. Defect removal efficiency

Number of post-release defects (found by clients in field operation), categorized by level

of severity

Ratio of defects found internally prior to release (via inspections and testing), as a

percentage of all defects

All defects include defects found internally plus externally (by customers) in the first

year after product delivery

7. Complexity of delivered product

McCabe's cyclomatic complexity counts across the system

Halsteads measure

Card's design complexity measures

Predicted defects and maintenance costs, based on complexity measures

8. Test coverage

Breadth of functional coverage

Percentage of paths, branches or conditions that were actually tested

Percentage by criticality level: perceived level of risk of paths

The ratio of the number of detected faults to the number of predicted faults.

9. Cost of defects

Business losses per defect that occurs during operation

Business interruption costs; costs of work-arounds

Lost sales and lost goodwill


7/22


8/22

Number of product recalls or fix releases

Number of production re-runs as a ratio of production runs

Metrics for Evaluating Application System Testing:

Metric = Formula

Test Coverage = Number of units (KLOC/FP) tested / total size of the system. (LOC

represents Lines of Code)

Number of tests per unit size = Number of test cases per KLOC/FP (LOC represents Lines

of Code).

Acceptance criteria tested = Acceptance criteria tested / total acceptance criteria

Defects per size = Defects detected / system size

Test cost (in %) = Cost of testing / total cost *100

Cost to locate defect = Cost of testing / the number of defects located

Achieving Budget = Actual cost of testing / Budgeted cost of testing

Defects detected in testing = Defects detected in testing / total system defects

Defects detected in production = Defects detected in production/system size


9/22

Quality of Testing = No of defects found during Testing/(No of defects found during

testing + No of acceptance defects found after delivery) *100

Effectiveness of testing to business = Loss due to problems / total resources processedby the system.

System complaints = Number of third party complaints / number of transactions

processed

Scale of Ten = Assessment of testing by giving rating in scale of 1 to 10

Source Code Analysis = Number of source code statements changed / total number of

tests.

Effort Productivity = Test Planning Productivity = No of Test cases designed / Actual

Effort for Design and Documentation

Test Execution Productivity = No of Test cycles executed / Actual Effort for testing

/==============S/W Design Validation/Verifications=============/

These are FDA's (an agency notorious for their strict definitions...) of design verification and

design validation:

Design verification means confirmation by examination and provision of objective evidencethat specified requirements have been fulfilled.

Design validation means establishing by objective evidence that device (product)specifications conform with user needs and intended use(s).

In other words:


10/22

You verify a design by checking drawings and specs, running simulations, checking that all

design requirements have been addressed, that calculations are correct, etc. It's mainly a

"paper" exercise and when you are through with it you should be quite confident that thedesign is complete and that a product that will eventually be built according to thosedrawings and specs stands a good chance of conforming to the requirements in the realworld.

You validate a design by trying out actual products (an initial run or batch of products), built

as above by real workers, installed and operated in the real environment of use by realoperators, etc. It's the proverbial proof of the pudding where you can catch errors and otherproblems that escaped all former verification efforts ... and others bugs that might havecrept in later on.

/=========================/

After reading many of the responses to the verification/validation problem, I keep

wondering why, after all these years, this is still debated. I am also surprised at howunhelpful most of the examples posted on this list appear to be, because they often do not

accurately differentiate between the two concepts. I hope the description below will help.

Verification means examining all of the things you have anticipated the customer will wantthe product to do, and checking to see if the product does those things the way you haveanticipated the customer will want. Verification is about checking the things you have

intentionally designed into the product and making sure the product meets those design

requirements. It is about whether you were smart enough to _meet_ your specified designgoals.

Validation means checking to see if the product does what the customer (or user) actually

wants the product to do under real-world conditions, or as-close-to-real-world conditions asyou can possibly simulate. Validation encompasses all of the things that can be verified, as

well as all of the things that cannot -- i.e., all of the things that the product designers mightnever have anticipated the customer might want or expect the product to do. It is aboutwhether you were smart enough to specify the _right_ design goals.

Of course, in the ideal world, product designers would correctly anticipate all of the thingsthe customer would ever want the product to do, they would specify all the right design

goals, and they would meet them. As a result, the validation would reveal nothing beyondwhat the verification covered.

In the real world, product designers sometimes don't correctly anticipate all of the thingsthe customer will want the product to do, and they discover that the product exhibits certain

unanticipated or undesirable characteristics, from the user's perspective.

Thus, the difference between verification and validation is that verification checks the

adequacy of the design with respect to _identified_ design goals, whereas validation checksthe adequacy of the design with respect to both identified and _unidentified_ customerexpectataions.

If you want an example of the difference between verification and validation, consider the

difference between the foot-operated controls and the hand-operated controls on most cars.If you rent a car, even a model you have never driven before, you always know which foot


11/22

pedal makes the car go and which foot pedal makes the car stop. In fact, virtually any

driver can easily get into any rental car -- at night or in the rain -- and operate the foot

pedals to make the car go and stop. This is an example of a design that passes bothverification and validation, because the pedals work as the designers intended (verification)and they also work as the user expects, even under foreseeable adverse use conditions(validation) such as darkness or rain.

Now consider the hand-operated controls. I don't know about you, but there have been

times when I have rented a car and simply not known how to operate some of the criticalcontrols. For example, the stalk to the left of the steering wheel might operate theheadlights, it might operate the windshield wipers, it might operate both, or it might

operate neither. If the controls differ from the car I own and drive daily, I might reach for

the stalk in an effort to turn on the windshield wipers, and instead turn on the headlights.This is an example of a design that passes verification, because the controls perform their

stated function; but it fails validation, because the controls do not work as the user expects

under foreseeable conditions of use. Indeed, in this example, a user's inability to correctlyoperate the vehicle controls could, at a critical moment, cause the user to be unable to seeoncoming hazards on the road, possibly with fatal consequences.

This illustrates one more thing about verification and validation: instead of "intended use,"

which many people think is relevant to a design validation, I find it far more helpful to think

in terms of "reasonably foreseeable use," "reasonably foreseeable user" and "reasonablyforeseeable use environment." The important distinction is that what is "intended" is never,

ever enough: one must also consider things that are "unintended." The phrase "reasonablyforeseeable" includes both, and is, in fact, the standard that U.S. tort law applies in cases of

product liability. It should therefore be the minimum standard that should be used byproduct designers.

Another very simple example is the common screwdriver. Intended use: turn screws.

Intended use environment: home and shop. Intended user: Joe Sixpack. Simple, right? Nowconsider what is "reasonably foreseeable." Reasonably foreseeable uses might include: turn

screws, pry open paint cans, chisel holes in wood, remove dried spackling compound, chiseloff rusted bolts.... Reasonably foreseeable use environments: home and shop, chemistry

lab, salt-water pier, high tension electrical tower, off-shore oil rig.... Reasonably foreseeable

user: Joe Sixpack, his neighbor Martha with arthritis in her hands, her 10-year-old grandsonJohnny with small hands, his sister Sue who is left handed, their mother Jan who works in

that chemical lab with all sorts of corrosive materials, her husband Jim who works on thosehigh tension electrical towers wearing heavily insulated gloves, Jim's brother Dave whoworks on that off-shore oil rig and who's hands are always covered with oil....

Get the idea? If you only think in terms of what is "intended," you might not think hardenough about all the ways your product might be used. If so, your product might actually

be hazardous to use or, at the very least, you might miss an important market segment

that your competitor will be very happy to fill at your expense -- and, by doing so, reduceyour market share, eat your lunch, and take away the income you were planning to save foryour kid's college education or your early retirement.

And that, as I see it, is the important difference between verification and validation.

/============================/


12/22

Software Testing Life Cycle Models

Software Testing Life Cycle ModelsThe various activities which are undertaken when developing software are commonlyModeled as a software development lifecycle. The software development lifecycle

begins with the identification of a requirement for software and ends with the formalverification of the developed software against that requirement. The softwaredevelopment lifecycle does not exist by itself; it is in fact part of an overall Productlifecycle. Within the product lifecycle, software will undergo maintenance to correcterrors and to comply with changes to requirements. The simplest overall form is Wherethe product is just software, but it can become much more complicated, with Multiplesoftware developments each forming part of an overall system to comprise a Product.There are a number of different models for software development lifecycles. One thingWhich all models have in common, is that at some point in the lifecycle, software has tobe tested. This paper outlines some of the more commonly used software developmentLifecycles, with particular emphasis on the testing activities in each model. A software

life cycle model depicts the significant phases or activities of a software project fromconception until the product is retired. It specifies the relationship between projectphases, including transition criteria, feedback mechanisms, milestones, baselines,reviews, and deliverables. Typically, a life cycle model addresses the following phasesof a software project: requirement phase, design phase, implemenentation, integration,testing, operations and maintenance. Much of the motivation behind utilizing a life cyclemodel is to provide structure. Life cycle models describe the inter relationship betweensoftware development phases .the common life cycle models are;

V-mode of SDLC

V & V PROCESS MODEL :V&V Model is Verification & Validation Model.In This Model We work simultaneouslyDevelopment and Testing.In this Model One V for Verification and one For Validationfirst 'V' we follow SDLC(software Development Life Cycle) and Second 'V' we followSTLC-(Software Testing Life Cycle).

Testing normally done in a large system in 2 parts. The functional verification

and validation against the Requirement specification and Performanceevaluation against the indicated requirements.

Testing activity is involved right from the beginning of the project.

Use of V&V process model increases the rate of success in a project

development company to deliver the application on time and increases the

cost effectiveness.
http://testingsolution.blogspot.com/2006/12/software-testing-life-cycle-models.htmlhttp://testingsolution.blogspot.com/2006/12/v-mode-of-sdlc.htmlhttp://testingsolution.blogspot.com/2006/12/v-mode-of-sdlc.htmlhttp://testingsolution.blogspot.com/2006/12/software-testing-life-cycle-models.html


13/22

Testing Related ActivitiesDuring Requirement Phase

Creation and finalization of testing template.

Creation of test plan and test strategy .

Capturing Acceptance criteria and preparation of acceptance test plan.

Capturing Performance Criteria of the software requirements.

Testing activities in Design Phase

Develop test cases to ensure that product is on par with Requirement

Specification document.

Verify Test Cases & Test Scripts by peer reviews.

Preparation of traceability matrix from system requirements.

Testing activities in Unit Testing Phase

Unit test is done for validating the product with respect to client requirements.

Testing can be in multiple rounds.

Defects found during system test should be logged in to defect tracking

system for the purpose of resolving and tracking.

Test logs and defects are captured and maintained.

Review of all test documents.

Testing activities in Integration Testing Phase

This testing is done in parallel with integration of various applications or

components.

Testing the product with its external and internal interfaces without using

drivers and stubs.
http://bp1.blogger.com/_IMmmNaDrX3U/RYuWPvFqyKI/AAAAAAAAAAw/ptYBqKAxgTs/s1600-h/vv-1.bmp


14/22

Incremental approach while integrating the interfaces.

Performance testing

This is done to validate the performance criteria of the product/ application.

This is non-functional testing.

Business Cycle testing

This refers to end to end testing of real life like business scenarios.

Testing activities during Release phase

Acceptance testing is conducted at the customer location.

Resolves all defects reported by the customer during Acceptance testing.

Conduct Root Cause Analysis (RCA) for those defects reported by customer

during acceptance testing.

Waterfall Model

Waterfall Model

The waterfall Model is an engineering model designed to be applied to the developmentof software.The idea is the following: there are different stages to the development andthe outputs of the First Stage "Flow" into the second stage and these outputs "flow" intothe third stage and so on.there are Usually five stages in this model of softwareDevelopment.
http://testingsolution.blogspot.com/2006/12/waterfall-model.htmlhttp://bp3.blogger.com/_IMmmNaDrX3U/RYuX8PFqyLI/AAAAAAAAAA8/JGt2I46J_4Q/s1600-h/wfm-1.bmphttp://testingsolution.blogspot.com/2006/12/waterfall-model.html


15/22

Stages of Water Fall ModelRequirement analyis and Planninng:- In This stage the requirements of the "To bedeveloped Software" are established.These are usually the services it will provide,itsconstraints and Goalsof the Software.Once theae are Established they Have to bedefined such a way that are usable in the next Stage.This Stage is often Preludes by a

Feasibility or a Feasible study is included in this stage.the Feasibility study includesQuestions like;Should we develop the Software,what are the alternatives? It could becalled the conception of a software project and might be seen as the very begining ofthe life cycle.

Prototype Model

Spiral Model
http://testingsolution.blogspot.com/2006/12/prototype-model.htmlhttp://testingsolution.blogspot.com/2006/12/spiral-model.htmlhttp://bp2.blogger.com/_IMmmNaDrX3U/RYuYw_FqyMI/AAAAAAAAABI/vXKVXQSQF2I/s1600-h/prototype+model-1new.bmphttp://testingsolution.blogspot.com/2006/12/spiral-model.htmlhttp://testingsolution.blogspot.com/2006/12/prototype-model.html


16/22

Iteration Model

/================================/

Coupling (computer programming)

From Wikipedia, the free encyclopedia
http://testingsolution.blogspot.com/2006/12/iteration-model.htmlhttp://bp1.blogger.com/_IMmmNaDrX3U/RYuazvFqyOI/AAAAAAAAABg/2AsMu54MLwo/s1600-h/iterative+modal+new-1.bmphttp://bp0.blogger.com/_IMmmNaDrX3U/RYuc4fFqyPI/AAAAAAAAABs/KLEkEWjuI6o/s1600-h/spiral+model.bmphttp://bp1.blogger.com/_IMmmNaDrX3U/RYuazvFqyOI/AAAAAAAAABg/2AsMu54MLwo/s1600-h/iterative+modal+new-1.bmphttp://bp0.blogger.com/_IMmmNaDrX3U/RYuc4fFqyPI/AAAAAAAAABs/KLEkEWjuI6o/s1600-h/spiral+model.bmphttp://testingsolution.blogspot.com/2006/12/iteration-model.html


17/22

Jump to:navigation,search

This article needs additionalcitationsforverification.

Please helpimprove this articleby addingreliable references. Unsourced material may bechallenged

andremoved.(September 2010)

Incomputer science,coupling or dependency is the degree to which each program modulerelies on each one of the other modules.

Coupling is usually contrasted withcohesion. Low coupling often correlates with high cohesion,and vice versa. Thesoftware quality metricsof coupling and cohesion were invented byLarry

Constantine, an original developer of Structured Design[1]

who was also an early proponent of

these concepts (see alsoSSADM). Low coupling is often a sign of a well-structuredcomputer

systemand a good design, and when combined with high cohesion, supports the general goals ofhigh readability and maintainability.

Contents

[hide]

1 Types of coupling

o 1.1 Object-oriented programming

2 Disadvantages

3 Performance issues

4 Solutions 5 Coupling versus Cohesion

6 Module coupling

7 See also

8 References

Types of coupling
http://en.wikipedia.org/wiki/Coupling_(computer_programming)#mw-headhttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#mw-headhttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#mw-headhttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#p-searchhttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#p-searchhttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#p-searchhttp://en.wikipedia.org/wiki/Wikipedia:Citing_sources#Inline_citationshttp://en.wikipedia.org/wiki/Wikipedia:Citing_sources#Inline_citationshttp://en.wikipedia.org/wiki/Wikipedia:Citing_sources#Inline_citationshttp://en.wikipedia.org/wiki/Wikipedia:Verifiabilityhttp://en.wikipedia.org/wiki/Wikipedia:Verifiabilityhttp://en.wikipedia.org/wiki/Wikipedia:Verifiabilityhttp://en.wikipedia.org/w/index.php?title=Coupling_(computer_programming)&action=edithttp://en.wikipedia.org/w/index.php?title=Coupling_(computer_programming)&action=edithttp://en.wikipedia.org/w/index.php?title=Coupling_(computer_programming)&action=edithttp://en.wikipedia.org/wiki/Wikipedia:Identifying_reliable_sourceshttp://en.wikipedia.org/wiki/Wikipedia:Identifying_reliable_sourceshttp://en.wikipedia.org/wiki/Wikipedia:Identifying_reliable_sourceshttp://en.wikipedia.org/wiki/Template:Citation_neededhttp://en.wikipedia.org/wiki/Template:Citation_neededhttp://en.wikipedia.org/wiki/Template:Citation_neededhttp://en.wikipedia.org/wiki/Wikipedia:Verifiability#Burden_of_evidencehttp://en.wikipedia.org/wiki/Wikipedia:Verifiability#Burden_of_evidencehttp://en.wikipedia.org/wiki/Wikipedia:Verifiability#Burden_of_evidencehttp://en.wikipedia.org/wiki/Computer_sciencehttp://en.wikipedia.org/wiki/Computer_sciencehttp://en.wikipedia.org/wiki/Computer_sciencehttp://en.wikipedia.org/wiki/Cohesion_(computer_science)http://en.wikipedia.org/wiki/Cohesion_(computer_science)http://en.wikipedia.org/wiki/Cohesion_(computer_science)http://en.wikipedia.org/wiki/Software_metrichttp://en.wikipedia.org/wiki/Software_metrichttp://en.wikipedia.org/wiki/Software_metrichttp://en.wikipedia.org/wiki/Larry_Constantinehttp://en.wikipedia.org/wiki/Larry_Constantinehttp://en.wikipedia.org/wiki/Larry_Constantinehttp://en.wikipedia.org/wiki/Larry_Constantinehttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#cite_note-0http://en.wikipedia.org/wiki/Coupling_(computer_programming)#cite_note-0http://en.wikipedia.org/wiki/Structured_Systems_Analysis_and_Design_Methodologyhttp://en.wikipedia.org/wiki/Structured_Systems_Analysis_and_Design_Methodologyhttp://en.wikipedia.org/wiki/Structured_Systems_Analysis_and_Design_Methodologyhttp://en.wikipedia.org/wiki/Computerhttp://en.wikipedia.org/wiki/Computerhttp://en.wikipedia.org/wiki/Computerhttp://en.wikipedia.org/wiki/Computerhttp://en.wikipedia.org/wiki/Coupling_(computer_programming)http://en.wikipedia.org/wiki/Coupling_(computer_programming)http://en.wikipedia.org/wiki/Coupling_(computer_programming)http://en.wikipedia.org/wiki/Coupling_(computer_programming)#Types_of_couplinghttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Types_of_couplinghttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Object-oriented_programminghttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Object-oriented_programminghttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Disadvantageshttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Disadvantageshttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Performance_issueshttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Performance_issueshttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Solutionshttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Solutionshttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Coupling_versus_Cohesionhttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Coupling_versus_Cohesionhttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Module_couplinghttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Module_couplinghttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#See_alsohttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#See_alsohttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Referenceshttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Referenceshttp://en.wikipedia.org/wiki/File:Question_book-new.svghttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Referenceshttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#See_alsohttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Module_couplinghttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Coupling_versus_Cohesionhttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Solutionshttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Performance_issueshttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Disadvantageshttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Object-oriented_programminghttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#Types_of_couplinghttp://en.wikipedia.org/wiki/Coupling_(computer_programming)http://en.wikipedia.org/wiki/Computerhttp://en.wikipedia.org/wiki/Computerhttp://en.wikipedia.org/wiki/Structured_Systems_Analysis_and_Design_Methodologyhttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#cite_note-0http://en.wikipedia.org/wiki/Larry_Constantinehttp://en.wikipedia.org/wiki/Larry_Constantinehttp://en.wikipedia.org/wiki/Software_metrichttp://en.wikipedia.org/wiki/Cohesion_(computer_science)http://en.wikipedia.org/wiki/Computer_sciencehttp://en.wikipedia.org/wiki/Wikipedia:Verifiability#Burden_of_evidencehttp://en.wikipedia.org/wiki/Template:Citation_neededhttp://en.wikipedia.org/wiki/Wikipedia:Identifying_reliable_sourceshttp://en.wikipedia.org/w/index.php?title=Coupling_(computer_programming)&action=edithttp://en.wikipedia.org/wiki/Wikipedia:Verifiabilityhttp://en.wikipedia.org/wiki/Wikipedia:Citing_sources#Inline_citationshttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#p-searchhttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#mw-head


18/22

Conceptual model of coupling

Coupling can be "low" (also "loose" and "weak") or "high" (also "tight" and "strong"). Some

types of coupling, in order of highest to lowest coupling, are as follows:

Content coupling (high)

Content coupling is when one module modifies or relies on the internal workings of another

module (e.g., accessing local data of another module).

Therefore changing the way the second module produces data (location, type, timing) will lead

to changing the dependent module.

Common coupling

Common coupling is when two modules share the same global data (e.g., a global variable).

Changing the shared resource implies changing all the modules using it.

External coupling

External coupling occurs when two modules share an externally imposed data format,

communication protocol, or device interface.

Control coupling

Control coupling is one module controlling the flow of another, by passing it information on

what to do (e.g., passing a what-to-do flag).

Stamp coupling (Data-structured coupling)
http://en.wikipedia.org/wiki/File:Coupling_sketches_cropped_1.svghttp://en.wikipedia.org/wiki/File:Coupling_sketches_cropped_1.svghttp://en.wikipedia.org/wiki/File:Coupling_sketches_cropped_1.svghttp://en.wikipedia.org/wiki/File:Coupling_sketches_cropped_1.svg


19/22

Stamp coupling is when modules share a composite data structure and use only a part of it,

possibly a different part (e.g., passing a whole record to a function that only needs one field of

it).

This may lead to changing the way a module reads a record because a field that the module

doesn't need has been modified.

Data coupling

Data coupling is when modules share data through, for example, parameters. Each datum is an

elementary piece, and these are the only data shared (e.g., passing an integer to a function that

computes a square root).

Message coupling (low)

This is the loosest type of coupling. It can be achieved by state decentralization (as in objects)

and component communication is done via parameters or message passing (seeMessage

passing).

No coupling

Modules do not communicate at all with one another.

Object-oriented programming

Subclass Coupling

Describes the relationship between a child and its parent. The child is connected to its parent,

but the parent isn't connected to the child.

Temporal coupling

When two actions are bundled together into one module just because they happen to occur at

the same time.

Disadvantages

Tightly coupled systems tend to exhibit the following developmental characteristics, which are

often seen as disadvantages:

1. A change in one module usually forces aripple effectof changes in other modules.

2. Assembly of modules might require more effort and/or time due to the increased inter-module

dependency.

3. A particular module might be harder to reuse and/or test because dependent modules must beincluded.

Performance issues
http://en.wikipedia.org/wiki/Message_passinghttp://en.wikipedia.org/wiki/Message_passinghttp://en.wikipedia.org/wiki/Message_passinghttp://en.wikipedia.org/wiki/Message_passinghttp://en.wikipedia.org/wiki/Ripple_effecthttp://en.wikipedia.org/wiki/Ripple_effecthttp://en.wikipedia.org/wiki/Ripple_effecthttp://en.wikipedia.org/wiki/Ripple_effecthttp://en.wikipedia.org/wiki/Message_passinghttp://en.wikipedia.org/wiki/Message_passing


20/22

Whether loosely or tightly coupled, a system's performance is often reduced by message and

parameter creation, transmission, translation and interpretation overhead. Seeevent-drivenprogramming.

Message Creation Overhead and Performance

Since all messages and parameters must possess particular meanings to be consumed (i.e.,

result in intended logical flow within the receiver), they must be created with a particular

meaning. Creating any sort of message requires overhead in either CPU or memory usage.

Creating a single integer value message (which might be a reference to a string, array or data

structure) requires less overhead than creating a complicated message such as a SOAP message.

Longer messages require more CPU and memory to produce. To optimize runtime performance,

message length must be minimized and message meaning must be maximized.

Message Transmission Overhead and Performance

Since a message must be transmitted in full to retain its complete meaning, messagetransmission must be optimized. Longer messages require more CPU and memory to transmit

and receive. Also, when necessary, receivers must reassemble a message into its original state

to completely receive it. Hence, to optimize runtime performance, message length must be

minimized and message meaning must be maximized.

Message Translation Overhead and Performance

Message protocols and messages themselves often contain extra information (i.e., packet,

structure, definition and language information). Hence, the receiver often needs to translate a

message into a more refined form by removing extra characters and structure information

and/or by converting values from one type to another. Any sort of translation increases CPU

and/or memory overhead. To optimize runtime performance, message form and content must

be reduced and refined to maximize its meaning and reduce translation.

Message Interpretation Overhead and Performance

All messages must be interpreted by the receiver. Simple messages such as integers might not

require additional processing to be interpreted. However, complex messages such as SOAP

messages require a parser and a string transformer for them to exhibit intended meanings. To

optimize runtime performance, messages must be refined and reduced to minimize

interpretation overhead.

Solutions

One approach to decreasing coupling isfunctional design, which seeks to limit the

responsibilities of modules along functionality, coupling increases between two classes A and B

if:
http://en.wikipedia.org/wiki/Event-driven_programminghttp://en.wikipedia.org/wiki/Event-driven_programminghttp://en.wikipedia.org/wiki/Event-driven_programminghttp://en.wikipedia.org/wiki/Event-driven_programminghttp://en.wikipedia.org/wiki/Functional_designhttp://en.wikipedia.org/wiki/Functional_designhttp://en.wikipedia.org/wiki/Functional_designhttp://en.wikipedia.org/wiki/Functional_designhttp://en.wikipedia.org/wiki/Event-driven_programminghttp://en.wikipedia.org/wiki/Event-driven_programming


21/22

A has an attribute that refers to (is of type) B.

A calls on services of an object B.

A has a method that references B (via return type or parameter).

A is a subclass of (or implements) class B.

Low coupling refers to a relationship in which one module interacts with another module througha simple and stable interface and does not need to be concerned with the other module's internal

implementation (seeInformation Hiding).

Systems such asCORBAorCOMallow objects to communicate with each other without having

to know anything about the other object's implementation. Both of these systems even allow for

objects to communicate with objects written in other languages.

Coupling versus Cohesion

Coupling and Cohesion are the two terms which very frequently occur together. Together they

talk about the quality a module should have. Coupling talks about the inter dependenciesbetween the various modules while cohesion describes how related functions within a moduleare. Low cohesion implies that module performs tasks which are not very related to each other

and hence can create problems as the module becomes large.

Module coupling

Coupling in Software Engineering[2]describes a version of metrics associated with this concept.

For data and control flow coupling:

di: number of input data parameters

ci: number of input control parameters

do: number of output data parameters

co: number of output control parameters

For global coupling:

gd: number of global variables used as data

gc: number of global variables used as control

For environmental coupling:

w: number of modules called (fan-out)

r: number of modules calling the module under consideration (fan-in)
http://en.wikipedia.org/wiki/Information_Hidinghttp://en.wikipedia.org/wiki/Information_Hidinghttp://en.wikipedia.org/wiki/Information_Hidinghttp://en.wikipedia.org/wiki/CORBAhttp://en.wikipedia.org/wiki/CORBAhttp://en.wikipedia.org/wiki/CORBAhttp://en.wikipedia.org/wiki/Component_Object_Modelhttp://en.wikipedia.org/wiki/Component_Object_Modelhttp://en.wikipedia.org/wiki/Component_Object_Modelhttp://en.wikipedia.org/wiki/Coupling_(computer_programming)#cite_note-Pressman-1http://en.wikipedia.org/wiki/Coupling_(computer_programming)#cite_note-Pressman-1http://en.wikipedia.org/wiki/Coupling_(computer_programming)#cite_note-Pressman-1http://en.wikipedia.org/wiki/Component_Object_Modelhttp://en.wikipedia.org/wiki/CORBAhttp://en.wikipedia.org/wiki/Information_Hiding


22/22

Coupling(C)makes the value larger the more coupled the module is. This number ranges fromapproximately 0.67 (low coupling) to 1.0 (highly coupled)

For example, if a module has only a single input and output data parameter

If a module has 5 input and output data parameters, an equal number of control parameters, and

accesses 10 items of global data, with a fan-in of 3 and a fan-out of 4,

Date post:	07-Apr-2018
Category:	Documents
Upload:	bhagirath-singh
View:	239 times
Download:	0 times

Design Verification and Validation

Documents