What is a Dispatcher?

A number of types of schedulers are available that suit the different needs of different operating systems. Presently, there are three categories of the schedulers:

1. Long-term schedulers
2. Medium-term schedulers
3. Short-term schedulers

Apart from the schedulers there is one more component involved in the scheduling process and is known as the dispatcher. 

- It is the dispatcher that gives a process power to control the CPU. 

- To which process this control is to be given is selected by the short-term scheduler. 

- This whole process involves the following three steps:

1. Switching the context
2. Turning on the user code
3. Making a jump to the exact location of the program from where it has to be restarted.

- Values taken from the program counter are analyzed by the dispatcher and accordingly it fetches instructions and feeds data in to the registers. 

- The dispatcher unlike the other system components needs to be very quick since it is invoked during all the switches that occur. 

- Whenever a context switch is invoked, the processor gets in to an idle state for a very small period of time. 

- Hence, it is required that the context switches that are not necessary might be avoided. 

- The dispatcher takes some time for stopping one process and start running the other one. 

- The dispatch latency is what we call this time.

- Scheduling and dispatch are complex processes and interrelation to each other. 

- These two are very much essential for the operation of the operating system. 

- Today, architectural extensions are available for the modern processors that provide a number of banks of registers.

- Swapping of these registers in hardware is possible and therefore a certain number of tasks are capable of retaining their full registers. 

- Whenever an interrupt triggers the dispatcher, it sends to it the full set of the registers belonging to the process that was being executed at the time of occurrence of the interrupt. 

- Here, the program counter is not considered. 

- Therefore, it is important that the dispatcher should be written carefully for storing the present states of the registers on being triggered. 

- In other words, we can say that for the dispatcher itself, there is no immediate context. 

- This saves it from the same problem. 

Process of Dispatcher

Below we try to describe in simple words what actually the process is.

1. The program presently having the context is executed by the processor. Things used by this program include stack base, flags, program counter, and registers and so on. There is a possible exception of the reserved register that is native to the operating system. The executing program does not have any knowledge regarding the dispatcher.
2. For dispatcher a timed interrupt is triggered. Here the program counter jumps to the address listed in the BIOS interrupt. This marks the beginning of the execution of the dispatch sub routine. The dispatcher then deals with the stacks and the registers etc. of the program that raised the interrupt.
3. Dispatcher like the other programs consists of some sets of instructions that operate up on the register of the current program. These instructions know everything of the previously executed programs. Out of these, the first few instructions are responsible for storing the state of the program.
4. Dispatcher next determines which program should be given the CPU next for executing. Now it deletes all the statistics of the previously executed state and fills in the details of the next process to be executed.
5. Dispatcher jumps to the address mentioned in the program counter and establishes a full context on the processor.

- Actually dispatcher does not really require registers since its only work is to write the current state of the CPU in to a memory location that has been predetermined. 

- It then loads in to the CPU another process from other predetermined location. 

What are different types of design patterns?

The Composite View Design Pattern
- The context of composite view pattern is that it allows the development of the view more manageable through the creation of a template to handle common page elements for a view.
- The problem comes in modifying and managing the layout of multiple views.
- The solution is to use this pattern when a view is composed of multiple atomic sub-views. Each component of the template may be included into the whole and the layout of the page may be managed independently of the content.
- A benefit of using this pattern is that interface designer can prototype the layout of the page, plugging in static content on each component.
- The drawback is that there is a runtime overhead associated with it.

The Front Controller Design Pattern
- It provides a centralized controller for managing requests.
- The problem is that the system needs a centralized access point for presentation-tier request handling to support the integration of system data retrieval, view management, and navigation.
- The solution to the above problem is that a controller is used as an initial point of contact for handling a request. It centralizes decision-making controls.

Data Access Object Design Pattern
- It separates resource's client interface from its data access mechanisms.It allows data access mechanism to change independently of the code that uses the data.
- The problem is that data will be coming from different persistent storage mechanism and access mechanism varies based on the type of storage.
- The solution to the above problem is to use the Data Access Object to abstract and encapsulate all access to the data source. It implements the access mechanism required to work with the data source.

What are different characteristics of design patterns?

A design pattern is a general repeatable solution to a commonly occurring problem in software design.
- It is a proven solution to problems that keep recurring.
- They are reusable solutions to common problems.
- Design patterns are not frameworks.
- Design patterns are more abstract than frameworks.
- Design pattern cannot be directly implemented.
- Design patterns are more primitive than a framework.
- A design pattern cannot incorporate a framework.
- Patterns may be documented using one of several alternative templates.
- Design patterns can speed up the development process by providing tested, proven development paradigms.
- Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.
- Patterns allow developers to communicate using well-known, well understood names for software interactions.

A pattern description includes the following elements:
- name of the pattern should be meaningful.
- context of the pattern represents the circumstances or preconditions.
- Problem description that pattern addresses should be provided.
- Solution is a description of the static and dynamic relationships amongthe components of the pattern.
The use of design patterns requires careful analysis of the problem that is to be
addressed and the context in which it occurs.

What is Quality and what are different perspectives used in understanding quality?

Quality is the total characteristic of an entity to satisfy stated and implied needs. Three perspectives are used in understanding quality:
- quality of the product
- quality of the process
- quality in the context of the business environment.

Quality of the Product
- The quality of the product has a different perspective for different people.
- End users assume that the software has quality if it gives what they want, when they want it, all the time. The ease of use and is also a important criterion for end users.
- For software engineers, they take a look at the internal characteristics rather than the external.

Quality of the Process
As software engineers, we valuethe quality of the software development process. Process guidelines suggests that byimproving the software development process,we also improve the quality of theresulting product. Common guidelines of process include Capability Maturity Model Integration (CMMI),ISO 9000:2000, Software Process Improvement and Capability Determination (SPICE).

Quality in the Context of Business Process
Quality is viewed in terms of the products and services being provided by the business in which the software is used. Improving the technical quality of the business process adds value to the business, i.e., technical value of thesoftware translates to business value.

To address quality issues:
- use quality standards.
- understand people involved in development process.
- understand the systematic biases in human nature.
- commit to quality.
- manage user requirements.

The System Engineering Hierarchy - System Modeling

Good system engineering begins with a clear understanding of context - the world view - and then progressively narrows focus until technical details are understood. System engineering encompasses a collection of top-down and bottom-up methods to navigate the hierarchy.
System engineering process begins with a world of view which is refined to focus more fully on a specific domain of interest. Within a specific domain, the need for targeted system elements is analyzed. Finally, the analysis, design, and construction of targeted system element is initiated. Broad context is established at the top of the hierarchy and at the bottom, detailed technical activities are conducted. It is important for a system engineer narrows the focus of work as one moves downward in the hierarchy.

System modeling is an important element of system engineering process. System engineering model accomplishes the following:
- define processes.
- represent behavior of the process.
- define both exogenous and endogenous input to model.
- represent all linkages.

Some restraining factors that are considered to construct a system model are:
- Assumptions that reduce number of possible permutations and variations thus enabling a model to reflect the problem in a reasonable manner.
- Simplifications that enable the model to be created in a timely manner.
- Limitations that help to bound the system.
- Constraints that will guide the manner in which the model is created and the approach taken when the model is implemented.
- Preferences that indicate the preferred architecture for all data, functions , and technology.
The resultant system model may call for a completely automated or semi automated or a non automated solution.

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 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.