Why is documentation so important for software testing?

IMPORTANCE OF DOCUMENTATION

- Software documentation like other kinds of documentation is just a piece of plane text.
- Though just being plain text, its importance in the field cannot be neglected.
- You must have observed that whenever you purchase some software or application it comes with a documentation which contains user’s manual also.
- It is obvious that you must be using this user’s manual to understand and use the software better.
- The manual might have always helped you in diagnosis of your system whenever it might have had a break down, crash or hang.
- Documentation is a great help as it helps us in operating the software system or application.
- Documentation helps different people in different ways.
- Documentation has a very important role to play in the field of software engineering.

TYPES OF DOCUMENTATION

1.Requirements Documentation
- This documentation states all the requirements of a software system or application be it functional requirements or non functional requirements.
- Apart from the requirements it also states the features, functionalities, capabilities, attributes and characteristics of a software system or application. - This type of documentation serves as a foundation for the other documentations.

2. Technical Documentation
- This documentation contains the written code of the program and algorithm implemented.
- It also provides knowledge about the user interface of the software system or application.
- It also gives information about the APIs.

3. Marketing Documentation
- This documentation gives tip and information for marketing the software product.

4. Architectural Documentation
- This documentation is all about the internal structure of the software system or application.
- It explains how a particular software system or application is related to the environment and on what principles the construction of the program is based.

5. End user Documentation or User’s Manual
- This document is popularly known as user’s manual.
- It contains all type of knowledge that a user might need to operate the software system or for trouble shooting.

SOME FACTS ABOUT DOCUMENTATION
- Documentation introduces the software system or application to the user.
- It contains details about the software.
- Documentation can be thought of as a verified and validated agreement between the product developer and the buyer i.e., client.
- Documentation is modular in nature.
- It serves as road map for the user.
- It is said that if something is not present in the writing, it actually never happened.
- Documentation serves as a proof.
- If you don’t make a write up about the software, the client or the users will think that you are just making up the facts and if the things are there, they might have been done by some body else.
- You need to document every aspect of your software so that if later any dispute arises, none will be able to testify your work and decisions.
- Information contained in the documentation is very crucial and important.
- The software engineering industry is so documentation intensive.

Let us say that you have a program that got some problem like it crashed or hanged and the person in charge of the software is not available. Neither you know the structure and design of the program nor do you have any idea of how to mend the fault in the program. So what you will do in such a case?

Here documentation comes to your rescue.
- You have all the necessary details and tips on how to fix a fault and also the design of the program.
- It is important that the proper documentation is made available to each and every personnel of the software development team.

How to assess alternative architectural designs?

There are many architectural alternatives that need to be assessed. There are different ways to assess the design:

Trade off Analysis Method
It establishes an iterative evaluation process for software architectures. It involves six steps:
- All the scenarios are collected.
- Requirements, constraints and environment description are elicited.
- Architectural styles or patterns chosen to address scenarios and requirements are described.
- Quality attributes are evaluated.
- The sensitivity of quality attributes to architectural attributes are identified.
- Critique candidate architectures using sensitivity analysis.

Architectural Complexity
In architectural complexity, the dependencies between the components are assessed within the architecture. Dependencies can be divided into:
- Sharing dependencies represent dependence relationship among consumers or producers.
- Flow dependencies represent dependence relationships between producers and consumers of resources.
- Constrained dependencies represent constraints on the flow of control among set of activities.

Architectural Description Languages
Architectural description language provides a semantic and syntax for describing a software architecture. It is a set of tools and notation that allows the design to be represented in an unambiguous and understandable fashion.

Introduction to Pattern-based design in software design?

Pattern based design is a technique that reuses the design elements. Each architectural pattern, design pattern, or idiom is cataloged, thoroughly documented and carefully considered as it is assessed for inclusion in a specific application.

A description of design pattern may consider a set of design forces. Design forces are those characteristics of the problem and attributes of the solution that constrain the way in which the design is developed. These design forces also describe the environment and conditions that must exist to make design pattern applicable.

Types of design patterns available are:
- Architectural patterns
The overall structure of software, relationship among subsystems and software components and rules are defined for relationship among elements of architecture.
- Design patterns
It addresses a specific element of design to solve some design problem, relationships among components or mechanisms for good communication among components.
- Idioms
These are language specific patterns. They implement the algorithmic element of a component. They can act as a specific interface protocol or a mechanism for communication among components.

How do we map data flow into a software architecture?

In architectural design, the mapping method uses data flow characteristics to derive a commonly used architectural style. A data flow diagram is mapped into program structure using one of the two mapping approaches:
- Transform Mapping
- Transaction Mapping
Structured design is often characterized as a data flow oriented design method because it provides a convenient transition from a data flow diagram. This type of information flow is the driver for the mapping approach.
Transform Flow: The overall flow of data occurs in a sequential manner and follows one, or only a few straight line paths. When a segment of a data flow diagram exhibits these characteristics, transform flow is present.

Transaction Flow: Information flow which is characterized by single data item called a transaction that triggers other data flow along one of many paths. When a data flow diagram takes this kind of form then transaction flow is present.

TRANSFORM MAPPING

It is a set of design steps that allows a data flow diagram with transform flow characteristics to be mapped into a specific architectural style.
- Review the fundamental system model.
- Review and refine data flow diagrams for the software.
- Determine whether the data flow diagram has transform or transaction flow characteristics.
- Isolate the transform center by specifying incoming and outgoing flow boundaries.
- Perform first level factoring.
- Perform second level factoring.
- Refine the first iteration architecture using design heuristics for improved software quality.

TRANSACTION MAPPING

In transaction mapping, information flow along two of the three action paths accommodates additional incoming flow. Each action path flows into a single transform, display messages and status. The design steps for transaction mapping is similar with a major difference lies in mapping of data flow diagram to software structure.
- Review the fundamental system model.
- Review and refine data flow diagrams for the software.
- Determine whether the data flow diagram has transform or transaction flow characteristics.
- Identify the transaction center and the flow characteristics along each of the action paths.
- Map the data flow diagram in a program structure amenable to transaction processing.
- Factor and refine the transaction structure and the structure of each action path.
- Refine the first iteration architecture using design heuristics for improved software quality.

Once an architecture has been derived, it is elaborated and then analyzed against quality criteria.

Architectural Design - Refining the Architecture into Components and Describing Instantiations of the System

Refining the Architecture into Components

As the software architecture is refined into components, structure of the system begins to emerge. Components of the software architecture are derived from three sources:
- the application domain
- the infrastructure domain
- the interface domain
Because analysis modeling does not address infrastructure, one should allocate sufficient design time to consider it carefully.
In order to find the components that are most suitable for refining the software architecture, you need to start by using the classes which were described in the analysis model. The analysis classes in turn are representations of business entities that architecture is trying to describe. You could also base these components on an infrastructure model rather than the business model. If you went purely by the business model, you would not be able to depict many of those infrastructure components such as database components, components used for communication etc.
Whatever interfaces are described in the architecture context diagram imply one or more specialized components that process the data that flow across the interface.

Describing Instantiations of the System

The context of the system has been represented, the archetypes indicating important abstractions are defined, the overall structure of system apparent and major software components are identified, however further refinement is necessary which is accomplished by developing an actual instantiation of architecture. The architecture is applied to a specific problem with the intent of demonstrating that the structure and components are appropriate.

Architectural Design - Representing the System in Context and Defining Archetypes

As architectural design begins, the design should define the external entities that the software interacts with and nature of the interaction. Once the context is modeled and all external interfaces are described, the structure of the system is specified by the designer. It is done by defining and refining software components that implement the architecture.

REPRESENTING THE SYSTEM IN CONTEXT

Architectural context represents how the software interacts with entities external to its boundaries. A system context diagram accomplishes this requirement by representing the flow of information into and out of the system. At the architectural design level, a software architect uses an architectural context diagram to model the manner in which software interacts with entities external to its boundaries.

How do systems inter-operate with the target system?
Superordinate Systems
These systems use the target system as part of some higher level processing scheme.
Subordinate Systems
These systems are used by the target system and provide data or processing that are necessary to complete target system.
Peer-level Systems
These systems interact on a peer-to-peer basis.
Actors
These entities interact with the target system by producing or consuming information necessary for requisite processing.
Each of these external entities communicates with target systems through an interface.

DEFINING ARCHETYPES

Archetypes are the abstract building blocks of an architectural design. It is a class or pattern that represents a core abstraction that is critical to design of an architecture for the target system. Archetypes can be derived by examining analysis classes defined as part of analysis model.Target system architecture is composed of these archetypes which represent stable elements of the architecture. Some kind of archetypes are:
- Nodes
- Detector
- Indicator
- Controller

What are different types of architectural pattern domains?

Architectural patterns define a specific approach for handling some behavioral characteristics of the system. A software architecture may have a number of architectural patterns that address issues such as concurrency, persistence and distribution.

CONCURRENCY
To promote parallelism, applications must handle multiple tasks and there are different ways to handle concurrency by an application and each way can be presented by a different architectural pattern.
- One approach is to use an operating system process management pattern that provides built-in operating system features allowing components to execute concurrently.
- Another approach is to define a task scheduler at the application level.

PERSISTENCE
Data persists if it survives past the execution of the process that created it. Persistent data can be read or modified by other processes at a later time as they are stored in a database or file. Persistence can be achieved through two architectural patterns:
- database management system pattern that applies the storage and retrieval capability of a database management system to the application architecture.
- application level persistence pattern that builds persistence features into application architecture.

DISTRIBUTION
The distribution problem addresses in a manner in which systems or components communicate with one another in a distributed environment. The most common architectural pattern established to address distribution problem is the broker pattern. Broker acts as middle man between client and server component.

What is an architectural style and pattern?

There are many architectural styles associated with the software that is built for computer based systems. The style describes a system category that encompasses:
- set of components.
- set of connectors enabling communication, coordination and cooperation among components.
- constraints.
- semantic models enabling a designer to understand overall properties of a system.

Architectural style is a transformation which is imposed on the design of an entire system. The intent is to establish a structure for all components of the system. When an existing architecture is re engineered, fundamental changes to the structure of the software results.
Architectural pattern imposes a transformation on the design of an architecture. Differences between pattern and style are:
- Scope of pattern is less broad.
- Pattern imposes a rule on architecture describing how software will handle some aspect of its functionality.
- Architectural patterns tend to address specific behavioral issues within context of architectural.
Patterns can be used in conjunction with an architectural style to establish the shape the overall structure of a system.

How is data designed at architectural and component level?

Data Design at Architectural Level

Data design translates data objects defined during analysis model into data structures at the software component level and, when necessary,a database architecture at the application level.
There are small and large businesses that contains lot of data. There are dozens of databases that serve many applications comprising of lots of data. The aim is to extract useful information from data environment especially when the information desired is cross functional.
Techniques like data mining is used to extract useful information from raw data. However, data mining becomes difficult because f some factors:
- Existence of multiple databases.
- Different structures.
- Degree of detail contained with databases.Alternative solution is concept of data warehousing which adds an additional layer to data architecture. Data warehouse encompasses all data used by a business. A data warehouse is a large, independent database that serve the set of applications required by a business. Data warehouse is a separate data environment.

Data Design at Component Level

It focuses on representation of data structures that are directly accessed by one or more software components. Set of principles applicable to data design are:
- Systematic analysis principles applied to function and behavior should also be applied to data.
- All data structures and operations to be performed on each should be identified.
- The content of each data object should be defined through a mechanism that should be established.
- Low level data design decisions should be deferred until late in design process.
- A library of data structures and operations that are applied to them should be developed.
- The representation of data structure should only be known to those modules that can directly use the data contained within the structure.
- Software design and programming language should support the specification and realization of abstract data types.

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.

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.

Introduction to Architecture Design - WebApp Architecture

The design process for identifying the subsystems making up a system and the
framework for sub-system control and communication is architectural design. An architectural design is :
- early stage in system design process.
- conducted in parallel with other design activities.
- establishes a link among goals established for web application, content, users visiting it, and the navigation criterion.
- identifying system components and their communications.

A web application is an application that is accessed over a network such as the Internet or an intranet.Web application architecture provides an infrastructure that enables a web based system to achieve its business objectives.
The Model View Controller (MVC) architecture decouples the user interface from web application functionality and information content.

The MVC design pattern divides applications into three components:
- The Model maintains the state and data that the application represents.
- The View allows the display of information about the model to the user. It contains all interface specific functions.
- The Controller allows the user to manipulate the application. It coordinates the flow of data between model and view.

Web application architecture is defined within the context of the development environment in which the application is to be implemented.

Introduction to Architecture Design - Content Architecture

The design process for identifying the subsystems making up a system and the
framework for sub-system control and communication is architectural design. An architectural design is :
- early stage in system design process.
- conducted in parallel with other design activities.
- establishes a link among goals established for web application, content, users visiting it, and the navigation criterion.
- identifying system components and their communications.

Content architecture emphasize on the fact how are the content objects structured for presentation and navigation. It focuses on overall hypermedia structure of the web application. It focuses on
- identifying links and relationships among content and documents.
- defining the structure of content.
- specifying consistent document requirements and attributes.

The design can choose from four different content structures:
- Linear Structures : a predictable sequence of interactions is common. The sequence of content presentation is predefined and linear in nature.
- Grid Structures : applied when the web application content can be organized categorically in two dimensions. This web application architecture is useful when highly regular content is encountered.
- Hierarchical Structures : it is the most common web application architecture. It is designed in a manner that enables flow of control horizontally, across vertical branches of the structure.
- Networked Structures : architectural components are designed so that they may pass control to virtually every other component in the system. It provides navigational flexibility but at the same time it can be a bit confusing to a user.
- Composite Structures : the overall architecture of the web application may be hierarchical, but part of the a structure may exhibit linear characteristics, while another part of the architecture may be networked.

The WebApp Design - Attributes, Goals and Web Design Pyramid

Design is an engineering activity that leads to a high quality product. The major attributes of quality for web applications are:
- Security : The main emphasis of security is the ability of the web application and its environment to avoid unauthorized access or attack.
- Availability : Web application will not meet users needs if its unavailable. Availability is the measure of the percentage of time that a web application is available for use.
- Scalability : Is the variation in volume handled significantly by the web applications and the system. It is important to build a web application that can accommodate the burden of success.
- Time to market : It is a measure of quality from business point of view.

What should be considered when assessing content quality?
- Scope and depth of content be easily determined so that it meets user's needs?
- Background and authority of content's author be easily identified?
- Possibility of determining the currency of content, last update?
- Stability of content and location?
- Credibility of content?
- Uniqueness of content?
- Is content well organized?
- Is content valuable?

Design Goals

The design goals for every web application are:
- Simplicity
- Consistency
- Identity
- Robustness
- Navigability
- Visual appeal
- Compatibility

Web Design Pyramid

Each level of the pyramid represents the design activities:
- Interface Design : It describes structure and organization of the user interface. It includes screen layout, interaction modes, navigation mechanisms.
- Aesthetic Design : It describes the look and feel of the application.
- Content Design : It defines layout, structure and outline of all content.
- Navigation Design : It describes the navigational flow for web application.
- Architectural Design : It represents the overall hypermedia structure.
- Component Design : It develops detailed processing logic.

Hypermedia Design Patterns in Web Engineering

Web engineering uses design patterns. These are of two types:
- Generic design patterns - applicable for every software.
- Hypermedia design pattern - specific to WebApps.
Design problems can be solved by using design patterns. There are some pattern categories:

NAVIGATION PATTERNS
These patterns helps in the design of NSU, navigation links and overall navigation flow of the web application.

ARCHITECTURAL PATTERNS
It helps in the design of content and web application architecture. Many architectural patterns are available for web engineers who design web applications in various business domains.

COMPONENT CONSTRUCTION PATTERNS
The web application components can be combined by the methods provided by these patterns. When data processing functionality is required within a web application, the architectural and component level design patterns are applicable.

PRESENTATION PATTERNS
Presentation patterns assist in the presentation of content as it is presented to the user via the interface. They tell how to organize user interface control functions, shows the relationship between an interface action and the content object it affects, establish content hierarchies.

BEHAVIOR AND USER INTERACTION PATTERNS
These patterns assist in design of user machine interaction. They address how the interface informs the user of the consequences of a specific action, how a user expands content based on usage context, how to best describe the destination that is implied by a link.