How to design conventional components - Program Design Language and Comparison of Design Notation

Conventional component level design requires the representation of data structures, interfaces, and algorithms for a program module. The designer uses one of a number of design notations that represent component level detail in either graphical, tabular, or text based formats.

PROGRAM DESIGN LANGUAGE
Program design language is also called pseudo code. In this, vocabulary of one language and overall syntax of another language is used. Program design language(PDL) is used as a generic reference for a design language.
The difference between a PDL and a real programming language lies in the use of narrative text embedded directly within PDL statements.
- PDL cannot be complied.
- Tools can translate PDL into a programming language.
- These tools also produce nesting maps, design operation index, cross reference tables and other information.
- PDL may be simple transposition of a language.
- Basic PDL syntax should include constructs for component definition, interface description, data declaration, block structuring, condition and repetition constructs.
- PDL can be extended to include keywords for multitasking, interrupt handling, interprocess synchronization.

COMPARISON OF DESIGN NOTATION
- Design notation leads to procedural representation which is easy to understand and review.
- Design notation should enhance "code to" ability.
- Design representation must be easily maintainable so that design always represents the program correctly.
- PDL offers the best combination of characteristics.
- However, it does not follow that other design notations are inferior.
- Activity diagrams and flowcharts provides a perspective on control flow that many designers prefer.

Component Level Design - Designing Class based Components - Cohesion

Cohesion in context with component level design refers that a component or class encapsulates only attributes and operations that are closely related to each other and to the class or component itself.

TYPES OF COHESION

Functional
It is exhibited mainly by operations. This type of cohesion occurs when a module performs one and only one computation and then returns a result.
Layer
It is exhibited by packages, components, and classes. This type of cohesion occurs when a higher layer accesses the services of a lower layer, but lower layers do not access higher layers.
Temporal
Operations that are performed to reflect a specific behavior or state.
Procedural
Components and operations are grouped together. It allows one to be invoked immediately after preceding one was invoked. It is done even if there is no data is passed between them.
Communicational
Operation on same data are defined in one class. Classes and components that exhibit functional, layer, and communicational cohesion are easy to implement, test and maintain.
Sequential
Components and operations are grouped in such a manner that the first one provides input to the second one and so on.
Utility
Components, classes, or operations exist in the same category but are otherwise unrelated are grouped together. This type is less used.

What is white Box Testing and why we do it ?

White box testing involves looking at the structure of the code. When you know the internal structure of a product, tests can be conducted to ensure that the internal operations are performed according to the specifications and all the internal components have been adequately exercised. In other words, white box testing tends to involve the coverage of the specification in the code.

The control structure of the procedural design to derive test cases is used during white box testing. Using the methods of WBT, a tester can derive the test cases that guarantee that all independent paths within a module have been exercised at least once, exercise all logical decisions on their true and false values, execute all loops at their boundaries and within their operational bounds and exercise internal data structures to ensure their validity.

White box testing is done because black box testing uncover sorts defects in the program. These defects are:
- Logic errors and incorrect assumptions are inversely proportional to the probability that a program path will be executed. Errors tend to creep into our work when we design and implement functions, conditions or controls that are out of the program.
- The logical flow of the program is sometimes counter intuitive, meaning that our unconscious assumptions about flow of control and data may lead to design errors that are uncovered only when path testing starts.
- Typographical errors are random, some of which will be uncovered by syntax checking mechanisms but others will go undetected until test begins.

All we need to do in white box testing is to define all logical paths, develop test cases to exercise them and evaluate results i.e. generate test cases to exercise the program logic exhaustively. We need to know the program well, the specifications and the code to be tested, related documents should be available to us.