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.

How to design conventional components - Graphical Design Notation and Tabular Design Notation

There were some logical constructs developed from which any program could be formed. Each construct has a logical structure. The constructs are sequence, condition, and repetition.
- Sequence implements processing the steps that are essential in the specification of any algorithm.
- Condition provides the facility for selected processing based on some logical occurrence.
- Repetition allows for looping.
Structured programming is a design technique that constrains logic flow to three constructs: sequence, condition and repetition. The structured constructs were supposed to limit the procedural design of software to a small number of predictable operations.

GRAPHICAL DESIGN NOTATION
Activity diagram allows a designer to represent sequence,condition and repetition. Flowchart, like an activity diagram, is quite simple pictorially.
The dogmatic use of only structured constructs can introduce inefficiency when an escape from a set of nested loops or nested conditions is required. Additional complication of all logical tests along the path of escape can hinder the control flow, increase the possibility of error and have a negative impact.
There are two options:
- procedural representation is redesigned so that escape branch is not required at a nested location.
- structured constructs are violated in a controlled manner; that is , a constrained branch out of the nested flow is redesigned.

TABULAR DESIGN NOTATION
Decision tables translates actions and conditions in a tabular form. It is difficult to misinterpret. A decision table is divided into quadrants:
- Upper left quadrant: contains a list of all conditions.
- Lower left quadrant: contains a list of all actions that are possible based on combinations of conditions.
- Right hand quadrant: a matrix that indicates condition combinations and corresponding actions. Each column of matrix may be interpreted as a processing rule.

-

What are different steps while conducting component level designing?

The following steps represent a typical task set for component level design, when it is applied for an object oriented system. If you are working in a non object oriented environment, the first three steps focus on the refinement of data objects and processing functions identified as part of analysis model.

STEP 1: Identify all design classes that correspond to the problem domain.
STEP 2: Identify all design classes that correspond to the infrastructure domain.
STEP 3: Elaborate all design classes that are not acquired as reusable components.
In addition to all interfaces, attributes, operations, design heuristics i.e cohesion and coupling should be considered during elaboration.
- Specify message details when classes or components collaborate.
Structure of messages that are passed between objects within a system are shown as component level design proceeds.
- Identify appropriate interfaces for each component.
Interface is an abstract class that provides a controlled connection between design classes. So interfaces should be identified appropriately.
- Elaborate attributes and define data types and data structures required to implement them.
The programming language that is to be used in the project typically is a factor in the definition of the data structure and types used to describe attributes. When the component level design process is started, the name of attributes is used; as the design proceeds the UML attribute format is increasingly used.
- Describe processing flow within each operation in detail.
There are two ways to do this; through a UML activity diagram or a programming language based pseudocode. The elaboration of each software component is by doing a number of iterations and in each iteration a step-wise refinement concept is used.
STEP 4: Describe persistent data sources and identify the classes required to manage them.
As the design elaboration proceeds, an additional data should be provided about the structure and organization of these data sources which are initially specified as part of architectural design.
STEP 5: Develop and elaborate behavioral representations for a class or component.
In order to depict the externally observable behavior of the system as well as that of individual analysis classes, UML state diagrams are used. As a part of component level design, modeling the behavior of a design class may be sometimes required. The instantiation of a design class a s program executes is also known as the dynamic behavior of the object. This behavior is impacted by the current state of object as well as external events.
STEP 6: Elaborate deployment diagrams to provide additional implementation detail.
When component level design is being done, in order to make deployment diagrams simple to read and comprehend, the location of components(individual components) are generally not depicted.
STEP 7: Factor every component level design representation and always consider alternatives.
The first component level model that is created will not be consistent, complete and accurate as compared to the nth iteration that is applied to the model. It is necessary to re-factor as design work is conducted.

Designing Class based Components - Component Level Design Guidelines

As component level design proceeds, there are some guidelines other than basic design guidelines. These guidelines are applied to components and their interfaces, their dependencies and inheritance.

COMPONENTS
- Naming conventions should be established for components.
- These are specified as part of architectural model and then refined and elaborated as part of component level design.
- Architectural component names should be drawn from the problem domain.
- It should have meaning to all stakeholders.

INTERFACES
- Provides information about communication and collaboration.
- Lollipop approach to represent interface should be used in combination with UML box and dashed arrow.
- Interface should flow from left side of the component box for consistency.
- Only relevant interfaces to component should be shown.

DEPENDENCIES AND INHERITANCE
- Model dependencies from left to right.
- Model inheritance from bottom to top.
- Component interdependencies should be represented via interfaces.

Performing User Interface Design - Design Evaluation

Design should be evaluated to check whether it meets the user needs or not once an operational user interface prototype has been created. Evaluation spans a formality spectrum that ranges from an informal test drive in which a user provides an impromptu feedback to a formally designed study.

- After design model has been completed, a first level prototype is created.
- Prototype is evaluated by user.
- User provides designer with direct comments about the efficacy of interface.
- Evaluation cycle continues until no further modifications to interface design are necessary.
- Once first prototype is built, designer collects a variety of qualitative and quantitative data that will assist in evaluating the interface.
- Qualitative data includes questionnaires like simple yes/no, numeric response, scaled response, likert scales, percentage response or open ended.
- Quantitative data can be got by a form of time study analysis can be conducted.

The evaluation criterion applied during early design reviews are:
- length and complexity of written specification of the system.
- number of user tasks specified and average number of actions per task.
- number of actions, tasks, and system states indicated by the design model imply memory load.
- interface styles, help facilities, and error handling protocol provides an indication of interface complexity.

Component Level Design - Designing Class based Components - Basic Design Principles

Component level design in object oriented approach focuses on elaboration of analysis classes and the definition and refinement of infrastructure classes.

BASIC DESIGN PRINCIPLES

There are four basic design principles that are adopted to component level design.
Open-Closed Principle
A component or module should be open for extension and closed for modification. It means that the component should be allowed to extend without the need to make any internal changes. Abstractions are created that serve as a buffer between functionality that is expected to be extended and the design class itself.

Liskov Substitution Principle(LSP)

This principle suggests that a component that uses a base class should continue to function properly if a class derived from the base class is passed to the component instead. When a derived class is created, it also conforms to the pre- and post- conditions.

Dependency Inversion Principle(DIP)

This principle depends on abstractions. It does not depend on concretions. The more a component depends on other concrete components, the more difficult it will be to extend.

Interface Segregation Principle(ISP)

This principle suggests that a specialized interface should be designed to serve each major category of clients. Operations relevant to that category of clients should be described in interface. If multiple clients require same operations, they should be specified in each of the specialized interfaces.

Release Reuse Equivalence Principle(REP)

This principle suggests that when classes and components are designed for reuse, an implicit contract is established between the developer and the people who are using it. Older versions of entity are maintained by the developer who establishes a release control system.

Common Closure Principle(CCP)

This principle suggests that classes should address the same functional or behavioral area when they are packaged as part of a design.

Common Reuse Principle(CRP)

This principle suggests that release number of the package changes when one or more classes with a package changes. All other classes or packages that rely on the package that has been changed must now update to the most recent release of the package and be tested to ensure that new release operates without incident.

Component Level Design - Designing Class based Components - Coupling

The complexity of the system increases as the amount of collaboration and communication increases. As the complexity increases, difficulty in implementing, testing, and maintaining software also increases.

Coupling is a qualitative measure of the degree to which classes are connected to each other. Coupling increases as the classes become more dependent on each other. The main objective of component level design is to minimize coupling as much as possible.

As the design for each software component is elaborated, the focus shifts to the design of specific data structures and procedural designs to manipulate the data structures. There are different categories of coupling :

- Content Coupling
Content coupling is when one module modifies or relies on the internal workings of another module. This violates the basic design concept i.e. information hiding.
- Common Coupling
In common coupling, two modules share the same global data. It can lead to uncontrolled error propagation and side effects.
- Control Coupling
In Control coupling, one module controls the flow of other module. The problem is that an unrelated change in second module can result in the change of the meaning of control flag.
- External Coupling
Two modules share an external data format. A component communicates or collaborates with infrastructure components. It is necessary but should be limited to small number of components or classes.
- Data Coupling
Data coupling is when modules share data through. The bandwidth of communication grows and the complexity also increases.
- Stamp Coupling
In this type of coupling, modules share a composite data structure. It occurs when class B is declared as an argument of an operation of class A and therefore the system becomes more complex.
- Routine Call Coupling
It occurs when one operation invokes another. This type of coupling is quite necessary but it does increase the interconnectedness of a system.
- Type Use Coupling
It occurs when component A uses a data type in component B. If the type definition changes, every component that uses the definition also changes.
- Inclusion Coupling
In this type of coupling, component A includes or imports a package or content of component B.

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.

Component Level Design - Important Views that describes what a component is?

An Object Oriented View of Component

- From an object oriented viewpoint, a component is a set of collaborating classes.
- Each class within a component consists of attributes and operations relevant.
- Interfaces enabling the classes to communicate with other design classes are defined.
- Designer accomplishes this from analysis model and elaborates analysis classes and infrastructure classes.
- Analysis and design modeling are both iterative actions. Elaborating original analysis class may require additional analysis step which are then followed with design analysis steps to represent elaborated design class.
- Elaboration activity is applied to every component.
- After this, elaboration is applied to each attribute, operation, and interface.
- Data structures are specified.
- Algorithms for implementing each logic is designed.

The Conventional View

- A component is functional element of a program, also called module.
- It incorporates processing logic, internal data structures, interface that enables the component to be invoked and data to be passed to it.
- It resides within software architecture.
- It serves one of the roles control component, problem domain component or an infrastructure component.
- Conventional components are also derived from analysis classes.
- Data flow oriented element of analysis model is the basis for derivation.
- Each module is elaborated.
- Module interface is defined.
- Data structures are defined.
- Algorithm is designed using stepwise refinement approach.
- Design elaboration continues until sufficient detail is provided.

Process Related View

- The above two approaches assume that component is designed from scratch.
- Emphasize is on building systems that make use of existing software.
- As software architecture is developed, components or design patterns are chosen from catalog and used to populate the architecture.

Component Level Design - Definition, why it is important and what are the steps?

When the first iteration of architectural design is completed, component level design comes into picture. Intent of this phase is to translate the design model into operational software. The internal data structures and processing details of each component are not represented at a level of abstraction that is close to code. Component level design defines the data structures, algorithms, interface characteristics, and communication mechanisms allocated to each software component. A software engineer performs component level design.

Component level design is important because it is necessary to determine whether the software will work before you build it. The component level design represents the software in a way that allows you to review the details of the design for correctness and consistency with earlier design representations. It also provides a means for assessing whether data structures, interfaces and algorithms will work.

It is possible to represent component level design using a programming language. Component level design can also be represented by using some intermediate representation that can be translated easily into source code.

Define Component?
A component is a modular building block for computer software. Components should communicate and collaborate with other components as they reside within the software architecture. The meaning of component will differ depending on the point of view of software engineer using it. There are three different views of defining component :
- An Object oriented view
- The Conventional view
- A Process-related view

Steps in Component Level Design
- Design representations of data, architecture, and interfaces form the foundation of component level design.
- Class definition or processing narrative for each component is translated into detailed design that makes use of diagrammatic or text based forms that specify internal data structures, local interface detail, and processing logic.
- The procedural design is specified using a set of structured programming constructs.

Interface Design Steps - Applying Interface Design Steps, User Interface Design Patterns and Design Issues

Interface design is an iterative process. Interface design activities commences once interface analysis has been completed. Each user interface design occurs a number of times, each elaborating and refining information developed. Interface designer begins with sketches of each interface state and then work backward to define objects, actions, and other important design information.

APPLYING INTERFACE DESIGN STEPS

- Definition of interface objects.
- Defining the actions that are applied to them.
- Description of a use case is written.
- Once objects and actions are defined and elaborated, they are categorized by type.
- Target, source and application objects are identified.
- A source objects is dragged and dropped onto a target object.
- Application objects represents application specific data that is not directly manipulated as part of screen interaction.
- Screen layout is performed once all objects and actions are defined.
- Screen layout is interactive process in which graphical design and placement of icons, major and minor menus, screen text is conducted.
- Although automated tools can be useful in developing layout prototypes, sometimes a pencil and paper are all that are needed.

USER INTERFACE DESIGN PATTERNS

- A wide variety of user interface design patterns have emerged.
- A design pattern is an abstraction that prescribes a design solution to a specific well bounded design problem.

DESIGN ISSUES

Four common design issues are:
- system response time: it is measured from the point at which the user performs some control action. its two main characteristics are length and variability.If system response is too long, user frustration and stress is the result.Variability refers to the deviation from average response time.
- user help facilities: design issues must be addressed when a help facility is considered.
- error information handling: A good error message should describe problem in language that a user can understand. An error message should provide constructive advice for recovering from error. The message should indicate any negative consequences of the error. The error message should be accompanied by an audible or visual cue and the message should be non-judgmental.
- command labeling: Conventions for command usage should be established across all applications.It is confusing and often error-prone for a user to type command. The potential of error obvious.

Unnecessary iteration, project delays, and customer frustration often result. It is better to establish a design issue to be considered at beginning of software design, when changes are easy and costs are low.

Interface Analysis - Analysis of Display Content and Work Environment

ANALYSIS OF DISPLAY CONTENT

User tasks lead to the presentation of variety of content.Content can be character based reports, graphical displays, specialized information. Analysis modeling techniques identify the output data objects. During this step, the format and aesthetics of content are considered.
To determine format and aesthetics of content, steps that are followed are:
- can user customize screen location for content?
- is proper on-screen identification assigned to all content?
- how is color used to enhance understanding?
- how will error messages and warnings presented to user?
- how is report partitioned for ease of understanding?
- are different types of data assigned to consistent geographic locations on screen?

ANALYSIS OF WORK ENVIRONMENT

People do not work in isolation. They are always influenced by the activity around them. In some applications, the user interface is placed in a user-friendly location but in others lighting and noise may be a factor, a keyboard or mouse may not be an option. in addition to physical environment factors, the work place culture also is important.Can system interaction be measured? Will two or more people share information before input is provided? Many such questions should be answered before interface design commences.

Interface Analysis - Task Analysis and Modeling

The goals of task analysis :

- what work will the user perform in specific circumstances?
The use case is developed to show how an end-user performs some specific work related task. The use case provides a basic description of one important task for the computer aided design systems. The software engineer extracts tasks, objects and overall flow of interaction.

- what tasks and sub tasks will be performed as the user does the work?
It is a mechanism for refining the tasks that are required for the software to accomplish some desired function. Task elaboration is quite useful, but it can also be dangerous. A human engineer must first define and classify tasks.One approach is stepwise elaboration. Each of these major tasks can be elaborated into subtasks. Design model should accommodate each of the task in a way that is consistent with user model and system perception.

- what specific problem domain objects will the user manipulate as work is performed?
The objects that are extracted from the information obtained from the user can be categorized into classes. Attributes of each class are defined, and an evaluation of the actions applied to each object gives a list of operations to designer. Although object elaboration is useful, it should not be used as a standalone approach.

- what is the sequence of work tasks-the workflow?
Workflow analysis allows a software engineer to understand how a work process is completed when several people and roles are involved. Work flow analysis is applied when a number of users, each playing different roles, makes use of a user interface, it is sometimes necessary to go beyond task analysis and object elaboration.

- what is the hierarchy of tasks?
Process of elaboration occurs once the interface is analyzed. Once workflow has been established, a task hierarchy can be defined for each user type. Hierarchy is derived by a stepwise elaboration of each task identified for the user.

Interface Analysis - User Analysis

Interface analysis involves four steps:
- understanding the end-users who will interact with the system.
- understanding tasks that users should perform.
- understanding content.
- environment in which tasks will be conducted.

USER ANALYSIS IN INTERFACE ANALYSIS

Each user has a image or a perception of the software that may be different from the image and perceptions developed by other users. Information that is obtained from different sources can be used to understand users themselves as well as how people will use the system:
- User Interviews to better understand their needs, motivations and other issues.
- Sales input that is obtained when sales people meet with customers and users on regular basis.
- Marketing input
- Support input obtained when support staff talk with users on a daily basis.

To understand better the users of a system, interface designer can take help of following questions:
- are users trained professionals?
- what level of education?
- what is primary language?
- what and how are users compensated?
- what is age range?
- are users capable of learning from written materials or classroom training?
- what are consequences if user makes a mistake using a system?
- are users expert in subject matter addressed by the system?
- do users want to know about the technology that sits behind the interface?

User Interface Analysis and Design - The Process

The analysis and design process for user interfaces is iterative that is represented using a spiral model. User interface analysis and design process consists of four framework activities:
- User, task and environment analysis and modeling.
- Interface design.
- Interface construction.
- Interface validation.
The construction activity involves prototyping. Interface analysis focuses on the profile of users who will interact with system. Different user categories are defined. Requirements are obtained for each user category.

After the requirements are defined, detailed task analysis is conducted. Tasks performed by users are identified, described, and elaborated. The analysis of user environment focuses on physical work environment.Things that one should know about the environment as the user interface design begins are:
- Physical location of interface.
- Will the user sitting, standing or performing some other tasks unrelated to interface?
- Does the interface hardware accommodate space, light, or noise constraints?
- Any human factors that are driven by environmental factors?

- Analysis model is created using the information gathered from analysis activity.
- Design activity starts using analysis model as a basis.
- Interface design defines a set of interface objects and actions.
- Construction activity begins with creation of prototype that enables usage scenarios to be evaluated.
- Validation focuses on interface ability to implement every user task correctly, degree to which interface is easy to use and learn and users' acceptance of the interface.

User Interface Analysis and Design - Interface analysis and design models

User interface design begins with creating of different models of system function, human and computer tasks required to achieve system function are delineated, design issues applying to interface designs are considered, tools that are used and result that is evaluated by end-users for quality.

Analyzing and designing a user interface design requires four different models:
User Model
It is established by human or software engineer. It establishes the profile of end users of system. Users are categorized as:
- Novices: No syntactic and little semantic knowledge.
- Knowledgeable, intermittent users: Reasonable semantic and low recall or syntactic knowledge.
- Knowledgeable, frequent users: Good semantic and syntactic knowledge.

Design Model
Software engineer creates a design model. It includes data architectural, interface and procedural representations of the software.

User's Mental Model
It is created by end-user. It is the image of the system that end users carry in their mind. Accuracy of the description depends on the user's profile.

Implementation Model
It is created by implementers of the system. It combines the outward manifestation of computer based systems coupled with all information that describe system syntax and semantics.

When the implementation and user's mental model are coincident, users are comfortable with the software and use it effectively.

User Interface Testing - The Golden Rules

User interface design creates an effective communication medium between a human and a computer. User interface is designed by a software engineer. Interface design focuses on three areas:
- design of interfaces between software components.
- design of interfaces between software and other non-human producers and consumers of information.
- design of interface between a human and computer.

Rules Forming the Basis For A Set of User Interface Design Principles

Place the User in Control: Some design principles that allow the user to maintain control are:
- Define the current state of the interface in a way that does not force a user in to unnecessary or undesired actions.
- Flexible interaction should be provided because different users have different interaction preferences.
- It allows the user interaction to be interruptible and un-doable.
- The user should not be aware of the technical internals like operating system, file management functions etc. The user interface should move the user into virtual world of the application.
- It is good to design a macro mechanism that enables an user to customize the interface to facilitate interaction.
- The interface should be designed in a manner in which user will have direct interaction with objects that appear on screen.

Reduce the User's Memory Load
Some design principles enabling an interface to reduce user's memory load:
- Interface should be designed to reduce the requirement to remember past actions and results. This can be done by providing visual cues that enables a user to recognize past actions rather than to recall them.
- Establish meaningful defaults.
- Shortcuts should be defined that are intuitive in nature.
- The visual layout of the interface should be based on real world metaphor.
- Interface should be organized in a hierarchical manner. The information should be disclosed in a progressive fashion.

Make the Interface Consistent
Consistency means that all visual information is organized according to a design standard, input mechanisms are constrained to limited set used consistently throughout the application and mechanisms for navigating from task to task.Some design principles that helps in making interface consistent are:
- Allow the user to put the current task into meaningful context.
- Consistency should be maintained across a family of applications.
- Do not make changes in past interactive models that have created user expectations unless there is some solid reason to change.

Testing for Real-Time Systems - Effective Strategy for testing real time systems

The nature of real time systems is time-dependent and its asynchronous nature. This nature adds a difficult element to the testing mix and that is time. Test case designer need to consider:
- event handling
- timing of the data
- parallelism of the tasks that handle the data
The intimate relationship between real time software and its hardware environment causes testing problems.

An effective four step strategy for testing a real time system are:
Task Testing:
The first step is to test each task independently. Each task has conventional tests designed for them and each task is executed. It helps to uncover errors in logic, function.
Behavioral Testing:
The behavior of a real time system can be simulated using system models created with automated tools. These analysis activities can serve as the basis for the designing of test cases.
Intertask Testing:
Once the task and system related errors are identified, asynchronous tasks that communicate with one another with different data rates and load are tested against errors. Tasks that communicate through a message queue or data store are tested to uncover errors.
System Testing:
System tests are done to uncover errors at the software/hardware interface. Testing the handling of boolean events is essential. The tester develops a list of possible interrupts using state diagram and control specification. Tests that are designed are:
- Interrupt priorities are properly assigned and handled?
- Processing for interrupt is correct?
- Does performance procedure conform to requirements?
- Does high volume of interrupts arriving at critical times create problems in performance?

Testing for specialized Graphical User Interface(GUI) and Client/Server Architecture

There are some unique environments, architectures and applications for which unique guidelines and approaches are designed.

Testing Graphical User Interface (GUI)

The complexity of GUIs has grown because of reusable components provided as part of GUI development, leading to more difficulty in the design and execution of test cases. A series of standard tests can be derived as many graphical user interfaces have the same look and feel.
Finite state modeling graphs may be used to derive a series of tests. Testing of GUI should be done using automated tools as there are large number of permutations with GUI operations.

Testing of Client/Server Architectures

Testing of client server software occurs at three different levels:
- individual client applications are tested in disconnected mode.
- client and associated server applications are tested in concert but network operations are not explicitly exercised.
- the complete client server architecture including network operation and performance.

Types of tests that are conducted for client/server systems:
- Network communication tests: It ensures that message passing, transactions,and related network traffic occur without error.
- Database tests: Accuracy and integrity of data stored by the server is tested. Transactions are tested.
- Application function tests: Functionality of client applications are tested.
- Server tests: Coordination and data management functions of the server are tested.
- Transaction tests: Tests are created to ensure that each class of transactions is processed according to requirements.

Object Oriented Testing Methods - Fault Based Testing

Object oriented system testing begins at different levels to uncover errors that may occur as classes collaborate with one another and subsystems communicate across architectural layers.
Actual object oriented testing begins with a series of tests designed to exercise class operations and check whether errors exists when a class collaborates with other classes.
Attributes and operations are encapsulated, testing operations outside of the class is unproductive. Encapsulation, an essential design concept, creates a minor obstacle during testing. Inheritance also leads to additional challenges for the test case designer. Multiple inheritance complicates testing further by increasing the number of contexts for which testing is required.
White box testing methods like basis path, loop testing or data flow techniques can help to ensure that every statement in an operation has been tested. Black box testing methods are also appropriate for object oriented systems as they are for systems developed using conventional software engineering methods.

FAULT BASED TESTING

The strategy for fault based testing is to hypothesize a set of plausible faults and then derive tests to prove each hypothesis. The objective of fault based testing within an object oriented system is to design tests that have a higher possibility of uncovering plausible errors. Test cases are designed to exercise the design or code and to determine whether faults exist. This approach is really no better than any random testing technique if faults in object oriented systems are implausible.

Three types of faults are encountered when integration testing looks for plausible faults in operation calls or message connections. These faults are:
- unexpected result.
- wrong operation/message used.
- incorrect invocation.
Integration testing applies to attributes as well as operations. Integration testing attempts to find errors in the client side and not the server.

Black-Box Testing Method - Equivalence Partitioning

Equivalence partitioning is a method for deriving test cases.
- It divides the input domain into classes of data from which test cases are derived.
- It strives to define a test case that uncovers classes of errors, thereby reducing the total number of test cases that must be developed.
- Equivalence classes for an input condition is used for test case design.
- An equivalence class represents a set of valid or invalid states for input conditions.
- Input classes are known relatively early in the software process.
- An input condition is either a specific numeric value, range of values, set of related values or a boolean condition.

DEFINING EQUIVALENCE CLASSES FOR TESTING

If an input condition specifies a:
- SPECIFIES RANGE : one valid and two invalid equivalence classes are defined.
- REQUIRES SPECIFIC VALUE : one valid and two invalid equivalence classes are defined.
- SPECIFIES MEMBER OF SET : one valid and one invalid equivalence class are defined.
- BOOLEAN : one valid and one invalid equivalence class are defined.

Control Structure Testing - Condition Testing, Data Flow Testing, Loop Testing

Control structure testing is a group of white-box testing methods.
CONDITION TESTING
- It is a test case design method.
- It works on logical conditions in program module.
- It involves testing of both relational expressions and arithmetic expressions.
- If a condition is incorrect, then at least one component of the condition is incorrect.
- Types of errors in condition testing are boolean operator errors, boolean variable errors, boolean parenthesis errors, relational operator errors, and arithmetic expression errors.
- Simple condition: Boolean variable or relational expression, possibly proceeded by a NOT operator.
- Compound condition: It is composed of two or more simple conditions, Boolean operators and parentheses.
- Boolean expression: It is a condition without Relational expressions.

DATA FLOW TESTING
- Data flow testing method is effective for error protection because it is based on the relationship between statements in the program according to the definition and uses of variables.
- Test paths are selected according to the location of definitions and uses of variables in the program.
- It is unrealistic to assume that data flow testing will be used extensively when testing a large system, However, it can be used in a targeted fashion for areas of software that are suspect.

LOOP TESTING
- Loop testing method concentrates on validity of the loop structures.
- Loops are fundamental to many algorithms and need thorough testing.
- Loops can be defined as simple, concatenated, nested, and unstructured.
- In simple loops, test cases that can be applied are skip loop entirely, only one or two passes through loop, m passes through loop where m is than n, (n-1), n, and (n+1) passes through the loop where n is the maximum number of allowed passes.
- In nested loops, start with inner loop, set all other loops to minimum values, conduct simple loop testing on inner loop, work outwards and continue until all loops tested.
- In concatenated loops, if loops are independent, use simple loop testing. If dependent, treat as nested loops.
- In unstructured loops, redesign the class of loops.

User Interface Testing - Interface testing strategy

The user interface model is reviewed to ensure that it conforms to customer requirements and to other elements of analysis model. During testing, focus is shifted towards application specific aspects of user interaction as they are manifested by interface syntax and semantics.

The goal of interface testing is to:
- uncover errors related to specific interface mechanism.
- uncover errors in the way interface implements semantics of navigation, web application functionality or content display.

Objectives that should be achieved are:
- Interface features are tested to ensure that design rules, aesthetics, and related visual content are available for user without error.
- Individual interface mechanisms are tested in a manner that is analogous to unit testing.
- Each interface mechanism is tested within the context of a use case or navigation semantic units for a specific user category.
- The complete interface is tested against selected use cases and navigation semantic units to uncover errors in the semantics of the interface.
- The interface is tested within a variety of environments to ensure that it will be compatible.

Usability testing evaluates the degree to which users can interact effectively with the web application and the degree to which the web application guides user actions, provides meaningful feedback, and enforces a consistent interaction approach. Usability tests are designed by a web engineering team, but the tests themselves are conducted by end users.

Steps to be followed are :
- define a set of usability testing categories and identify goals for each.
- design tests that will enable each goal to be evaluated.

What are different issues that complicate database testing for web applications?

Web applications interface with sophisticated database management systems and build dynamic content objects created in real time using the data acquired from a database.Errors can and do occur as a consequence of each of these steps. Database testing for web applications is complicated by a variety of factors:

- Tests should be designed in such a way that they should be able to uncover errors made in translating the user's request into a form that is processed by DBMS.
- REMOTE DATABASE TO THE SERVER: Tests should be designed that uncovers errors in communication between web application and remote database.
- RAW DATA FROM DATABASE MUST BE TRANSMITTED TO WEBAPP SERVER: Tests should be designed that will demonstrate the validity of raw data received by the web application server.
- DYNAMIC CONTENT OBJECT TRANSMITTED TO CLIENT IN A FORM THAT IS DISPLAYED TO END USER: Tests should be designed to uncover errors in content object format and there should be test compatibility with client environment configurations.

Testing should ensure that :
- valid information is passed between client and server from interface layer.
- web application processes scripts correctly.
- user data is passed correctly to server.
- queries are passed to data management layer that communicates with database access routines.

User interface Layer - Tested to ensure HTML scripts are constructed properly and
transmitted to server side.
WebApp Layer on server - Ensure that user data are extracted from HTML scripts and transmitted to data transformation layer.
Data transformation function - Tested to ensure that correct SQL is created and passed to data management components.

Analysis for Web Applications - The Functional Model and The Configuration Model

The functional model describes two elements of web application :
- User Observable Functions: Delivered by web application to end users. It encompasses any processing functions that are initiated directly by the user. These functions may be implemented using operations within analysis classes but from the point of view of an end-user, the function is the visible outcome.
- Class Operations: Implement behaviors associated with the class. These operations manipulate class attributes and are involved as classes collaborate with one another to accomplish some required behavior.
The UML activity diagram can be used to represent processing details.

The Configuration Model describes the environment that the web application will require on both the server and client side of the system. Although it is very important to consider all configurations that are likely to be used, a web application must be engineered to serve its end-users. Web application resides on a server that provides access via Internet, Intranet or an Extra-net. Server hardware and operating system must be specified. Also, interoperability considerations on the server side should be considered.

Client side software provides an infrastructure that enables access to web application from user's location. Web application content and functionality is delivered by browser software. Each browser has its own peculiarities.

Overview of The Interaction Model - Use cases, Sequence diagrams, State diagrams, User interface prototype

The interaction model of web applications enables a conversation between an end user and application functionality, content, and behavior. Interaction model is made up of four elements:
- Use cases
- Sequence diagrams
- State diagrams
- User interface prototype

Some use cases describe the interactions between end user categories and the system. Other use cases refine the interactions, providing the analysis detail necessary to guide design and construction. Use cases provide a one-dimensional view of the interaction.

Sequence diagrams are a shorthand representation of the manner in which dynamic elements(user actions) collaborate with the structural elements(analysis classes) of the system. There is a need to ensure that traceability exists between the classes that have been defined and the use-cases that describe system interaction. Sequence diagrams can be created for each use-case once analysis classes are defined for the use case. Sequence diagrams present a second dimension that is more procedural in nature.

As the interaction occurs, state diagrams are another way to represent the dynamic behavior of the web application. State diagrams can be represented at different levels of abstraction. State diagrams provide a third dimension that is more behavioral and contains information about potential navigation pathways that is not provided by use cases or the sequence diagram.
Large complex web applications benefits from interaction model that encompasses the three representations : use cases, sequence diagrams and state diagrams.


User Interface Prototype : The layout of user interface, content it presents, interaction mechanisms, and overall aesthetic of user-web application connections have much to do with user satisfaction and the overall acceptance of the web application. User interface prototype is performed during the creation of analysis model.