Computer Systems And Concepts..

What is the difference between Shallow copy and Deep copy? Which is default?

2015-08-23T01:09:00.001+05:30

When you do a shallow copy, all the fields of the source object is copied to target object as it is. That means, if there is a dynamically created field in the source object, shallow copy will copy the same pointer to target object. So you will have two objects with fields that are pointing to same memory location which is not what you usually want.

In case of deep copy, instead of copying the pointer, the object itself is copied to target. In this case if you modify the target object, it will not affect the source. By default copy constructors and assignment operators do shallow copy. To make it as deep copy, you need to create a custom copy constructor and override assignment operator.

RISC PIPELINE

2013-03-11T21:25:00.001+05:30

In the history of computer hardware, some early reduced instruction set computer central processing units (RISC CPUs) used a very similar architectural solution, now called a classic RISC pipeline.

Those CPUs were: MIPS, SPARC, Motorola 88000, and later DLX.

The main common concept of each design was a five-stage execution instruction pipeline. During operation, each pipeline stage would work on one instruction at a time.

Each of these stages consisted of an initial set of flip-flops, and combinational logic which operated on the outputs of those flops.

The classic five stage RISC pipelineInstruction fetchDecode
Execute

Register-Register Operation (Single cycle latency): Add, subtract, compare, and logical operations. During the execute stage, the two arguments were fed to a simple ALU, which generated the result by the end of the execute stage.

Memory Reference (Two cycle latency). All loads from memory. During the execute stage, the ALU added the two arguments (a register and a constant offset) to produce a virtual address by the end of the cycle.

Multi Cycle Instructions (Many cycle latency). Integer multiply and divide and all floating-point operations. During the execute stage, the operands to these operations were fed to the multi-cycle multiply/divide unit. The rest of the pipeline was free to continue execution while the multiply/divide unit did its work. To avoid complicating the writeback stage and issue logic, multicycle instruction wrote their results to a separate set of registers.

Memory Access
Writeback
Hazards
Hennessy and Patterson coined the term hazard for situations in which a completely trivial pipeline would produce wrong answers.
Structural Hazards
Data Hazards
Solution A. Bypassing
SUB r3,r4 -> r10 ; Writes r3-r4 to r10
AND r10,r3 -> r11 ; Writes r10 & r3 to r11

A register file read port (i.e. the output of the decode stage, as in the naïve pipeline): red arrow

The current register pipeline of the ALU (to bypass by one stage): blue arrow

The current register pipeline of the access stage (which is either a loaded value or a forwarded ALU result, this provides bypassing of two stages): purple arrow. Note that this requires the data to be passed backwards in time by one cycle. If this occurs, a bubble must be inserted to stall the AND operation until the data is ready.

Control hazards

The branch resolution recurrence goes through quite a bit of circuitry: the instruction cache read, register file read, branch condition compute (which involves a 32-bit compare on the MIPS CPUs), and the next instruction address multiplexer.

Because branch and jump targets are calculated in parallel to the register read, RISC ISAs typically do not have instructions which branch to a register+offset address. Jump to register is supported.

On any branch taken, the instruction immediately after the branch is always fetched from the instruction cache. If this instruction is ignored, there is a one cycle per taken branch IPC penalty, which is quite large.

Predict Not Taken: Always fetch the instruction after the branch from the instruction cache, but only execute it if the branch is not taken. If the branch is not taken, the pipeline stays full. If the branch is taken, the instruction is flushed (marked as if it were a NOP), and one cycle's opportunity to finish an instruction is lost.

Branch Likely: Always fetch the instruction after the branch from the instruction cache, but only execute it if the branch was taken. The compiler can always fill the branch delay slot on such a branch, and since branches are more often taken than not, such branches have a smaller IPC penalty than the previous kind.

Branch Delay Slot: Always fetch the instruction after the branch from the instruction cache, and always execute it, even if the branch is taken. Instead of taking an IPC penalty for some fraction of branches either taken (perhaps 60%) or not taken (perhaps 40%), branch delay slots take an IPC penalty for those branches into which the compiler could not schedule the branch delay slot. The SPARC, MIPS, and MC88K designers designed a branch delay slot into their ISAs.

Branch Prediction: In parallel with fetching each instruction, guess if the instruction is a branch or jump, and if so, guess the target. On the cycle after a branch or jump, fetch the instruction at the guessed target. When the guess is wrong, flush the incorrectly fetched target.

Compilers typically have some difficulty finding logically independent instructions to place after the branch (the instruction after the branch is called the delay slot), so that they must insert NOPs into the delay slots.

Superscalar processors, which fetch multiple instructions per cycle and must have some form of branch prediction, do not benefit from delayed branches. The Alpha ISA left out delayed branches, as it was intended for superscalar processors.

The most serious drawback to delayed branches is the additional control complexity they entail. If the delay slot instruction takes an exception, the processor has to be restarted on the branch, rather than that next instruction. Exceptions then have essentially two addresses, the exception address and the restart address, and generating and distinguishing between the two correctly in all cases has been a source of bugs for later designs.

The Instruction Cache on these machines had a latency of one cycle. During the Instruction Fetch stage, a 32-bit instruction was fetched from the cache.

The PC predictor sends the Program Counter (PC) to the Instruction Cache to read the current instruction. At the same time, the PC predictor predicts the address of the next instruction by incrementing the PC by 4 (all instructions were 4 bytes long). This prediction was always wrong in the case of a taken branch, jump, or exception (see delayed branches, below). Later machines would use more complicated and accurate algorithms (branch prediction and branch target prediction) to guess the next instruction address.

Unlike earlier microcoded machines, the first RISC machines had no microcode. Once fetched from the instruction cache, the instruction bits were shifted down the pipeline, so that simple combinational logic in each pipeline stage could produce the control signals for the datapath directly from the instruction bits. As a result, very little decoding is done in the stage traditionally called the decode stage.

All MIPS, SPARC, and DLX instructions have at most two register inputs. During the decode stage, these two register names are identified within the instruction, and the two registers named are read from the register file. In the MIPS design, the register file had 32 entries.

At the same time the register file was read, instruction issue logic in this stage determined if the pipeline was ready to execute the instruction in this stage. If not, the issue logic would cause both the Instruction Fetch stage and the Decode stage to stall. On a stall cycle, the stages would prevent their initial flops from accepting new bits.

If the instruction decoded was a branch or jump, the target address of the branch or jump was computed in parallel with reading the register file. The branch condition is computed after the register file is read, and if the branch is taken or if the instruction is a jump, the PC predictor in the first stage is assigned the branch target, rather than the incremented PC that has been computed.

The decode stage ended up with quite a lot of hardware: the MIPS instruction set had the possibility of branching if two registers were equal, so a 32-bit-wide AND tree ran in series after the register file read, making a very long critical path through this stage. Also, the branch target computation generally required a 16 bit add and a 14 bit incrementer. Resolving the branch in the decode stage made it possible to have just a single-cycle branch mispredict penalty. Since branches were very often taken (and thus mispredicted), it was very important to keep this penalty low.

Instructions on these simple RISC machines can be divided into three latency classes according to the type of the operation:

During this stage, single cycle latency instructions simply have their results forwarded to the next stage. This forwarding ensures that both single and two cycle instructions always write their results in the same stage of the pipeline, so that just one write port to the register file can be used, and it is always available.

For direct mapped and virtually tagged data caching, the simplest by far of the numerous data cache organizations, two SRAMs are used, one storing data and the other storing tags.

If the instruction is a load, data is read from the data cache, so both SRAMs are read in parallel during the access stage of the instruction. The single tag read from the tag SRAM is compared with the virtual address specified in the load instruction, and if the two are equal then the datum recently retrieved from the data SRAM is the desired element of data. The success of finding the tag immediately in the tag SRAM is called a cache hit and allows the load instruction to complete the writeback stage normally. If the tag from the tag SRAM and virtual address from the load instruction are not equal, then the data is not in the cache and the datum retrieved from the data SRAM is useless, referred to as a cache miss. The CPU pipeline must suspend operation (described below) while a state machine updates the cache from memory, reading the required data from memory into the cache and optionally writing any dirty data evicted from the cache back into memory.

During a store, the tag SRAM is read to determine if the store is a cache hit or cache miss. If a cache miss occurs, the previously described cache update state machine brings the correct datum into the cache. Note that this means store data cannot be written to the cache data SRAM during the access stage because the processor does not yet know if the correct line is resident. Instead, the store data is held in a Store Data Queue, until it can be written to the cache data SRAM during the next store instruction. In a classic RISC pipeline, the Store Data Queue is just a single 32 bit register. For later reference, the virtual address written is held in the Store Address Queue, also a single 32 bit register. On more complicated pipelines, these queues can have multiple hardware registers and variable length.

To complicate things further, a load instruction immediately after a store instruction could reference the same memory address, in which case the data must come from the Store Data Queue rather than from the cache's data SRAM. For this reason, during a load instruction the virtual address included in the instruction is checked against the Store Address Queue in addition to the tag cache SRAM. Should the virtual address included in the load instruction be matched by an entry in the Store Address Queue, the associated data from the Store Data Queue is forwarded during the writeback stage rather than any data from the data cache SRAM without changing the flow of the load operation through the pipeline.

During this stage, both single cycle and two cycle instructions write their results into the register file.

Structural hazards are when two instructions might attempt to use the same resources at the same time. Classic RISC pipelines avoided these hazards by replicating hardware. In particular, branch instructions could have used the ALU to compute the target address of the branch. If the ALU were used in the decode stage for that purpose, an ALU instruction followed by a branch would have seen both instructions attempt to use the ALU simultaneously. It is simple to resolve this conflict by designing a specialized branch target adder into the decode stage.

Data hazards are when an instruction, scheduled blindly, would attempt to use data before the data is available in the register file.

Data hazards are avoided in one of two ways:

Suppose the CPU is executing the following piece of code:

The instruction fetch and decode stages will send the second instruction one cycle after the first. They flow down the pipeline as shown in this diagram:

In a naïve pipeline, without hazard consideration, the data hazard progresses as follows:

In cycle 3, the SUB instruction calculates the new value for r10. In the same cycle, the AND operation is decoded, and the value of r10 is fetched from the register file. However, the SUBinstruction has not yet written its result to r10. Write-back of this normally occurs in cycle 5 (green box). Therefore, the value read from the register file and passed to the ALU (in the Execute stage of the AND operation, red box) is incorrect.

Instead, we must pass the data that was computed by SUB back to the Execute stage (i.e. to the red circle in the diagram) of the AND operation before it is normally written-back. The solution to this problem is a pair of bypass multiplexers. These multiplexers sit at the end of the decode stage, and their flopped outputs are the inputs to the ALU. Each multiplexer selects between:

Decode stage logic compares the registers written by instructions in the execute and access stages of the pipeline to the registers read by the instruction in the decode stage, and cause the multiplexers to select the most recent data. These bypass multiplexers make it possible for the pipeline to execute simple instructions with just the latency of the ALU, the multiplexer, and a flip-flop. Without the multiplexers, the latency of writing and then reading the register file would have to be included in the latency of these instructions.

Note that the data can only be passed forward in time - the data cannot be bypassed back to an earlier stage if it has not been processed yet. In the case above, the data is passed forward (by the time the AND is ready for the register in the ALU, the SUB has already computed it).

However, consider the following instructions:

The data read from the address adr will not be present in the data cache until after the Memory Access stage of the LD instruction. By this time, the AND instruction will already be through the ALU. To resolve this would require the data from memory to be passed backwards in time to the input to the ALU. This is not possible. The solution is to delay the AND instruction by one cycle. The data hazard is detected in the decode stage, and the fetch and decode stages are stalled - they are prevented from flopping their inputs and so stay in the same state for a cycle. The execute, access, and write-back stages downstream see an extra no-operation instruction (NOP) inserted between the LD and AND instructions.

This NOP is termed a "pipeline bubble" since it floats in the pipeline, like an air bubble, occupying resources but not producing useful results. The hardware to detect a data hazard and stall the pipeline until the hazard is cleared is called a pipeline interlock.

A pipeline interlock does not have to be used with any data forwarding, however. The first example of the SUB followed by AND and the second example of LD followed by AND can be solved by stalling the first stage by three cycles until write-back is achieved, and the data in the register file is correct, causing the correct register value to be fetched by the AND's Decode stage. This causes quite a performance hit, as the processor spends a lot of time processing nothing, but clock speeds can be increased as there is less forwarding logic to wait for.

This data hazard can be detected quite easily when the program's machine code is written by the compiler. The original Stanford RISC machine relied on the compiler to add the NOP instructions in this case, rather than having the circuitry to detect and (more taxingly) stall the first two pipeline stages. Hence the name MIPS: Microprocessor without Interlocked Pipeline Stages. It turned out that the extra NOP instructions added by the compiler expanded the program binaries enough that the instruction cache hit rate was reduced. The stall hardware, although expensive, was put back into later designs to improve instruction cache hit rate, at which point the acronym no longer made sense.

Control hazards are caused by conditional and unconditional branching. The classic RISC pipeline resolves branches in the decode stage, which means the branch resolution recurrence is two cycles long. There are three implications:

There are four schemes to solve this performance problem with branches:

Delayed branches were controversial, first, because their semantics are complicated. A delayed branch specifies that the jump to a new location happens after the next instruction. That next instruction is the one unavoidably loaded by the instruction cache after the branch.

MEMORY CONTROLLER

2012-07-06T18:28:00.000+05:30

The memory controller is a digital circuit which manages the flow of data going to and from the main memory. It can be a separate chip or integrated into another chip, such as on the die of a microprocessor. This is also called a Memory Chip Controller (MCC).

Computers using Intel microprocessors have traditionally had a memory controller implemented on their motherboard's northbridge, but many modern microprocessors, such as DEC/Compaq'sAlpha 21364, AMD's Athlon 64 and Opteron processors, IBM's POWER5, Sun Microsystems's UltraSPARC T1, and more recently Intel's Core i7 have an integrated memory controller (IMC) on the microprocessor in order to reduce memory latency. While this has the potential to increase the system's performance, it locks the microprocessor to a specific type (or types) of memory, forcing a redesign in order to support newer memory technologies. When DDR2 SDRAM was introduced, AMD released new Athlon 64 CPUs. These new models, with a DDR2 controller, use a different physical socket (known as Socket AM2), so that they will only fit in motherboards designed for the new type of RAM. When the memory controller is not on-die, the same CPU may be installed on a new motherboard, with an updated northbridge.

The integration of the memory controller onto the die of the microprocessor is not a new concept. Some microprocessors in the 1990s such as the DEC Alpha 21066 and HP PA-7300LC had integrated memory controllers, but rather than for performance gains, this was implemented to reduce the cost of systems by eliminating the need for an external memory controller.

Purpose

Memory controllers contain the logic necessary to read and write to DRAM, and to "refresh" the DRAM by sending current through the entire device. Without constant refreshes, DRAM will lose the data written to it as the capacitors leak their charge within a fraction of a second (not less than 64 milliseconds according to JEDEC standards).

Reading and writing to DRAM is performed by selecting the row and column data addresses of the DRAM as the inputs to the multiplexer circuit, where the demultiplexer on the DRAM uses the converted inputs to select the correct memory location and return the data, which is then passed back through a multiplexer to consolidate the data in order to reduce the required bus width for the operation.

Bus width is the number of parallel lines available to communicate with the memory cell. Memory controllers' bus widths range from 8-bit in earlier systems, to 512-bit in more complicated systems and video cards (typically implemented as four 64-bit simultaneous memory controllers operating in parallel, though some are designed to operate in "gang mode" where two 64-bit memory controllers can be used to access a 128-bit memory device).

Double data rate memory

Double Data Rate DDR memory controllers are used to drive DDR SDRAM, where data is transferred on the rising and falling access of the memory clock of the system. DDR memory controllers are significantly more complicated than Single Data Rate controllers, but allow for twice the data to be transferred without increasing the clock rate or increasing the bus width to the memory cell.

Dual-channel memory

Dual Channel memory controllers are memory controllers where the DRAM devices are separated on to two different buses to allow two memory controllers to access them in parallel. This doubles the theoretical amount of bandwidth of the bus. In theory, more channels can be built (a channel for every DRAM cell would be the ideal solution), but due to wire count, line capacitance, and the need for parallel access lines to have identical lengths, more channels are very difficult to add.

Fully buffered memory

Fully buffered memory systems place a memory buffer device on every memory module (called an FB-DIMM when Fully Buffered RAM is used), which unlike traditional memory controller devices, use a serial data link to the memory controller instead of the parallel link used in previous RAM designs. This decreases the number of the wires necessary to place the memory devices on a motherboard (allowing for a smaller number of layers to be used, meaning more memory devices can be placed on a single board), at the expense of increasing latency (the time necessary to access a memory location). This increase is due to the time required to convert the parallel information read from the DRAM cell to the serial format used by the FB-DIMM controller, and back to a parallel form in the memory controller on the motherboard. In theory, the FB-DIMM's memory buffer device could be built to access any DRAM cells, allowing for memory cell agnostic memory controller design, but this has not been demonstrated, as the technology is in its infancy.

TRANSLATION LOOKASIDE BUFFER

2011-06-10T21:33:00.000+05:30

A translation lookaside buffer (TLB) is a CPU cache that memory management hardware uses to improve virtual address translation speed. All current desktop and server processors (such as x86) use a TLB to map virtual and physical address spaces, and it is ubiquitous in any hardware which utilizes virtual memory.

The TLB is typically implemented as content-addressable memory (CAM). The CAM search key is the virtual address and the search result is a physical address. If the requested address is present in the TLB, the CAM search yields a match quickly and the retrieved physical address can be used to access memory. This is called a TLB hit. If the requested address is not in the TLB, it is a miss, and the translation proceeds by looking up the page table in a process called a page walk. The page walk is an expensive process, as it involves reading the contents of multiple memory locations and using them to compute the physical address. After the physical address is determined by the page walk, the virtual address to physical address mapping is entered into the TLB.

A TLB has a fixed number of slots that contain page table entries, which map virtual addresses to physical addresses. The virtual memory is the space seen from a process. This space is segmented in pages of a prefixed size. The page table (generally loaded in memory) keeps track of where the virtual pages are loaded in the physical memory. The TLB is a cache of the page table; that is, only a subset of its content are stored.

The TLB references physical memory addresses in its table. It may reside between the CPU and the CPU cache, between the CPU cache and primary storage memory, or between levels of a multi-level cache. The placement determines whether the cache uses physical or virtual addressing. If the cache is virtually addressed, requests are sent directly from the CPU to the cache, and the TLB is accessed only on a cache miss. If the cache is physically addressed, the CPU does a TLB lookup on every memory operation and the resulting physical address is sent to the cache. There are pros and cons to both implementations. Caches that use virtual addressing have for their key part of the virtual address plus, optionally, a key called an "address space identifier" (ASID). Caches that don't have ASIDs must be flushed every context switch in a multiprocessing environment.

Implication For Performance:

The CPU has to access main memory for a:

instruction cache miss
data cache miss
TLB miss

The third case (the simplest case) is where the desired information itself actually is in a cache, but the information for virtual-to-physical translation is not in a TLB. These are all about equally slow, so a program "thrashing" the TLB will run just as poorly as one thrashing an instruction or data cache. That is why a well functioning TLB is important.

VIRTUAL FUNCTION

2011-04-27T21:07:00.000+05:30

A virtual function or virtual method is a function or method whose behaviour can be overridden within an inheriting class by a function with the same signature. This concept is a very important part of the polymorphism portion of object-oriented programming (OOP).

The concept of the virtual function solves the following problem:

In OOP when a derived class inherits a base class, an object of the derived class may be referred to (or cast) as either being the base class type or the derived class type. If there are base class methods overridden by the derived class, the method call behaviour is ambiguous.

The distinction between virtual and non-virtual resolves this ambiguity. If the function in question is designated "virtual" in the base class then the derived class's function would be called (if it exists). If it is not virtual, the base class's function would be called.

Virtual functions overcome the problems with the type-field solution by allowing the programmer to declare functions in a base class that can be redefined in each derived class.

In C++ virtual functions or virtual methods are declared by using the virtual keyword to the function's declaration.

For example, a base class Animal could have a virtual function eat. Subclass Fish would implement eat() differently than subclass Wolf, but you can invoke eat() on any class instance referred to as Animal, and get the eat() behaviour of the specific subclass.

This allows a programmer to process a list of objects of class Animal, telling each in turn to eat (by calling eat()), with no knowledge of what kind of animal may be in the list. You also do not need to have knowledge of how each animal eats, or what the complete set of possible animal types might be.

The following is an example in C++. Note that this example is not exception-safe. In particular, it may leak resources if new or vector::push_back throws an exception.

#include <iostream>
#include <vector>
 
class Animal {
    public:
        virtual void eat() const { 
            std::cout << "I eat like a generic Animal." << std::endl; 
        }
        virtual ~Animal() { 
        }
};
 
class Wolf : public Animal {
    public:
        void eat() const { 
            std::cout << "I eat like a wolf!" << std::endl; 
        }
        virtual ~Wolf() { 
        }
};
 
class Fish : public Animal {
    public:
        void eat() const { 
            std::cout << "I eat like a fish!" << std::endl; 
        }
        virtual ~Fish() { 
        }
};
 
class GoldFish : public Fish {
    public:
        void eat() const { 
            std::cout << "I eat like a goldfish!" << std::endl; 
        }
        virtual ~GoldFish() { 
        }
};
 
class OtherAnimal : public Animal {
        virtual ~OtherAnimal() { 
        }
};
 
int main() {
    std::vector<Animal*> animals;
    animals.push_back(new Animal());
    animals.push_back(new Wolf());
    animals.push_back(new Fish());
    animals.push_back(new GoldFish());
    animals.push_back(new OtherAnimal());
 
    for (std::vector<Animal*>::const_iterator it = animals.begin(); it != animals.end(); ++it) {
        (*it)->eat();
        delete *it;
    }
 
    return 0;
}

Output with the virtual function Animal::eat():

I eat like a generic Animal.
I eat like a wolf!
I eat like a fish!
I eat like a goldfish!
I eat like a generic Animal.

Output if Animal::eat() were not declared as virtual:

I eat like a generic Animal.
I eat like a generic Animal.
I eat like a generic Animal.
I eat like a generic Animal.
I eat like a generic Animal.

COST BENEFIT

2011-04-24T20:37:00.000+05:30

A cost benefit analysis is done to determine how well, or how poorly, a planned action will turn out. Although a cost benefit analysis can be used for almost anything, it is most commonly done on financial questions. Since the cost benefit analysis relies on the addition of positive factors and the subtraction of negative ones to determine a net result, it is also known as running the numbers.

Cost Benefit Analysis

A cost benefit analysis finds, quantifies, and adds all the positive factors. These are the benefits. Then it identifies, quantifies, and subtracts all the negatives, the costs. The difference between the two indicates whether the planned action is advisable. The real trick to doing a cost benefit analysis well is making sure you include all the costs and all the benefits and properly quantify them.

Should we hire an additional sales person or assign overtime? Is it a good idea to purchase the new stamping machine? Will we be better off putting our free cash flow into securities rather than investing in additional capital equipment? Each of these questions can be answered by doing a proper cost benefit analysis.

Example Cost Benefit Analysis

As the Production Manager, you are proposing the purchase of a $1 Million stamping machine to increase output. Before you can present the proposal to the Vice President, you know you need some facts to support your suggestion, so you decide to run the numbers and do a cost benefit analysis.

You itemize the benefits. With the new machine, you can produce 100 more units per hour. The three workers currently doing the stamping by hand can be replaced. The units will be higher quality because they will be more uniform. You are convinced these outweigh the costs.

There is a cost to purchase the machine and it will consume some electricity. Any other costs would be insignificant.

You calculate the selling price of the 100 additional units per hour multiplied by the number of production hours per month. Add to that two percent for the units that aren't rejected because of the quality of the machine output. You also add the monthly salaries of the three workers. That's a pretty good total benefit.

Then you calculate the monthly cost of the machine, by dividing the purchase price by 12 months per year and divide that by the 10 years the machine should last. The manufacturer's specs tell you what the power consumption of the machine is and you can get power cost numbers from accounting so you figure the cost of electricity to run the machine and add the purchase cost to get a total cost figure.

You subtract your total cost figure from your total benefit value and your analysis shows a healthy profit. All you have to do now is present it to the VP, right? Wrong. You've got the right idea, but you left out a lot of detail.

FACT FINDING TECHNIQUE

2011-04-22T11:22:00.000+05:30

To study any system the analyst needs to do collect facts and all relevant information. the facts when expressed in quantitative form are termed as data. The success of any project is depended upon the accuracy of available data. Accurate information can be collected with help of certain methods/ techniques. These specific methods for finding information of the system are termed as fact finding techniques. Interview, Questionnaire, Record View and Observations are the different fact finding techniques used by the analyst. The analyst may use more than one technique for investigation.

Interview
This method is used to collect the information from groups or individuals. Analyst selects the people who are related with the system for the interview. In this method the analyst sits face to face with the people and records their responses. The interviewer must plan in advance the type of questions he/ she is going to ask and should be ready to answer any type of question. He should also choose a suitable place and time which will be comfortable for the respondent.

The information collected is quite accurate and reliable as the interviewer can clear and cross check the doubts there itself. This method also helps gap the areas of misunderstandings and help to discuss about the future problems. Structured and unstructured are the two sub categories of Interview. Structured interview is more formal interview where fixed questions are asked and specific information is collected whereas unstructured interview is more or less like a casual conversation where in-depth areas topics are covered and other information apart from the topic may also be obtained.

Questionnaire
It is the technique used to extract information from number of people. This method can be adopted and used only by an skillful analyst. The Questionnaire consists of series of questions framed together in logical manner. The questions are simple, clear and to the point. This method is very useful for attaining information from people who are concerned with the usage of the system and who are living in different countries. The questionnaire can be mailed or send to people by post. This is the cheapest source of fact finding.

Record View
The information related to the system is published in the sources like newspapers, magazines, journals, documents etc. This record review helps the analyst to get valuable information about the system and the organization.

Observation
Unlike the other fact finding techniques, in this method the analyst himself visits the organization and observes and understand the flow of documents, working of the existing system, the users of the system etc. For this method to be adopted it takes an analyst to perform this job as he knows which points should be noticed and highlighted. In analyst may observe the unwanted things as well and simply cause delay in the development of the new system.

INHERITANCE IN C++

2011-04-13T00:10:00.001+05:30

Inheritance is the process of creating new classes from the existing class or classes.

Using inheritance, one can create general class that defines traits common to a set of related items. This class can then be inherited (reused) by the other classes by using the properties of the existing ones with the addition of its own unique properties.

The old class is referred to as the base class and the new classes, which are inherited from the base class, are called derived classes.

In above figure, the class B contains the three member i.e. Property1, Property2 and Property3.

The second class named as D contains four members i.e. Property1, Property2, Property3 and Property4.

Out of these, three members (Property1, Property2, Property3) of the class D are same as that of class B, while the one member i.e. Property4 is unique.

In the class D, instead of defining all the three members again, one can reuse them from the class B. This feature is known as inheritance which saves time, space, money and increases the reliability and efficiency.

Forms of Inheritance:

Single Inheritance

If a class is derived from a single base class, it is called as single inheritance.

Multiple Inheritance

If a class is derived from more than one base class, it is known as multiple inheritance

Multilevel Inheritance

The classes can also be derived from the classes that are already derived. This type of inheritance is called multilevel inheritance.

Hierarchical Inheritance

If a number of classes are derived from a single base class, it is called as hierarchical inheritance

A derived class can be defined as follows:

class derived_class_name : access_specifier base_class_name
{
data members of the derived class ;
member functions of the derived class ;
}
The colon (:), indicates that the class derived_class_name is derived from the class base_class_name.
The access_specifier may be public, private or protected (will be discussed further).
If no access_specifier is specified, it is private by default.
The access_specifier indicates whether the members of the base class are privately derived or publicly derived.

Public inheritance

When a derived class publicly inherits the base class, all the public members of the base class also become public to the derived class and the objects of the derived class can access the public members of the base class.

The following program will illustrate the use of the single inheritance.

This program has a base class B, from which class D is inherited publicly.

Example:

#include
class Rectangle
{
private:
float length ; // This can't be inherited
public:
float breadth ; // The data and member functions are inheritable
void Enter_lb(void)
{
cout << "\n Enter the length of the rectangle : ";
cin >> length ;
cout << "\n Enter the breadth of the rectangle : ";
cin >> breadth ;
}
float Enter_l(void)
{ return length ; }
}; // End of the class definition

class Rectangle1 : public Rectangle
{
private:
float area ;
public:
void Rec_area(void)
{ area = Enter_l( ) * breadth ; }
// area = length * breadth ; can't be used here

void Display(void)
{
cout << "\n Length = " << Enter_l( ) ; // Object of the derived class can't
// inherit the private member of the base class. Thus the member
// function is used here to get the value of data member 'length'.
cout << "\n Breadth = " << breadth ;
cout << "\n Area = " << area ;
}
}; // End of the derived class definition D
void main(void)
{
Rectangle1 r1 ;
r1.Enter_lb( );
r1.Rec_area( );
r1.Display( );
}

Figure- Public Inheritance

Private inheritance

When a derived class privately inherits a base class, all the public members of the base class become private for the derived class.

In this case, the public members of the base class can only be accessed by the member functions of the derived class.

The objects of the derived class cannot access the public members of the base class.

Note that whether the derived class is inherited publicly or privately from the base class, the private members of the base class cannot be inherited.

Example:

#include
#include
class Rectangle
{
int length, breadth;
public:
void enter()
{
cout << "\n Enter length: "; cin >> length;
cout << "\n Enter breadth: "; cin >> breadth;
}
int getLength()
{
return length;
}
int getBreadth()
{
return breadth;
}
void display()
{
cout << "\n Length= " << length;
cout << "\n Breadth= " << breadth;
}
};

class RecArea : private Rectangle
{

public:
void area_rec()
{
enter();
cout << "\n Area = " << (getLength() * getBreadth());
}
};
void main()
{
clrscr();
RecArea r ;
r.area_rec();
getch();
}

Example:2

#include
class Rectangle // Base class
{
private:
float length ; // This data member can't be inherited
public:
float breadth ; // This data member is inheritable
void Enter_lb(void)
{
cout << "\n Enter the length of the rectangle: "; cin >> length ;
cout << "\n Enter the breadth of the rectangle: "; cin >> bredth ;
}
float Enter_l(void)
{
return length ;
}
void Display_l(void)
{
cout << "\n Length = " << length ;
}
}; // End of the base class Rectangle.
// Defining the derived class Rectangle1. This class has been derived from the
// base class i.e. Rectangle, privately.
class Rectangle1 : private Rectangle // All the public members of the base class
{ // Rectangle become private for the derived class Rectangle1.
private:
float area ;
public:
void Rec_area(void)
{
Enter_lb( );
area = Enter_l( ) * bredth ; // length can't be used directly
}
void Display(void)
{
Display_l( ); // Displays the value of length.
cout << "\n Bredth = " << bredth ;
cout << "\n Area = " << area << endl ;
}
};
void main(void)
{
Rectangle1 r1 ;
r1.Rec_area( ) ;
// r.Enter_lb( ); will not work as it has become private for the derived class.
r1.Display( ) ;
// r.Display_l( ) will not work as it also has become private for the derived class.
}

Fig: private inheritance

The protected access specifier

The third access specifier provided by C++ is protected.

The members declared as protected can be accessed by the member functions within their own class and any other class immediately derived from it.

These members cannot be accessed by the functions outside these two classes.

Therefore, the objects of the derived class cannot access protected members of the base class.

When the protected members (data, functions) are inherited in public mode, they become protected in the derived class. Thus, they can be accessed by the member functions of the derived class.

On other hand, if the protected members are inherited in the private mode, the members also become private in the derived class.

They can also be accessed by the member functions of the derived class, but cannot be inherited further.

Overriding the member functions:

The member functions can also be used in a derived class, with the same name as those in the base class.

One might want to do this so that calls in the program work the same way for objects of both base and derived classes.

The following program will illustrate this concept.

#include
const int len = 20 ;
class Employee
{
private:
char F_name[len];
int I_number ;
int age ;
float salary ;
public:
void Enter_data(void)
{
cout << "\n Enter the first name = " ; cin >> F_name ;
cout << "\n Enter the identity number = " ; cin >> I_number ;
cout << "\n Enter the age = " ; cin >> age ;
cout << "\n Enter the salary = " ; cin >> salary ;
}
void Display_data(void)
{
cout << "\n Name = " << F_name ;
cout << "\n Identity Number = " << I_number ;
cout << "\n Age = " << age ;
cout << "\n Salary = " << salary ;
}
}; // End of the base class
class Engineer : public Employee
{
private:
char design[len] ; // S_Engineer, J_Engineer, Ex_Engineer etc

public:
void Enter_data( )
{
Employee :: Enter_data( ) ; // Overriding of the member function
cout << "\n Enter the designation of the Engineer: " ; cin >> design ;
}

void Display_data(void)
{
cout << "\n *******Displaying the particulars of the Engineer**** \n" ;
Employee :: Display_data( ) ; // Overriding of the member function
cout << "\n Designition = " << design ;
}
}; // End of the derived class

void main(void)
{
Engineer er ;
er.Enter_data( ) ;
er.Display_data( );
}

Hierarchical Inheritance:
When two or more classes are derived from a single base class, then
Inheritance is called the hierarchical inheritance. The representation
of the hierarchical inheritance is shown in the following Fig.

In the above Fig., student is a base class, from which the three classes viz. arts, science and commerce have been derived. Now, let us write a program that illustrates the hierarchical inheritance, based on the above design.

Example

include
const int len = 20 ;
class student // Base class
{
private: char F_name[len] , L_name[len] ;
int age, int roll_no ;
public:
void Enter_data(void)
{
cout << "\n\t Enter the first name: " ; cin >> F_name ;
cout << "\t Enter the second name: "; cin >> L_name ;
cout << "\t Enter the age: " ; cin >> age ;
cout << "\t Enter the roll_no: " ; cin >> roll_no ;
}
void Display_data(void)
{
cout << "\n\t First Name = " << F_name ;
cout << "\n\t Last Name = " << L_name ;
cout << "\n\t Age = " << age ;
cout << "\n\t Roll Number = " << roll_no ;
}
};
class arts : public student
{
private:
char asub1[len] ;
char asub2[len] ;
char asub3[len] ;
public:
void Enter_data(void)
{
student :: Enter_data( );
cout << "\t Enter the subject1 of the arts student: "; cin >> asub1 ;
cout << "\t Enter the subject2 of the arts student: "; cin >> asub2 ;
cout << "\t Enter the subject3 of the arts student: "; cin >> asub3 ;
}
void Display_data(void)
{
student :: Display_data( );
cout << "\n\t Subject1 of the arts student = " << asub1 ;
cout << "\n\t Subject2 of the arts student = " << asub2 ;
cout << "\n\t Subject3 of the arts student = " << asub3 ;
}
};
class commerce : public student
{
private: char csub1[len], csub2[len], csub3[len] ;
public:
void Enter_data(void)
{
student :: Enter_data( );
cout << "\t Enter the subject1 of the commerce student: ";
cin >> csub1;
cout << "\t Enter the subject2 of the commerce student: ";
cin >> csub2 ;
cout << "\t Enter the subject3 of the commerce student: ";
cin >> csub3 ;
}
void Display_data(void)
{
student :: Display_data( );
cout << "\n\t Subject1 of the commerce student = " << csub1 ;
cout << "\n\t Subject2 of the commerce student = " << csub2 ;
cout << "\n\t Subject3 of the commerce student = " << csub3 ;
}
};

void main(void)
{
arts a ;
cout << "\n Entering details of the arts student\n" ;
a.Enter_data( );
cout << "\n Displaying the details of the arts student\n" ;
a.Display_data( );
science s ;
cout << "\n\n Entering details of the science student\n" ;
s.Enter_data( );
cout << "\n Displaying the details of the science student\n" ;
s.Display_data( );
commerce c ;
cout << "\n\n Entering details of the commerce student\n" ;
c.Enter_data( );
cout << "\n Displaying the details of the commerce student\n";
c.Display_data( );
}

Multiple Inheritance

When a class is inherited from more than one base class, it is known as multiple inheritance.
The syntax for defining a subclass, which is inheriting more than one classes is:
class Subclass : access_specifier Baseclass1,
access_specifier Baseclass2, ………
…….. access_specifier Baseclass_n
{
members of the derived class ;
};
The following figure illustrates the use of multiple inheritance.

In the above figure, Circle and Rectangle are two base classes from which the class Cylinder is being inherited.

The data members of both the base classes are declared in protected mode. Thus, the class Cylinder can access the data member radius of class Circle and data member length, breadth of the class Rectangle, but the objects of the class Cylinder cannot access these protected data members.

The volume of the cylinder is equal to 22/7*(radius*radius*length). Thus, instead of defining these data again, they can be inherited from the base classes Circle and Rectangle ( radius from class Circle and length from class Rectangle ).

Example:

#include
class Circle // First base class
{
protected:
float radius ;
public:
void Enter_r(void)
{
cout << "\n\t Enter the radius: "; cin >> radius ;
}
void Display_ca(void)
{
cout << "\t The area = " << (22/7 * radius*radius) ;
}
};
class Rectangle // Second base class
{
protected:
float length, breadth ;
public:
void Enter_lb(void)
{
cout << "\t Enter the length : "; cin >> length ;
cout << “\t Enter the breadth : ” ; cin >> breadth ;
}
void Display_ar(void)
{
cout << "\t The area = " << (length * breadth);
}
};
class Cylinder : public Circle, public Rectangle // Derived class, inherited
{ // from classes Circle & Rectangle
public:
void volume_cy(void)
{
cout << "\t The volume of the cylinder is: "
<< (22/7* radius*radius*length) ;
}
};
void main(void)
{
Circle c ;
cout << "\n Getting the radius of the circle\n" ;
c.Enter_r( );
c.Display_ca( );
Rectangle r ;
cout << "\n\n Getting the length and breadth of the rectangle\n\n";
r.Enter_l( );
r.Enter_b( );
r.Display_ar( );
Cylinder cy ; // Object cy of the class cylinder which can access all the
// public members of the class circle as well as of the class rectangle
cout << "\n\n Getting the height and radius of the cylinder\n";
cy.Enter_r( );
cy.Enter_lb( );
cy.volume_cy( );
}

Multilevel Inheritance:

It has been discussed so far that a class can be derived from a class.

C++ also provides the facility of multilevel inheritance, according to which the derived class can also be derived by an another class, which in turn can further be inherited by another and so on.

The following figure will illustrate the meaning of the multilevel inheritance.

In the above figure, class B represents the base class. The class D1 that is called first level of inheritance, inherits the class B. The derived class D1 is further inherited by the class D2, which is called second level of inheritance.

Example: Multilevel Inheritance

#include
class Base
{
protected:
int b;
public:
void EnterData( )
{
cout << "\n Enter the value of b: ";
cin >> b;
}
void DisplayData( )
{
cout << "\n b = " << b;
}
};
class Derive1 : public Base
{
protected:
int d1;
public:
void EnterData( )
{
Base:: EnterData( );
cout << "\n Enter the value of d1: ";
cin >> d1;
}
void DisplayData( )
{
Base::DisplayData();
cout << "\n d1 = " << d1;
}
};
class Derive2 : public Derive1
{
private:
int d2;
public:
void EnterData( )
{
Derive1::EnterData( );
cout << "\n Enter the value of d2: ";
cin >> d2;
}
void DisplayData( )
{
Derive1::DisplayData( );
cout << "\n d2 = " << d2;
}
};
int main( )
{
Derive2 objd2;
objd2.EnterData( );
objd2.DisplayData( );
return 0;
}

DOCUMENTATION

2011-04-13T00:10:00.000+05:30

Documentation and Importance of Documentation

Documentation is one of the system which is used to communicate, instruct and record the information for any reference or operational purpose. They are very useful for representing the formal flow of the present system. With the help of documentation it is very easy to track the flow of the system's progress and they working of the system can be expalined very easily.

It helps to provide the clear description of the work done so far. It is essential that the documents prepared must be updated on regular basis this will help to trace the progress of work easily. With appropriate and good documentation it is very easy to understand the how aspects of the system will work for the company where the system is to installed. It is also help to understand the type of data which will be inputted in the system and how the output can be produced.

After the system is installed, and if in case the system is not working properly it will be very easy for the administrator to understand the flow of data in the system with documentation which will help him/ her to correct the flaws and get the system working in no time.

Uses of Documentation

It facilitates effective communication regarding the system between the technical and the non technical users.

It is very useful in training new users. With a Good documentation new users can easily get acquainted with the flow of the systems.

Documentation also helps the users to solve problems like trouble shooting even a non technical user can fix the problems.

It plays a significant role in evaluation process.

It not only helps to exercise a better control over the internal working of the firm, but it also external as well especially during audit.

Documentations can help the manager to take better financial decisions of the organization.

Characteristics

What the characteristics of good system documentation are is difficult to decide. Some desirable characteristics are described below:

Created for intended audience

The documentation should be created for the intended audience. While it may be appropriate for a "Management overview" to be created for non-technical people, most system documentation will be used by System Administrators and other technical people as an important reference. System documentation should provide sufficient technical detail.

Specific

The system documentation should describe the specific implementation of a given system rather than provide generic documentation.

Relationship with other documentation

System documentation should be reasonably self contained; however it will often be a component of a wider collection of documentation and it is reasonable for it to reference other documents. There is little value in duplicating information from Vendor's manuals.

Up to date

The documentation needs to be up to date, but does not necessarily have to be recent. If the system has remained completely unchanged for a long period of time, the documentation can remain unchanged for the same period of time. It is important that when systems are changed documentation is updated to reflect the changes and this should be part of any change control procedures.

Sufficiently comprehensive

Documentation needs to be sufficiently comprehensive to for fill its purpose.

Accessible

The documentation must be held in a location and format that makes it accessible. It is obviously unacceptable to have the only copy of a system's documentation held on a drive that has failed or on the system itself should it fail.
It is very desirable to hold the documentation in a universal standard format that does not require access to a particular word processor; ASCII text may be most suitable.

Secure

Because system documentation could be useful to troublemakers, thought may need to be given to controlling access to the documentation.

Requirements

The question of what is the purpose of system documentation is difficult to answer. Below are some possible uses of system documentation.

Introduction / overview

System documentation can provide an introduction and overview of systems. New Administrators, contractors and other staff may need to familiarise themselves with a system; the first thing that will be requested is any system documentation. To avoid staff having to waste time discovering the purpose of a system, how it is configured etc system documentation should provide an Introduction.

Disaster Recovery

Many systems are supported by disaster recovery arrangements, but even in such circumstances, the recovery can still fail. There may be a need to re-build a system from scratch at least to the point where a normal restore from backup can be done. To make a rebuild possible it will be necessary to have documentation that provides answers to the configuration choices. For example it is important to re-build the system with the correct size of file systems to avoid trying to restore data to a file system that has been made too small. In some circumstances certain parameters can be difficult to change at a later date. When rebuilding a system it may be important to configure networking with the original parameters both to avoid conflicts with other systems on the network and because these may be difficult to change subsequently.

OS or Application re-load

Even when a disaster has not occurred, there may be times when it is necessary to reload an Operating System or Application; this can either be as part of a major version upgrade or a drastic step necessary to solve problems. In such circumstances it is important to know how an OS or Application has been configured.

Trouble shooting aid

The benefits of good system documentation, when trouble shooting, are fairly obvious. A comprehensive description of how a system should be configured and should behave can be invaluable when configuration information has become corrupted, when services have failed, or components have failed.
Good system documentation will include a description of the physical hardware and its physical configuration, which can avoid the need to shutdown a system in order to examine items such as jumper settings.

Planning tool

When planning changes or upgrades it will be necessary to assess the impact of changes on existing systems. A good understanding of existing systems is necessary for assessing the impact of any changes and for this good system documentation is required.

Other

System documentation can be used for many purposes including Auditing, Inventory, Maintenance, etc. The documentation of individual systems forms an important component of the overall network documentation.

Automating the creation of system documentation

Most operating systems include tools to report important system information and often the output from such tools can be re-directed to a file; this provides a means of automating the creation of system documentation.
Many Administrators have neither the time nor inclination to produce System Documentation and given the importance of keeping such documentation current, automation of the creation of system documentation is very desirable.
There are limitations to the extent to which system documentation can be automated. The following cannot be documented automatically:

Textual descriptions that Administrators may create.
Hardware configuration items that cannot be detected through software (perhaps such as which slot on a bus a card occupies or how jumpers are set).
Other items that cannot be detected through software such as serial numbers, the physical location of a system etc.

The documentation of items that cannot be documented automatically can be facilitated by such means as having standard template documents and creating such documentation when systems are first installed. Fortunately this kind of documentation is less susceptible to change and is often less critical. It may be useful to create a simple file in a standard location (perhaps root) on systems that contains "external" information such as serial numbers, asset numbers etc.
Most Operating Systems have tools for automating their deployment (e.g. unattend.txt for NT, JumpStart for Solaris, Kickstart for Redhat Linux etc). Although these tools are primarily intended for deploying large numbers of systems they can be used for individual systems. While the configuration scripts used in these tools are not very readable, they are in text form, and can be read by technical staff. Such scripts offer the great advantage that a system is documented in an unambiguous way that guarantees that the system can be rebuilt exactly the same way it was first built.
For most systems it should be possible to create a simple script (or batch file) that uses several system tools to report system information and out put the results to a file. The use of such tools together with simple print commands (e.g. echo "line of text") can readily produce a useful document. It should be possible to adapt such scripts to produce the documentation required in terms of content and level of detail etc.
If standard tools do not provide sufficient information, there are many third party tools and free tools that can be used, however the potential problems of using additional tools, rather than just "built-in" tools, has to be weighed against the advantages. Alternative scripting languages (such a Perl) may provide additional benefits.

FEASIBILITY STUDY

2011-04-12T20:43:00.000+05:30

It is the measure and the study of how beneficial the development of the system would be to the organization. This is known as feasibility study. The measurement of feasibility is known as feasibility study. There are number of aspects which are taken into consideration while the feasibility studies. Firstly the project team is formed then with the help of flowcharts and other forms of documentations the characteristics of the system are identified. The system is evaluated and measured against the expected performance. A suitable candidate is selected for the job and a final report is made and presented to the management for further evaluations.

The different types of feasibility studies are as follows:

Technical feasibility study: It is used to determine the requirements of technologies for the current system.
Schedule feasibility study: It is used to determine the time factor related to the current system.
Cultural feasibility study: It is used to determine the impact of the current system on a culture.
Legal feasibility study: It is used to determine the legal scrutiny of the current system.
Marketing feasibility study: It is used to determine the single and multi-dimensional market forces that affect the current system.
There are four types of marketing feasibility study, which are as follows:

Economic feasibility.
Legal feasibility.
Operational feasibility.
Schedule feasibility.

DEADLOCK

2011-04-11T23:34:00.000+05:30

Sometimes a process has to reserve more than one resource. For example, a process which copies files from one tape to another generally requires two tape drives. A process which deals with databases may need to lock multiple records in a database.

In general, resources allocated to a process are not preemptable; this means that once a resource has been allocated to a process, there is no simple mechanism by which the system can take the resource back from the process unless the process voluntarily gives it up or the system administrator kills the process. This can lead to a situation called deadlock. A set of processes or threads is deadlocked when each process or thread is waiting for a resource to be freed which is controlled by another process. Here is an example of a situation where deadlock can occur.

SYSTOLIC ARRAY

2011-04-11T23:32:00.001+05:30

An array of processing elements (typically multiplier-accumulator chips) in a pipeline structure that is used for applications such as image and signal processing and fluid dynamics. The "systolic," It refers to the rhythmic transfer of data through the pipeline, like blood flowing through the vascular system.

SEMAPHORE

2011-04-11T23:31:00.000+05:30

First let me begin our topic by giving an insight to what is actually a semaphore. A semaphore is nothing but a term used in UNIX. That comes in mind is what for we need this variable. For instance there may be times when two processes try to access the same file simultaneously. In this event we must control the access of the file when the other process is accessing. This is done by assigning value to semaphore.
In other words, we also can say that
In computer science, a semaphore is a protected variable or abstract data type that provides a simple but useful abstraction for controlling access by multiple processes to a common resource in a parallel environment.

A useful way to think of a semaphore is as a record of how many units of a particular resource are available, coupled with operations to safely (i.e. without race conditions) adjust that record as units are required or become free, and if necessary wait until a unit of the resource becomes available. Semaphores are a useful tool in the prevention of race conditions and deadlocks; however, their use is by no means a guarantee that a program is free from these problems. Semaphores which allow an arbitrary resource count are called counting semaphores, whilst semaphores which are restricted to the values 0 and 1 (or locked/unlocked, unavailable/available) are called binary semaphores.

JVM - THE JAVA VIRTUAL MACHINE

2011-04-11T23:22:00.000+05:30

Acronym for JAVA Virtual Machine. An abstract computing machine, or virtual machine, JVM is a platform-independent execution environment that converts Java bytecode into machine language and executes it. Most programming languages compile source code directly into machine code that is designed to run on a specific microprocessor architecture or OS such as Windows or UNIX. A JVM is a machine within a machine -- mimics a real JAVA processor, enabling Java bytecode to be executed as actions or operating system calls on any processor regardless of the operating system. For example, establishing a socket connection from a workstation to a remote machine involves an operating system call. Since different operating systems handle sockets in different ways, the JVM translates the programming code so that the two machines that may be on different platforms are able to connect.

MISD - MULTIPLE INSTRUCTIONS SINGLE DATA

2011-04-11T23:20:00.001+05:30

MISD didn't exist when Flynn was categorizing the machines. It might have been added for symmetry in his chart. Its applications are very limited and expensive and currently there seems to be no commercial implementation. But it is a research interest topic. One example is systolic array with matrix multiplication like computation. With rows of data processing units (cells) sharing the information with their neighbors immediately after processing.

FIBRE OPTICS

2011-04-11T23:19:00.000+05:30

A fiber-optic system is similar to the copper wire system that fiber-optics is replacing. The difference is that fiber-optics use light pulses to transmit information down fiber lines instead of using electronic pulses to transmit information down copper lines. Looking at the components in a fiber-optic chain will give a better understanding of how the system works in conjunction with wire based systems.
• SPEED: Fiber optic networks operate at high speeds - up into the gigabits
• BANDWIDTH: large carrying capacity
• DISTANCE: Signals can be transmitted further without needing to be refreshed.
• RESISTANCE: Greater resistance to electromagnetic noise such as radios & motors.
• MAINTENANCE: Fiber optic cables costs much less to maintain.

POLYMORPHISM

2011-04-11T23:17:00.003+05:30

Generally, the ability to appear in many forms. In object-oriented programming, polymorphism refers to a programming language's ability to process objects differently depending on their data type or class. More specifically, it is the ability to redefine methods for derived classes. For example, given a base class shape, polymorphism enables the programmer to define different area methods for any number of derived classes, such as circles, rectangles and triangles. No matter what shape an object is, applying the area method to it will return the correct results. Polymorphism is considered to be a requirement of any true object-oriented programming language (OOPL).

ABSTRACTION

2011-04-11T23:16:00.000+05:30

Abstraction is the process of hiding the details and exposing only the essential features of a particular concept or object. Computer scientists use abstraction to understand and solve problems and communicate their solutions with the computer in some particular computer language.

ENCAPSULATION - COMPACTING DATA

2011-04-11T23:11:00.000+05:30

Encapsulation means as much as shielding. Each OO object has a shield around it. Objects can't 'see' each other. They can exchange things though, as if they are interconnected through a hatch.

NETWORK TOPOLOGIES

2011-04-11T22:58:00.001+05:30

The physical topology of a network refers to the configuration of cables, computers, and other peripherals. Physical topology should not be confused with logical topology which is the method used to pass information between workstations. Logical topology was discussed in the Protocol chapter .
There are few kind of topologies:

Bus
Ring
Star
Mesh
Tree
Extended Star
Hierarchical

RAD - RAPID APPLICATION DEVELOPMENT MODEL

2011-04-11T22:57:00.001+05:30

RAD is a linear sequential software development process model that emphasis an extremely short development cycle using a component based construction approach. If the requirements are well understood and defines, and the project scope is constraint, the RAD process enables a development team to create a fully functional system with in very short time period

BRAND EQUITY

2011-04-11T22:56:00.001+05:30

A brand is a name or symbol used to identify the source of a product. When developing a new product, branding is an important decision. The brand can add significant value when it is well recognized and has positive associations in the mind of the consumer. This concept is referred to as brand equity.

CRM - CUSTOMER RELATIONSHIP MANAGEMENT

2011-04-11T22:46:00.001+05:30

CRM stands for Customer Relationship Management. It is a process or methodology used to learn more about customers' needs and behaviors in order to develop stronger relationships with them. There are many technological components to CRM, but thinking about CRM in primarily technological terms is a mistake. The more useful way to think about CRM is as a process that will help bring together lots of pieces of information about customers, sales, marketing effectiveness, responsiveness and market trends.
CRM helps businesses use technology and human resources to gain insight into the behavior of customers and the value of those customers.

2011-04-11T22:45:00.001+05:30

Advertising promotes a product, service or event to its target audience. A target audience is the portion of the general public that products, services or events were created for to fill a desire or need in the marketplace. Advertising is written by advertising copywriters and finished with artwork by graphic designers. The channelsadvertising is run through to reach its target audience includes Internet, print, broadcast, outdoor and point of purchase.

DBMS - DATABASE MANAGEMENT SYSTEM

2011-04-11T22:44:00.000+05:30

DBMS Stands for "Database Management System." In short, a DBMS is a database program. Technically speaking, it is a software system that uses a standard method of cataloging, retrieving, and running queries on data. The DBMS manages incoming data, organizes it, and provides ways for the data to be modified or extracted by users or other programs.