mca 3rd semester assignment

FEBRUARY 2011

MCA 3 RD S EMESTER A SSIGNMENT

H ARVINDER S INGH

511025273

TABLE OF C ONTENTSI. MC0071 SOFTWARE ENGINEERING (BOOK ID: B0808 & B0809) 1 24 40 64 71

II. MC0072 COMPUTER GRAPHICS (BOOK ID: B0810) III. MC0073 SYSTEM PROGRAMMING (BOOK ID: B0811) IV. MC0074 STATISTICAL AND NUMERICAL METHODS USING C++ (BOOK ID: B0812) V. MC0075 COMPUTER NETWORKS (BOOK ID: B0813 & B0814)

FACULTY : S HASHANK S IR

MC0071 SOFTWARE ENGINEERING(Book ID: B0808 & B0809) Assignment Set 1

M C0071 SOFTW AR E EN GIN E ERI N G

1. D ESCRIBE THE CONCURRENT DEVELOPMENT MODEL IN YOUR OWN WORDS .The concurrent process model can be represented schematically as a series of major technical activities, tasks, and their associated states. For e.g.:, the engineering activity defined for the spiral model is accomplished by invoking the following tasks. Prototyping and / or analysis modeling, requirements specification, and design. The below figure shows that it provides a schematic representation of one activity with the concurrent process model. The activity-analysis-may be in any one of the states noted at any given time. Similarly, other activities (e.g. Design or customer communication) can be represented in an analogous manner. All activities exist concurrently but reside in different states. For e.g., early in a project the customer communication activity has completed its first iteration and exists in the awaiting Changes State. The analysis activity (which existed in the none state while initial customer communication was completed) now makes a transition into the under development state. If the customer indicates that changes in requirements must be made, the analysis activity moves from the under development state into the awaiting changes state. The concurrent process model defines a series of events that will trigger transition from state to state for each of the software engineering activities. For e.g., during early stages of design, an inconsistency in the analysis model is uncovered. This generates the event analysis model correction, which will trigger the analysis activity from the done state into the awaiting Changes State. The concurrent process model is often used as the paradigm for the development of client/server applications. A client/server system is composed of a set of functional components. When applied to client/server, the concurrent process model defines activities in two dimensions a system dimension and component dimension. System level issues are addressed using three activities, design assembly, and use. The component dimension addressed with twoactivity design and realization. Concurrency is achieved in two ways; System and component activities occur simultaneously and can be modeled using the state oriented approach a typical client server application is implemented with many components, each of which can be designed and realized concurrently. The concurrent process model is applicable to all types of software development and provides an accurate picture of the current state of a project. Rather than confining software-engineering activities to a sequence of events, it defines a net work of activities. Each activity on the network exists simultaneously with other activities. Events generated within a given activity or at some other place in the activity network trigger transitions among the sates of an activity. Component based development model: This model incorporates the characteristics of the spiral model. It is evolutionary in nature, demanding an iterative approach to the creation of software. However, the component-based development model composes applications from prepackaged software components called classes.

HARVINDER SINGH

511025273

1


1. D ESCRIBE THE CONCURRENT DEVELOPMENT MODEL IN YOUR OWN WORDS .

(CONTD)

Classes created in past software engineering projects are stored in a class library or repository. Once candidate classes are identified, the class library is searched to determine if these classes already exist. If they do, they are extracted from the library and reused. If a candidate class does not reside in the library, it is engineered using object-oriented methods. The first iteration of the application to be built is then composed using classes extracted from the library and any new classes built to meet the unique needs of the application. Process flow then returns to the spiral and will ultimately re-enter the component assembly iteration during subsequent passes through the engineering activity. The component based development model leads to software reuse, and reusability provides software engineers with a number of measurable benefits although it is very much dependent on the robustness of the component library.

UNDER DEVELOPMENT

AWAITING CHANGES

UNDER REVISION

UNDER REVIEW

BASELINDED

DONE

Represents state of a software engineered activity

One element of concurrent process model

HARVINDER SINGH

511025273

2


2. E XPLAIN THE FOLLOWING CONCEPTS WITH RESPECT TO S OFTWARE R ELIABILITY:A) Software Reliability Metrics Metrics which have been used for software reliability specification are shown in below Figure. The choice of which metric should be used depends on the type of system to which it applies and the requirements of the application domain. For some systems, it may be appropriate to use different reliability metrics for different sub-systems. M ETRIC POFOD PROB AB ILI T Y OF FAILURE ON DEM AN D ROCOF RATE OF FAILURE OCCURREN CE EXPLAN ATI O N This is measure of the likelihood that the system will fail when a service request is made. For example, a POFOD of 0,001 means that 1 out of 1000 service requests may result in failure. This is a measure of the frequency of occurrence with which unexpected behavior is likely to occur. For example, a ROCOF of 2/100 mans that 2 failures are likely to occur in each 100 operational time units. This metric is sometimes called the failure intensity. This is a measure of the time between observed system failures. For example, an MTTF of 500 time units. If the system is not being changed, it is the reciprocal of the ROCOF. This is a measure of how likely the system is to be available for use. For example, an availability of 0.998 means that in every 1000 time units, the system is likely to be available for 998 of these EXAM PLE SYSTE M Safety critical and non-stop systems, such as hardware control systems.

Operating systems, transaction processing system.

M TTF M EAN TIM E TO FAILURE

Systems with long transactions such as CAD system. The MTTF must be greater than the transaction time.

AVAIL AVAILAB ILIT Y

Continuously running systems such as telephone switching system

Reliability matrix In some cases, system users are most concerned about how often the system will fail, perhaps because there is a significant cost in restarting the system. In those cases, a metric based on a rate of failure occurrence (ROCOF) or the mean time to failure should be used. In other cases, it is essential that a system should always meet a request for service because there is some cost in failing to deliver the service. The number of failures in some time period is less important. In those cases, a metric based on the probability of failure on demand (POFOD) should be used. Finally, users or system operators may be mostly concerned that the system is available when a request for service is made. They will incur some loss if the system is unavailable. Availability (AVAIL). Which takes into account repair or restart time, is then the most appropriate metric.HARVINDER SINGH 511025273

3


2. E XPLAIN THE FOLLOWING CONCEPTS WITH RESPECT TO S OFTWARE R ELIABILITY:There are three kinds of measurement, which can be made when assessing the reliability of a system: 1. 2. 3. The number of system failures given a number of systems inputs. This is used to measure the POFOD. The time (or number of transaction) between system failures. This is used to measure ROCOF and MTTF.

(CONTD)

The elapsed repair or restart time when a system failure occurs. Given that the system must be continuously available, this is used to measure AVAIL.

Time is a factor in all of this reliability metrics. It is essential that the appropriate time units should be chosen if measurements are to be meaningful. Time units, which may be used, are calendar time, processor time or may be some discrete unit such as number of transactions. Software reliability specification System requirements documents, reliability requirements are expressed in an informal, qualitative, untestable way. Ideally, the required level of reliability should be expressed quantitatively in the software requirement specification. Depending on the type of system, one or more of the metrics discussed in the previous section may be used for reliability specifications. Statistical testing techniques (discussed later) should be used to measure the system reliability. The software test plan should include an operational profile of the software to assess its reliability. The steps involved in establishing a reliability specification are as follows: 1. 2. For each identified sub-system, identify the different types of system failure, which may occur and analyze the consequences of these failures. From the system failure analysis, partition failures into appropriate classes. A reasonable starting point is to use the failure types shown in Figure shown below. For each failure class identified, define the reliability requirement using the appropriate reliability metric. It is not necessary to use the same metric for different classes of failure. For example, where a failure requires some intervention to recover from it, the probability of that failure occurring on demand might be the most appropriate metric. When automatic recover is possible and the effect of the failure is some user inconvenience, ROCOF might be more appropriate.

The cost of developing and validating a reliability specification for software system is very high. Statistical testing Statistical testing is a software testing process in which the objective is to measure the reliability of the software rather than to discover software faults. It users different test data from defect testing, which is intended to find faults in the software.

HARVINDER SINGH

511025273

4


2. E XPLAIN THE FOLLOWING CONCEPTS WITH RESPECT TO S OFTWARE R ELIABILITY:FAILURE CLASSQ TRAN SIEN T PERM AN EN T RECOVERAB L E UN RECOVERAB L E N ON -CURRUP TIN G CURRUPTIN G DESCRIPTI ON Occurs only with certain inputs Occurs with all inputs System can recover without operator intervention Operator intervention needed to recover from failure Failure does not corrupt system state or data Failure corrupts system state or data

(CONTD)

Failure classificationThe steps involved in statistical testing are: 1. 2. 3. 4. Determine the operational profile of the software. The operational profile is the probable pattern of usage of the software. This can be determined by analyzing historical data to discover the different classes of input to the program and the probability of their occurrence. Select or generate a set of test data corresponding to the operational profile. Apply these test cases to the program, recording the amount of execution time between each observed system failure. It may not be appropriate to use raw execution time. As discussed in the previous section, the time units chosen should be appropriate for the reliability metric used. After a statistically significant number of failures have been observed, the software reliability can then be computed. This involves using the number of failures detected and the time between these failures to computer the required reliability metric.

This approach to reliability estimation is not easy to apply in practice. The difficulties, which arise, are due to: Operational profile uncertainty; High cost of operational profile generation; Statistical uncertainty when high reliability is specified.HARVINDER SINGH 511025273

5


2. E XPLAIN THE FOLLOWING CONCEPTS WITH RESPECT TO S OFTWARE R ELIABILITY:B) Programming for Reliability

(CONTD)

There is a general requirement for more reliable systems in all application domains. Customers expect their software to operate without failures and to be available when it is required. Improved programming techniques, better programming languages and better quality management have led to very significant improvements in reliability for most software. However, for some systems, such as those, which control unattended machinery, these normal techniques may not be enough to achieve the level of reliability required. In these cases, special programming techniques may be necessary to achieve the required reliability. Some of these techniques are discussed in this chapter. Reliability in a software system can be achieved using three strategies: Fault avoidance: This is the most important strategy, which is applicable to all types of system. The design and implementation process should be organized with the objective of producing fault-free systems. Fault tolerance: This strategy assumes that residual faults remain in the system. Facilities are provided in the software to allow operation to continue when these faults cause system failures. Fault detection: Faults are detected before the software is put into operation. The software validation process uses static and dynamic methods to discover any faults, which remain in a system after implementation. Fault avoidance A good software process should be oriented towards fault avoidance rather than fault detection and removal. It should have the objective of developing fault-free software. Fault-free software means software, which conforms to its specification. Of course, there may be errors in the specification or it may not reflect the real needs of the user so fault-free software does not necessarily mean that the software will always behave as the user wants. Fault avoidance and the development of fault-free software relies on : 1. 2. 3. 4. 5. The availability of a precise system specification, which is an unambiguous description of what, must be implemented. The adoption of an organizational quality philosophy in which quality is the driver of the software process. Programmers should expect to write bugfree program. The adoption of an approach to software design and implementation which is based on information hiding and encapsulation and which encourages the production of readable programs. The use of a strongly typed programming language so that possible errors are detected by the language compiler. Restriction on the use of programming construct, such as pointers, which are inherently error-prone.511025273

HARVINDER SINGH

6


2. E XPLAIN THE FOLLOWING CONCEPTS WITH RESPECT TO S OFTWARE R ELIABILITY:

(CONTD)

Achieving fault-free software is virtually impossible if low-level programming. Languages with limited type checking are used for program development.Cost Per error deleted

Very few

Few Number of residual errors

Many

The increasing cost of residual fault of removal We must be realistic and accept that human errors will always occur. Faults may remain in the software after development. Therefore, the development process must include a validation phase, which checks the developed software for the presence of faults. This validation phase is usually very expensive. As faults are removed from a program, the cost of finding and removing remaining faults tends to rise exponentially. As the software becomes more reliable, more and more testing is required to find fewer and fewer faults. Structured programming and error avoidance Structured programming is term which is to mean programming without using go to statements, programming using only while loops and if statements as control constructs and designing using a top-down approach. The adoption of structured programming was an important milestone in the development of software engineering because it was the first step away from an undisciplined approach to software development. Go to statement was an inherently errorprone programming construct. The disciplined use of control structures force programmers to think carefully about their program. Hence they are less likely to make mistakes during development. Structured programming means programs can be read sequentially and are therefore easier to understand and inspect. However, avoiding unsafe control statements is only the first step in programming for reliability. Faults are less likely to be introduced into programs if the use of these constructs is minimized. These constructs include:HARVINDER SINGH 511025273

7


2. E XPLAIN THE FOLLOWING CONCEPTS WITH RESPECT TO S OFTWARE R ELIABILITY:1.

(CONTD)

Floating-point numbers: Floating-point numbers are inherently imprecise. They present a particular problem when they are compared because representation imprecision may lead to invalid comparisons. Fixed-point numbers, where a number is represented to a given number of decimal places, are safer as exact comparisons are possible. Pointer: Pointers are low-level constructs, which refer directly to areas of the machine memory. They are dangerous because errors in their use can be devastating and because they allow aliasing. This means the same entity may be referenced using different names. Aliasing makes programs harder to may be referenced using different names. Alilasing makes programs harder to understand so that errors are more difficult to find. However, efficiency requirements mean that it is often impractical to avoid the use of pointers. Dynamic memory allocation: Program memory is allocated at run-time rather than compile-time. The danger with this is that the memory may not be de-allocated so that the system eventually runs out of available memory. This can be a very subtle type of errors to detect as the system may run successfully for a long time before the problem occurs. Parallelism: Parallelism is dangerous because of the difficulties of predicting the subtle effects of timing interactions between parallel process. Timing problems cannot usually e detected by program inspection and the peculiar combination of circumstances, which cause a timing problem, may not result during system testing. Parallelism may be unavoidable but its use should be carefully controlled to minimize inter-process dependencies. Programming language facilities, such as Ada tasks, help avoid some of the problems of parallelism as the compiler can detect some kinds of programming errors. Recursion: Recursion is the situation in which a subroutine calls itself or calls another subroutine, which then calls the calling subroutine. Its use can result in very concise programs but it can be difficult to follow the logic of recursive programs. Errors in using recursion may result in the allocation of all they systems memory as temporary stack variables are created. Interrupts: Interrupts are a means of forcing control to transfer to a section of code irrespective of the code currently executing. The dangers of this are obvious as the interrupt may cause a critical operation to be terminated.

2.

3.

4.

5.

6.

Fault tolerance A fault-tolerant system can continue in operation after some system failures have occurred. Fault tolerance is needed in situations where system failure would cause some accident or where a loss of system operation would cause large economic losses. For example, the computers in an aircraft must continue in operation until the aircraft has landed; the computers in an traffic control system must be continuously available. Fault-tolerance facilities are required if the system is to failure. There are four aspects to fault tolerance. 1. 2. Failure detection: The system must detect a particular state combination has resulted or will result in a system failure. Damage assessment: The parts of the system state, which have been affected by the failure, must be detected.511025273

HARVINDER SINGH

8


2. E XPLAIN THE FOLLOWING CONCEPTS WITH RESPECT TO S OFTWARE R ELIABILITY:3.

(CONTD)

Fault recovery: The system must restore its state to a known safe state. This may be achieved by correcting the damaged state or by restoring the system the system to a known safe state. Forward error recovery is more complex as it involves diagnosing system faults and knowing what the system state should have been had the faults not caused a system failure. Fault repair: This involves modifying the system so that the fault does not recur. In many cases, software failures are transient and due to a peculiar combination of system inputs. No repair is necessary as normal processing can resume immediately after fault recovery. This is an important distinction between hardware and software faults.

4.

There has been a need for many years to build fault-tolerant hardware. The most commonly used hardware fault-tolerant technique is based around the notion of triple-modular redundancy (TMR) shown in the below figure. The hardware unit is replicated three (or sometimes more) times. The output from each unit is compared. If one of the units fails and does not produce the same output as the other units, its output is ignored. The system functions with two working units.A1 Output Comparator

A2

A3

Triple modular redundancy to cope with hardware failure The weakness of both these approaches to fault tolerance is that they are based on the assumption that the specification is correct. They do not tolerate specification errors. There have been two comparable approaches to the provision of software fault tolerance. Both have been derived from the hardware model where a component is replicated. 1) N-version programming: Using a common specification, the software system is implemented in a number of different versions by different teams. These versions are executed in parallel. Their outputs are compared using a voting system and inconsistent outputs are rejected. At least three versions of the system should be available.Version - 1 Output Comparator

Version - 2

Version - 3

N-version programmingHARVINDER SINGH 511025273

9



(CONTD)

2) Recovery Blocks: this is a finer grain approach to fault tolerance. Each program component includes a test to check if the component has executed successfully. It also includes alternative code, which allows the system to back-up and repeat the computation if the test detects a failure. Unlike Nversion programming, the implementation is different rather than independent implementation of the same specification. They are executed in sequence rather than in parallel.Try algorithm 1 Test for success

Algorithm 1

Acceptance TestRetry

Continue execution it acceptance test success Signal Exception if all algorithms fail

Acceptance test fails-retry

Retest

Retest

Algorithm 2

Algorithm 2Recovery blocks

Exception Handling

When an error of some kind or an unexpected event occurs during the execution of a program, this is called an exception. Exceptions may be caused by hardware or software errors. When an exception has not been anticipated, control is transferred to system exceptions handling mechanism. If an exception has been anticipated, code must be included in the program to detect and handle that exception. Most programming languages do not include facilities to detect and handle exceptions. The normal decision constructs (if statements) of the language must be used to detect the exception and control constructs used to transfer control to exception occurs in a sequence of nested procedure calls, there is not easy way to transmit it from one procedure to another. Consider example as shown in figure below a number of nested procedure calls where procedure A calls procedure B which calls procedure C. If an exception occurs during the execution of C this may be so serious that execution of B cannot continue. Procedure B has to return immediately to Procedure A, which must also be informed that B has terminated abnormally and that an exception has occurred.A B: B C: Call sequence Exception Occurrence C Exception return

Exception return in embedded procedure callsHARVINDER SINGH 511025273

10


2. E XPLAIN THE FOLLOWING CONCEPTS WITH RESPECT TO S OFTWARE R ELIABILITY:An exception handler is something like a case statement. It states exception names and appropriate actions for each exception.void Contorl_freezer (const float Danger_temp) { Float Ambient_temp: // try means exceptions will be handled in this block // Assume that Sensor. Temperature_dial and Pump are // objects which have been declared elsewhere Try{ while (true) Ambient_temp Sensor.Get_temperature 0: & (Ambient_temp > Temperature_dial_Setting 0 ) &(Pump Status 0 == off) { Pump Switch (on): Wait (Cooding_time): } else If (Pump_Status 0 == on) Pump_Switch (off) If ( Ambient_temp > Danger_temp ) throw Freezer_too_hot ( ): } //end of while loop } //end of exception handing try block //catch indicates the exception handing code Catch ( Freezer_too_hot ) AlarmActivate 0: }

(CONTD)

Exceptions in a freezer temperature controller(C++) Above table illustrates the use of exceptions and exception handling. These program fragments show the design of a temperature controller on a food freezer. The required temperature may be set between 18 and 40 degrees Celsius. Food may start to defrost and bacteria become active at temperatures over 18 degrees. The control system maintains this temperature by switching a refrigerant pump on and off depending on the value of a temperature sensor. If the required temperature cannot be maintained, the controlled sets off an alarm. The temperature of the freezer is discovered by interrogating an object called Sensor and the required temperature by inspecting an object called the exceptions Freezer_too_hot and Control_problem and the type FREEZER_TEMP are declared. There are no built-in exceptions in C++ but other information is declared in a separate header file. The temperature controller tests the temperature and switches the pump as required. If the temperature is too hot, it transfers control to the exception handler, which activates an alarm. In C++, Once an exception has been, it is not re-thrown.HARVINDER SINGH 511025273

11


2. E XPLAIN THE FOLLOWING CONCEPTS WITH RESPECT TO S OFTWARE R ELIABILITY:Defensive programming

(CONTD)

Defensive programming is an approach to program development whereby programmers assume that there may be undetected faults or inconsistencies in their programs. Redundant code is incorporated to check the System State after modifications and to ensure that the state change is consistent. If inconsistencies are detected, the state change is retracted or the state is restored to a known correct state. Defensive programming is an approach to fault tolerance, which can be carried out without a fault-tolerant controller. The techniques used, however, are fundamental to the activities in the fault tolerance process, namely detecting a failure, damage assessment, and recovering from that failure. Failure prevention Programming languages such as Ada and C++ allow many errors which cause state corruption and system failure to be detected at compile-time. The compiler can detect those problems which uses the strict type rules of the language. Compiler checking is obviously limited to static values but the compiler can also automatically add code to a program to perform run-time checks. Damage assessment Damage assessment involves analyzing the system state to gauge the extent of the state corruption. In many cases, corruption can be avoided by checking for fault occurrence before finally committing a change of state. If a fault is detected, the state change is not accepted so that no damage is caused. However, damage assessment may be needed when a fault arises because a sequence of state changes (all of which are individually correct) causes the system to enter an incorrect state. The role of the damage assessment procedures is not to recover from the fault but to assess what parts of the state space have been affected by the fault. Damage can only be assessed if it is possible to apply some validity function, which checks if the state is consistent. If inconsistencies are found, these are highlighted or signaled in some way. Other techniques which can be used for fault detection and damage assessment are dependent on the system state representation and on the application . Possible methods are: The use of checksums in data exchange and check digits in numeric data; The use of redundant links in data structures which contain pointers; The use of watchdog timers in concurrent systems. A checksum is a value that is computed by applying some mathematical function to the data. The function used should give a unique value for the packet of data, which is exchanged. The sender who applies the checksum function to the data and appends that function value to the data computes this checksum. The receiver applies the same function to the data and compares the checksum values. If these differ, some data corruption has occurred.HARVINDER SINGH 511025273

12



(CONTD)

When linked data structures are used, the representation can be made redundant by including backward pointers. That is, for every reference from A to B, there exists a comparable reference from B to A. It is also possible to keep count of the number of elements in the structure. Checking can determine whether or not all pointers have an inverse value and whether or not the stored size and the computed structure size are the same. When processes must react within a specific time period, a watch-dog timer may be installed. A watch-dog timer is a timer which must be reset by the executing process after its action is complete. It is started at the same time as a process and times the process execution. If, for some reason the process fails to terminate, the watch-dog timer is not reset. The controller can therefore detect that a problem has arisen and take action to force process termination. Fault recovery Fault recovery is the process of modifying the state space of the system so that the effects of the fault are minimized. The system can continue in operation, perhaps in same degraded form. Forward recovery involves trying to correct the damaged System State. Backward recovery restores the System State to a known correct state. There are two general situations where forward error recovery can be applied: 1. 2. When coded is corrupted The use of coding techniques which add redundancy to the data allows errors to be corrected as well as detected. When linked structures are corrupted if forward and backward pointers are included in the data structure, the structure can be recreated if enough pointers remain uncorrupted. This technique is frequently used for file system and database repair.

Backward error recovery is a simpler technique, which restores the state to a known safe state after an error has been detected. Most database systems include backward error recovery. When a user initiates a database computation a transaction is initiated. Changes made during that transaction are not immediately incorporated in the database. The database is only updated after the transaction is finished and no problems are detected. If the transaction fails, the database is not updated. Design by Contract Meyer suggests an approach to design, called design by contract, to help ensure that a design meets its specifications. He begins by viewing software system as a set of communicating components whose interaction is based on a precisely defined specification of what each component is supposed to do. These specifications, called contracts, govern how the component is to interact with other components and systems. Such specification cannot guarantee correctness, but it forms a good basis for testing and validation. Contract is written between two parties when one commissions the other for a particular service or product. Each party expects some benefit for some obligation; the supplier produces a service or product in a given period of time in exchange for money, and the client accepts the service or product for the money. The contract makes the obligation and benefits explicit.HARVINDER SINGH 511025273

13



(CONTD)

Mayer applies the notion of a contract to software. A software component, called a client, adopts a strategy to perform a set of tasks, t1, t2,tn. In turn, each nontrivial subtask, it is executed when the client calls another component, the supplier, to perform it. That is a contract between the two components to perform the sub-task. Each contract covers mutual obligation (called preconditions), benefits (called postconditions), and consistency constraints (called invariant). Together, these contract properties are called assertions. For example, suppose the client component has a table where each element is identified by a character string used as a key. Our suppliers components task is to insert an element from the table into a dictionary of limited size. We can describe the contract between the two components in the following way. 1. 2. 3. 4. The client component ensures that the dictionary is not full and that the key is nonempty. The supplier component records the element in table. The client component accesses the updated table where the element appears. If the table is full or the key is empty, no action is taken.

HARVINDER SINGH

511025273

14


3. S UGGEST SIX REASONS WHY SOFTWARE RELIABILITY IS IMPORTANT. U SING AN EXAMPLE , EXPLAIN THE DIFFICULTIES OF DESCRIBING WHAT SOFTWARE RELIABILITY MEANS .The need for a means to objectively determine software reliability comes from the desire to apply the techniques of contemporary engineering fields to the development of software. That desire is a result of the common observation, by both lay-persons and specialists, that computer software does not work the way it ought to. In other words, software is seen to exhibit undesirable behaviour, up to and including outright failure, with consequences for the data which is processed, the machinery on which the software runs, and by extension the people and materials which those machines might negatively affect. The more critical the application of the software to economic and production processes, or to life-sustaining systems, the more important is the need to assess the software's reliability. Regardless of the criticality of any single software application, it is also more and more frequently observed that software has penetrated deeply into most every aspect of modern life through the technology we use. It is only expected that this infiltration will continue, along with an accompanying dependency on the software by the systems which maintain our society. As software becomes more and more crucial to the operation of the systems on which we depend, the argument goes, it only follows that the software should offer a concomitant level of dependability. In other words, the software should behave in the way it is intended, or even better, in the way it should. A software quality factor is a non-functional requirement for a software program which is not called up by the customer's contract, but nevertheless is a desirable requirement which enhances the quality of the software program. Note that none of these factors are binary; that is, they are not either you have it or you dont traits. Rather, they are characteristics that one seeks to maximize in ones software to optimize its quality. So rather than asking whether a software product has factor x, ask instead the degree to which it does (or does not). Some software quality factors are listed here: Understandability Clarity of purpose. This goes further than just a statement of purpose; all of the design and user documentation must be clearly written so that it is easily understandable. This is obviously subjective in that the user context must be taken into account: for instance, if the software product is to be used by software engineers it is not required to be understandable to the layman. Completeness Presence of all constituent parts, with each part fully developed. This means that if the code calls a subroutine from an external library, the software package must provide reference to that library and all required parameters must be passed. All required input data must also be available. Conciseness Minimization of excessive or redundant information or processing. This is important where memory capacity is limited, and it is generally considered good practice to keep lines of code to a minimum. It can be improved by replacing repeated functionality by one subroutine or function which achieves that functionality. It also applies to documents.HARVINDER SINGH 511025273

15


3. S UGGEST SIX REASONS WHY SOFTWARE RELIABILITY IS IMPORTANT. U SING AN EXAMPLE , EXPLAIN THE DIFFICULTIES OF DESCRIBING WHAT SOFTWARE RELIABILITY MEANS . (CONTD)Portability Ability to be run well and easily on multiple computer configurations. Portability can mean both between different hardwaresuch as running on a PC as well as a smartphoneand between different operating systemssuch as running on both Mac OS X and GNU/Linux. Consistency Uniformity in notation, symbology, appearance, and terminology within itself. Maintainability Propensity to facilitate updates to satisfy new requirements. Thus the software product that is maintainable should be well-documented, should not be complex, and should have spare capacity for memory, storage and processor utilization and other resources. Testability Disposition to support acceptance criteria and evaluation of performance. Such a characteristic must be built-in during the design phase if the product is to be easily testable; a complex design leads to poor testability. Usability Convenience and practicality of use. This is affected by such things as the human-computer interface. The component of the software that has most impact on this is the user interface (UI), which for best usability is usually graphical (i.e. a GUI). Reliability Ability to be expected to perform its intended functions satisfactorily. This implies a time factor in that a reliable product is expected to perform correctly over a period of time. It also encompasses environmental considerations in that the product is required to perform correctly in whatever conditions it finds itself (sometimes termed robustness). Efficiency Fulfillment of purpose without waste of resources, such as memory, space and processor utilization, network bandwidth, time, etc.

HARVINDER SINGH

511025273

16


3. S UGGEST SIX REASONS WHY SOFTWARE RELIABILITY IS IMPORTANT. U SING AN EXAMPLE , EXPLAIN THE DIFFICULTIES OF DESCRIBING WHAT SOFTWARE RELIABILITY MEANS . (CONTD)Security Ability to protect data against unauthorized access and to withstand malicious or inadvertent interference with its operations. Besides the presence of appropriate security mechanisms such as authentication, access control and encryption, security also implies resilience in the face of malicious, intelligent and adaptive attackers. Time Example There are two major differences between hardware and software curves. One difference is that in the last phase, software does not have an increasing failure rate as hardware does. In this phase, software is approaching obsolescence; there are no motivation for any upgrades or changes to the software. Therefore, the failure rate will not change. The second difference is that in the useful-life phase, software will experience a drastic increase in failure rate each time an upgrade is made. The failure rate levels off gradually, partly because of the defects found and fixed after the upgrades.

Test/Debug

Useful Life

Obsolescence

Failure Rate

Upgrade

Upgrade

Time

Upgrade

HARVINDER SINGH

511025273

17


4. W HAT ARE THE ESSENTIAL SKILLS AND TRAITS NECESSARY FOR EFFECTIVE PROJECT MANAGERS IN SUCCESSFULLY HANDLING PROJECTS ?The Successful Project Manager: A successful project manager knows how to bring together the definition and control elements and operate them efficiently. That means you will need to apply the leadership skills you already apply in running a department and practice the organizational abilities you need to constantly look to the future. In other words, if youre a qualified department manager, you already possess the skills and attributes for succeeding as a project manager. The criteria by which you will be selected will be similar. Chances are, the project youre assigned will have a direct relationship to the skills you need just to do your job. For example: Organizational and leadership experience. An executive seeking a qualified project manager usually seeks someone who has already demonstrated the ability to organize work and to lead others. He or she assumes that you will succeed in a complicated long-term project primarily because you have already demonstrated the required skills and experience. Contact with needed resources. For projects that involve a lot of coordination between departments, divisions, or subsidiaries, top management will look for a project manager who already communicates outside of a single department. If you have the contacts required for a project, it will naturally be assumed that you are suited to run a project across departmental lines. Ability to coordinate a diverse resource pool. By itself, contact outside of your department may not be enough. You must also be able to work with a variety of people and departments, even when their backgrounds and disciplines are dissimilar. For example, as a capable project manager, you must be able to delegate and monitor work not only in areas familiar to your own department but in areas that are alien to your background. Communication and procedural skills. An effective project manager will be able to convey and receive information to and from a number of team members, even when particular points of view are different from his own. For example, a strictly administrative manager should understand the priorities of a sales department, or a customer service manager may need to understand what motivates a production crew. Ability to delegate and monitor work. Project managers need to delegate the work that will be performed by each team member, and to monitor that work to stay on schedule and within budget. A contractor who builds a house has to understand the processes involved for work done by each subcontractor, even if the work is highly specialized. The same is true for every project manager. Its not enough merely to assign someone else a task, complete with a schedule and a budget. Delegation and monitoring are effective only if youre also able to supervise and assess progress. Dependability. Your dependability can be tested only in one way: by being given responsibility and the chance to come through. Once you gain the reputation as a manager who can and does respond as expected, youre ready to take on a project. These project management qualifications read like a list of evaluation points for every department manager. If you think of the process of running your department as a project of its own, then you already understand what its like to organize a projectthe difference, of course, being that the project takes place in a finite time period, whereas your departmental tasks are ongoing. Thus, every successful manager should be ready to tackle a project, provided it is related to his or her skills, resources, and experience.HARVINDER SINGH 511025273

18


5. W HICH ARE THE FOUR PHASES OF DEVELOPMENT ACCORDING TO R ATIONAL U NIFIED P ROCESS ?The Rational Unified Process is a Software Engineering Process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget. The Rational Unified Process is a process product, developed and maintained by Rational Software. The development team for the Rational Unified Process are working closely with customers, partners, Rationales product groups as well as Rationales consultant organization, to ensure that the process is continuously updated and improved upon to reflect recent experiences and evolving and proven best practices. The Rational Unified Process enhances team productivity, by providing every team member with easy access to a knowledge base with guidelines, templates and tool mentors for all critical development activities. By having all team members accessing the same knowledge base, no matter if you work with requirements, design, test, project management, or configuration management, we ensure that all team members share a common language, process and view of how to develop software. The Rational Unified Process activities create and maintain models. Rather than focusing on the production of large amount of paper documents, the Unified Process emphasizes the development and maintenance of modelssemantically rich representations of the software system under development. The Rational Unified Process is a guide for how to effectively use the Unified Modeling Language (UML). The UML is an industry-standard language that allows us to clearly communicate requirements, architectures and designs. The UML was originally created by Rational Software, and is now maintained by the standards organization Object Management Group (OMG). Effective Deployment of 6 Best Practices The Rational Unified Process describes how to effectively deploy commercially proven approaches to software development for software development teams. These are called best practices not so much because you can precisely quantify their value, but rather, because they are observed to be commonly used in industry by successful organizations. The Rational Unified Process provides each team member with the guidelines, templates and tool mentors necessary for the entire team to take full advantage of among others the following best practices: 1. 2. 3. 4. 5. 6. Develop software iteratively Manage requirements Use component-based architectures Rational Unified Process: Best Practices for Software development Teams Visually model software Verify software quality Control changes to software

Develop Software Iteratively Given todays sophisticated software systems, it is not possible to sequentially first define the entire problem, design the entire solution, build the software and then test the product at the end. An iterative approach is required that allows an increasing understanding of the problem through successive refinements, and to incrementally grow an effective solution over multiple iterations.HARVINDER SINGH 511025273

19


5. W HICH ARE THE FOUR PHASES OF DEVELOPMENT ACCORDING TO R ATIONAL U NIFIED P ROCESS ? (CONTD)The Rational Unified Process supports an iterative approach to development that addresses the highest risk items at every stage in the lifecycle, significantly reducing a projects risk profile. This iterative approach helps you attack risk through demonstrable progress frequent, executable releases that enable continuous end user involvement and feedback. Because each iteration ends with an executable release, the development team stays focused on producing results, and frequent status checks help ensure that the project stays on schedule. An iterative approach also makes it easier to accommodate tactical changes in requirements, features or schedule. Manage Requirements The Rational Unified Process describes how to elicit, organize, and document required functionality and constraints; track and document tradeoffs and decisions; and easily capture and communicate business requirements. The notions of use case and scenarios proscribed in the process has proven to be an excellent way to capture functional requirements and to ensure that these drive the design, implementation and testing of software, making it more likely that the final system fulfills the end user needs. They provide coherent and traceable threads through both the development and the delivered system. Use Component-based Architectures The process focuses on early development and baselining of a robust executable architecture, prior to committing resources for full-scale development. It describes how to design a resilient architecture that is flexible, accommodates change, is intuitively understandable, and promotes more effective software reuse. The Rational Unified Process supports component-based software development. Components are non-trivial modules, subsystems that fulfill a clear function. The Rational Unified Process provides a systematic approach to defining an architecture using new and existing components. These are assembled in a well-defined architecture, either ad hoc, or in a component infrastructure such as the Internet, CORBA, and COM, for which an industry of reusable components is emerging. Visually Model Software The process shows you how to visually model software to capture the structure and behavior of architectures and components. This allows you to hide the details and write code using graphical building blocks. Visual abstractions help you communicate different aspects of your software; see how the elements of the system fit together; make sure that the building blocks are consistent with your code; maintain consistency between a design and its implementation; and promote unambiguous communication. The industrystandard Unified Modeling Language (UML), created by Rational Software, is the foundation for successful visual modeling. Verify Software Quality Poor application performance and poor reliability are common factors which dramatically inhibit the acceptability of todays software applications. Hence, quality should be reviewed with respect to the requirements based on reliability, functionality, application performance and system performance. The Rational Unified Process assists you in the planning, design, implementation, execution, and evaluation of these test types. Quality assessment is built into the process, in all activities, involving all participants, using objective measurements and criteria, and not treated as an afterthought or a separate activity performed by a separate group.HARVINDER SINGH 511025273

20


5. W HICH ARE THE FOUR PHASES OF DEVELOPMENT ACCORDING TO R ATIONAL U NIFIED P ROCESS ? (CONTD)Control Changes to Software The ability to manage change is making certain that each change is acceptable, and being able to track changes is essential in an environment in which change is inevitable. The process describes how to control, track and monitor changes to enable successful iterative development. It also guides you in how to establish secure workspaces for each developer by providing isolation from changes made in other workspaces and by controlling changes of all software artifacts (e.g., models, code, documents, etc.). And it brings a team together to work as a single unit by describing how to automate integration and build management. The Rational Unified Process product consists of: A web-enabled searchable knowledge base providing all team members with guidelines, templates, and tool mentors for all critical development activities. The knowledge base can further be broken down to: Extensive guidelines for all team members, and all portions of the software lifecycle. Guidance is provided for both the high-level thought process, as well as for the more tedious day-to-day activities. The guidance is published in HTML form for easy platform-independent access on your desktop. Tool mentors providing hands-on guidance for tools covering the full lifecycle. The tool mentors are published in HTML form for easy platformindependent access on your desktop. See section "Integration with Tools" for more details. Rational Rose examples and templates providing guidance for how to structure the information in Rational Rose when following the Rational Unified Process (Rational Rose is Rational's tool for visual modeling) SoDA templates more than 10 SoDA templates that helps automate software documentation (SoDA is Rationales Document Automation Tool) Microsoft Word templates more than 30 Word templates assisting documentation in all workflows and all portions of the lifecycle Microsoft Project Plans Many managers find it difficult to create project plans that reflects an iterative development approach. Our templates jump start the creation of project plans for iterative development, according to the Rational Unified Process. Development Kit: Describes how to customize and extend the Rational Unified Process to the specific needs of the adopting organization or project, as well as provides tools and templates to assist the effort. This development kit is described in more detail later in this section. Access to Resource Center containing the latest white papers, updates, hints, and techniques, as well as references to add-on products and services. A book "Rational Unified Process An Introduction", by Philippe Kruchten, published by Addison Wesley. The book is on 277 pages and provides a good introduction and overview to the process and the knowledge base.HARVINDER SINGH 511025273

21


6. D ESCRIBE THE C APABILITY M ATURITY M ODEL WITH SUITABLE REAL TIME EXAMPLES .The Capability Maturity Model (CMM)) is a multistaged, process definition model intended to characterize and guide the engineering excellence or maturity of an organizations software development processes. The Capability Maturity Model: Guidelines for Improving the Software Process (1995) contains an authoritative description. See also Paulk et al. (1993) and Curtis, Hefley, and Miller (1995) and, for general remarks on continuous process improvement, Somerville, Sawyer, and Viller (1999) (see Table 3.2). The model prescribes practices for planning, engineering, and managing software development and maintenance and addresses the usual goals of organizational system engineering processes: namely, quality improvement, risk reduction, cost reduction, predictable process, and statistical quality control (Oshana& Linger 1999). However, the model is not merely a program for how to develop software in a professional, engineering-based manner; it prescribes an evolutionary improvement path from an ad hoc, immature process to a mature, disciplined process (Oshana& Linger 1999). Walnau, Hissam, and Seacord (2002) observe that the ISO and CMM process standards established the context for improving the practice of software develop- meant by identifying roles and behaviors that define a software factory. The CMM identifies five levels of software development maturity in an organization: At level 1, the organizations software development follows no formal development process. The process maturity is said to be at level 2 if software management controls have been introduced and some software process is followed. A decisive feature of this level is that the organizations process is supposed to be such that it can repeat the level of performance that it achieved on similar successful past projects. This is related to a central purpose of the CMM: namely, to improve the predictability of the development process significantly. The major technical requirement at level 2 is incorporation of configuration management into the process. Configuration management(or change management, as it is sometimes called) refers to the processes used to keep track of the changes made to the development product (including all the intermediate deliverables) and the multifarious impacts of these changes. These impacts range from the recognition of development problems; identification of the need for changes; alteration of previous work; verification that agreed upon modifications have corrected the problem and that corrections have not had a negative impact on other parts of the system; etc. An organization is said to be at level 3 if the development process is standard and consistent. The project management practices of the organization are supposed to have been formally agreed on,defined, and codified at this stage of process maturity. Organizations at level 4 are presumed to have put into place qualitative and quantitative measures of organizational process. These process metrics are intended to monitor development and to signal trouble and indicate where and how a development is going wrong when problems occur. Organizations at maturity level 5 are assumed to have established mechanisms designed to ensure continuous process improvement and optimization. The metric feedbacks at this stage are not just applied to recognize and control problems with the current project as they were in level-4 organizations. They are intended to identify possible root causes in the process that have allowed the problems to occur and to guide the evolution of the process so as to prevent the recurrence of such problems in future projects, such as through the introduction of appropriate new technologies and tools.HARVINDER SINGH 511025273

22


6. D ESCRIBE THE C APABILITY M ATURITY M ODEL WITH SUITABLE REAL TIME EXAMPLES . (CONTD)The higher the CMM maturity level is, the more disciplined, stable, and well-defined the development process is expected to be and the environment is assumed to make more use of automated tools and the experience gained from many past successes (Zhiying 2003). The staged character of the model lets organizations progress up the maturity ladder by setting process targets for the organization. Each advance reflects a further degree of stabilization of an organizations development process, with each level institutionaliz[ing] a different aspect of the process (Oshana& Linger 1999). Each CMM level has associated key process areas (KPA) that correspond to activities that must be formalized to attain that level. For example, the KPAs at level 2 include configuration management, quality assurance, project planning and tracking, and effective management of subcontracted software. The KPAs at level 3 include intergroup communication, training, process definition, product engineering, and integrated software management. Quantitative process management and development quality define the required KPAs at level 4. Level 5 institutionalizes process and technology change management and optimizes defect prevention. Bamberger (1997), one of the authors of the Capability Maturity Model, addresses what she believes are some misconceptions about the model. For example, she observes that the motivation for the second level, in which the organization must have a repeatable software process, arises as a direct response to the historical experience of developers when their software development is out of control (Bamberger 1997). Often this is for reasons having to do with configuration management or mismanagement! Among the many symptoms of configuration mismanagement are: confusion over which version of a file is the current official one; inadvertent side effects when repairs by one developer obliterate the changes of another developer; inconsistencies among the efforts of different developers; etc. A key appropriate response to such actual or potential disorder is to get control of the product and the product pieces under development (configuration management) by (Bamberger 1997): Controlling the feature set of the product so that the impact/s of changes are more fully understood (requirements management) Using the feature set to estimate the budget and schedule while leveraging as much past knowledge as possible (project planning) Ensuring schedules and plans are visible to all the stakeholders (project tracking) Ensuring that the team follows its own plan and standards and corrects discrepancies when they occur (quality assurance) Bamberger contends that this kind of process establishes the basic stability and visibility that are the essence of the CMM repeatable level.

HARVINDER SINGH

511025273

23

FACULTY : K AMYA M AM

MC0072 COMPUTER GRAPHICS(Book ID: B0810) Assignment Set 2

M C0072 COM PUTER GRAPHICS

1. W RITE A SHORT NOTE ON THE FOLLOWINGS :A) Video mixing Video controller provides the facility of video mixing. In which it accepts information of two images simultaneously. One from frame buffer and other from television camera, recorder or other source. This is illustrated in below fig. The video controller merges the two received images to form a composite image. Frame Buffer Video Controller Monitor

Video Signal Source Video mixing There are two types of video mixing. In first, a graphics image is set into a video image. Here mixing is accomplished with hardware that treats a designated pixel value in the frame buffer as a flag to indicate that the video signal should be shown instead of the signal from the frame buffer, normally the designated pixel value corresponds to the background color of the frame buffer image. In the second type of mixing, the video image is placed on the top of the frame buffer image. Here, whenever background color of video image appears, the frame buffer is shown, otherwise the video image is shown. B) Frame buffer A frame buffer is a video output device that drives a video display from a memory buffer containing a complete frame of data. The information in the memory buffer typically consists of color values for every pixel (point that can be displayed) on the screen. Color values are commonly stored in 1-bit binary (monochrome), 4-bit palettized, 8-bit palettized, 16-bit high color and 24-bit true color formats. An additional alpha channel is sometimes used to retain information about pixel transparency. The total amount of the memory required to drive the frame buffer depends on the resolution of the output signal, and on the color depth and palette size. Frame buffers differ significantly from the vector displays that were common prior to the advent of the frame buffer. With a vector display, only the vertices of the graphics primitives are stored. The electron beam of the output display is then commanded to move from vertex to vertex, tracing an analog line across the area between these points. With a frame buffer, the electron beam (if the display technology uses one) is commanded to trace a left-to-right, top-to-bottom path across the entire screen, the way a television renders a broadcast signal. At the same time, the color information for each point on the screen is pulled from the frame buffer, creating a set of discrete picture elements (pixels).HARVINDER SINGH 511025273

24


1. W RITE A SHORT NOTE ON THE FOLLOWINGS :

(CONTD)

The term "frame buffer" has also entered into colloquial usage to refer to a backing store of graphical information. The key feature that differentiates a frame buffer from memory used to store graphics the output device is lost in this usage.

Display modes Frame buffers used in personal and home computing often had sets of defined "modes" under which the frame buffer could operate. These modes would automatically reconfigure the hardware to output different resolutions, color depths, memory layouts and refresh rate timings. In the world of Unix machines and operating systems, such conveniences were usually eschewed in favor of directly manipulating the hardware settings. This manipulation was far more flexible in that any resolution, color depth and refresh rate was attainable limited only by the memory available to the frame buffer. An unfortunate side-effect of this method was that the display device could be driven beyond its capabilities. In some cases this resulted in hardware damage to the display.[3] More commonly, it simply produced garbled and unusable output. Modern CRT monitors fix this problem through the introduction of "smart" protection circuitry. When the display mode is changed, the monitor attempts to obtain a signal lock on the new refresh frequency. If the monitor is unable to obtain a signal lock, or if the signal is outside the range of its design limitations, the monitor will ignore the frame buffer signal and possibly present the user with an error message. LCD monitors tend to contain similar protection circuitry, but for different reasons. Since the LCD must digitally sample the display signal (thereby emulating an electron beam), any signal that is out of range cannot be physically displayed on the monitor. Color palette Frame buffers have traditionally supported a wide variety of color modes. Due to the expense of memory, most early frame buffers used 1-bit (2 color), 2bit (4 color), 4-bit (16 color) or 8-bit (256 color) color depths. The problem with such small color depths is that a full range of colors cannot be produced. The solution to this problem was to add a lookup table to the frame buffers. Each "color" stored in frame buffer memory would act as a color index; this scheme was sometimes called "indexed color".HARVINDER SINGH 511025273

25



(CONTD)

The lookup table served as a palette that contained data to define a limited number (such as 256) of different colors. However, each of those [256] colors, itself, was defined by more than 8 bits, such as 24 bits, eight of them for each of the three primary colors. With 24 bits available, colors can be defined far more subtly and exactly, as well as offering the full range gamut which the display can show. While having a limited total number of colors in an image is somewhat restrictive, nevertheless they can be well chosen, and this scheme is markedly superior to 8-bit color. The data from the frame buffer in this scheme determined which of the [256] colors in the palette was for the current pixel, and the data stored in the lookup table (sometimes called the "LUT") went to three digital-to-analog converters to create the video signal for the display. The frame buffer's output data, instead of providing relatively-crude primary-color data, served as an index a number to choose one entry in the lookup table. In other words, the index determined which color and the data from the lookup table determined precisely what color to use for the current pixel. Memory access While frame buffers are commonly accessed via a memory mapping directly to the CPU memory space, this is not the only method by which they may be accessed. Frame buffers have varied widely in the methods used to access memory. Some of the most common are: Mapping the entire frame buffer to a given memory range. Port commands to set each pixel, range of pixels or palette entry. Mapping a memory range smaller than the frame buffer memory, then bank switching as necessary. The frame buffer organization may be chunky (packed pixel) or planar. Virtual frame buffers Many systems attempt to emulate the function of a frame buffer device, often for reasons of compatibility. The two most common "virtual" frame buffers are the Linux frame buffer device (fbdev) and the X Virtual Framebuffer (Xvfb). The X Virtual Framebuffer was added to the X Window System distribution to provide a method for running X without a graphical frame buffer. While the original reasons for this are lost to history, it is often used on modern systems to support programs such as the Sun Microsystems JVM that do not allow dynamic graphics to be generated in a headless environment. The Linux frame buffer device was developed to abstract the physical method for accessing the underlying frame buffer into a guaranteed memory map that is easy for programs to access. This increases portability, as programs are not required to deal with systems that have disjointed memory maps or require bank switching. Page flipping Since frame buffers are often designed to handle more than one resolution, they often contain more memory than is necessary to display a single frame atHARVINDER SINGH 511025273

26



(CONTD)

lower resolutions. Since this memory can be considerable in size, a trick was developed to allow for new frames to be written to video memory without disturbing the frame that is currently being displayed. The concept works by telling the frame buffer to use a specific chunk of its memory to display the current frame. While that memory is being displayed, a completely separate part of memory is filled with data for the next frame. Once the secondary buffer is filled (often referred to as the "back buffer"), the frame buffer is instructed to look at the secondary buffer instead. The primary buffer (often referred to as the "front buffer") becomes the secondary buffer, and the secondary buffer becomes the primary. This switch is usually done during the vertical blanking interval to prevent the screen from "tearing" (i.e., half the old frame is shown, and half the new frame is shown). Most modern frame buffers are manufactured with enough memory to perform this trick even at high resolutions. As a result, it has become a standard technique used by PC game programmers. Graphics accelerators As the demand for better graphics increased, hardware manufacturers created a way to decrease the amount of CPU time required to fill the frame buffer. This is commonly called a "graphics accelerator" in the Unix world. Common graphics drawing commands (many of them geometric) are sent to the graphics accelerator in their raw form. The accelerator then rasterizes the results of the command to the frame buffer. This method can save from thousands to millions of CPU cycles per command, as the CPU is freed to do other work. While early accelerators focused on improving the performance of 2D GUI systems, most modern accelerators focus on producing 3D imagery in real time. A common design is to send commands to the graphics accelerator using a library such as OpenGL. The OpenGL driver then translates those commands to instructions for the accelerator's graphics processing unit (GPU). The GPU uses those microinstructions to compute the rasterized results. Those results are bit blitted to the frame buffer. The frame buffer's signal is then produced in combination with built-in video overlay devices (usually used to produce the mouse cursor without modifying the frame buffer's data) and any analog special effects that are produced by modifying the output signal. An example of such analog modification was the anti-aliasing technique used by the 3dfx Voodoo cards. These cards add a slight blur to output signal that makes aliasing of the rasterized graphics much less obvious. Popular manufacturers of 3D graphics accelerators are Nvidia and ATI Technologies. C) Color table In color displays, 24- bits per pixel are commonly used, where 8-bits represent 256 levels for each color. Here it is necessary to read 24-bits for each pixel from frame buffer. This is very time consuming. To avoid this video controller uses look up table (LUT) to store many entries of pixel values in RGB format. With this facility, now it is necessary only to read index to the look up table from the frame buffer for each pixel. This index specifies the one of the entries in the look-up table. The specified entry in the loop up table is then used to control the intensity or color of the CRT. Usually, look-up table has 256 entries. Therefore, the index to the look-up table has 8-bits and hence for each pixel, the frame buffer has to store 8-bits per pixel instead of 24 bits. Fig. 2.6 shows the organization of a color (Video) look-up table.HARVINDER SINGH 511025273

27


1. W RITE A SHORT NOTE ON THE FOLLOWINGS :0 1 0 0 0 0 0 1

(CONTD)

Organization of a Video look-up table There are several advantages in storing color codes in a lookup table. Use of a color table can provide a "reasonable" number of simultaneous colors without requiring Iarge frame buffers. For most applications, 256 or 512 different colors are sufficient for a single picture. Also, table entries can be changed at any time, allowing a user to be able to experiment easily with different color combinations in a design, scene, or graph without changing the attribute settings for the graphics data structure. In visualization and image-processing applications, color tables are convenient means for setting color thresholds so that all pixel values above or below a specified threshold can be set to the same color. For these reasons, some systems provide both capabilities for colorcode storage, so that a user can elect either to use color tables or to store color codes directly in the frame buffer. Display technology The image is shown on a screen (also called a moniteur), which is an output peripheral device that allows a visual representation to be offered. This information comes from the computer, but in an indirect way. Indeed, the processor does not directly send information to the monitor, but processes the information coming from its Random access memory (RAM), then sends it to a graphics card that converts the information into electrical impulses, which it then sends to the monitor.Cyan (0,255,255) White (255,255,255) B

Blue

(0,0,255)

Magenta (255,0,255) G Yellow (255,255,0) Green

Black (0,0,0)

Red R (255,0,0)

HARVINDER SINGH

511025273

28



(CONTD)

Computer monitors are usually cathode tubes, i.e. a tube made out of glass in which an electron gun emits electrons which are then directed by a magnetic field towards a screen on which small phosphorescent elements (luminophores) are laid out, constituting points (pixels) that emit light when the electrons hit them. The pixel concept An image consists of a set of points called pixels (the word pixel is an abbreviation of PICture ELement) The pixel is thus the smallest component of a digital image. The entire set of these pixels is contained in a two-dimensional table constituting the image:

The screen-sweeping is carried out from left to right and from top to bottom, it is usual to indicate the pixel located at the top left hand corner of the image using the coordinates [0,0], this means that the directions of the image axes are the following: The direction of the X-axis is from left to right The direction of the Y-axis is from top to bottom, contrary to the conventional notation in mathematics, where the direction of the Y-axis is upwards. Definition and resolution The number of points (pixels) constituting the image, that is, its dimensions (the number of columns of the image multiplied by its number of rows) is known as the definition. An image 640 pixels wide and 480 pixels high will have a definition of 640 by 480 pixels, which is written as 640x480. On the other hand, the resolution, a term often confused with the definition, is determined by the number of points per unit of area, expressed in dots per inch (DPI), an inch being equivalent to 2.54 cm. The resolution thus makes it possible to establish the relationship between the number of pixels of an image and the actual size of its representation on a physical support. A resolution of 300 dpi thus means 300 columns and 300 lines of pixels in a square inch which thus yields 90000 pixels in a square inch. The 72 dpi reference resolution gives us a 1/72 (an inch divided by 72) pixel, that is to say 0.353mm, corresponding to a pica (Anglo-Saxon typographical unit).HARVINDER SINGH 511025273

29


1. W RITE A SHORT NOTE ON THE FOLLOWINGS :Colour models

(CONTD)

An image is thus represented by a two-dimensional table in which each cell is a pixel. To represent an image by means of computer, it is thus enough to create a pixel table in which each cell contains a value. The value stored in a cell is coded on a certain number of bits which determine the colour or the intensity of the pixel, This is called the coding depth (or is sometimes also called the colour depth). There are several coding depth standards: Black and white bitmap: by storing one bit in each cell, it is possible to define two colours (black or white). Bitmap with 16 colours or 16 levels of grey: storing 4 bits in each cell, it is possible to define 24 intensities for each pixel, that is, 16 degrees of grey ranging from black to white or 16 different colours. Bitmap with 256 colours or 256 levels of grey: by storing a byte in each cell, it is possible to define 24 intensities, that is, 256 degrees of grey ranging from black to white or 256 different colours. Colour palette colourmap): thanks to this method it is possible to define a pallet, or colour table, with all the colours that can be contained in the image, for each of which there is an associated index. The number of bits reserved for the coding of each index of the palette determines the number of colours which can be used. Thus, by coding the indexes on 8 bits it is possible to define 256 usable colours; that is, each cell of the two-dimensional table that represents the image will contain a number indicating the index of the colour to be used. An image whose colours are coded according to this technique is thus called an indexed colour image. "True Colours" or "real colours": this representation allows an image to be represented by defining each component (RGB, for red, green and blue). Each pixel is represented by a set comprising the three components, each one coded on a byte, that is, on the whole 24 bits (16 million colours). It is possible to add a fourth component, making it possible to add information regarding transparency or texture; each pixel is then coded on 32 bits.

HARVINDER SINGH

511025273

30


2. D ESCRIBE THE FOLLOWING WITH RESPECT TO METHODS OF GENERATING CHARACTERS :A) Stroke method This method uses small line segments to generate a character. The small series of line segments are drawn like a stroke of pen to form a character as shown in the figure below.

Stroke method We can build our own stroke method character generator by calls to the line drawing algorithm. Here it is necessary to decide which line segments are needed for each character and then drawing these segments using line drawing algorithm. B) Starbust method In this method a fix pattern of line segments are used to generate characters. As shown in the fig. 5.20, there are 24 line segments. Out of these 24 line segments, segments required to display for particular character are highlighted. This method of character generation is called starbust method because of its characteristic appearance

HARVINDER SINGH

511025273

31


2. D ESCRIBE THE FOLLOWING WITH RESPECT TO METHODS OF GENERATING CHARACTERS: (CONTD)Figure shows the starbust patterns for characters A and M. the patterns for particular characters are stored in the form of 24 bit code, each bit representing one line segment. The bit is set to one to highlight the line segment; otherwise it is set to zero. For example, 24-bit code for Character A is 0011 0000 0011 1100 1110 0001 and for character M is 0000 0011 0000 1100 1111 0011. This method of character generation has some disadvantages. They are 1. 2. 3. The 24-bits are required to represent a character. Hence more memory is required Requires code conversion software to display character from its 24-bit code Character quality is poor. It is worst for curve shaped characters.

C) Bitmap method The third method for character generation is the bitmap method. It is also called dot matrix because in this method characters are represented by an array of dots in the matrix form. It is a two dimensional array having columns and rows. An 5 x 7 array is commonly used to represent characters as shown in the below figure. However 7 x 9 and 9 x 13 arrays are also used. Higher resolution devices such as inkjet printer or laser printer may use character arrays that are over 100x100.

Character A in 5 x 7 dot matrix format Each dot in the matrix is a pixel. The character is placed on the screen by copying pixel values from the character array into some portion of the screens frame buffer. The value of the pixel controls the intensity of the pixel.HARVINDER SINGH 511025273

32


3. D ISCUSS THE HOMOGENEOUS COORDINATES FOR TRANSLATION , ROTATION ANDSCALINGFor translation: The third 2D graphics transformation we consider is that of translating a 2D line drawing by an amount Tx along the x axis and Ty along the y axis. The translation equations may be written as: (5) We wish to write the Equations 5 as a single matrix equation. This requires that we find a 2 by 2 matrix,

Such that x x a + y x c = x + Tx From this it is clear that a=1 and c=0, but there is no way to obtain the Tx term required in the first equation of Equations 5. Similarly we must have x x b + y x d = y + Ty. Therefore, b=0 and d=1, and there is no way to obtain the Ty term required in the second equation of Equations 5. For Rotation: Suppose we wish to rotate a figure around the origin of our 2D coordinate system. Below figure shows the point x,y being rotated degrees (by convention, counter clock-wise direction is positive) about the origin.

Rotating a Point About the OriginHARVINDER SINGH 511025273

33


3. D ISCUSS THE HOMOGENEOUS COORDINATES FOR TRANSLATION , ROTATION ANDSCALING (CONTD)The equations for changes in the x and y coordinates are:

(1) If we consider the coordinates of the point (x,y) as a one row two column matrix [ x y ] and the matrix x,y)

Then, given the J definition for matrix product, mp =: +/ . *, we can write Equations (1) as the matrix equation (2) We can define a J monad, rotate, which produces the rotation matrix. This monad is applied to an angle, expressed in degrees. Positive angles are measured in a counter-clockwise direction by convention. rotate =: monad def '2 2 $ 1 1 _1 1 * 2 1 1 2 o. (o. y.) % 180' rotate 90 01 _1 0 rotate 360 `1 _2.44921e_16 2.44921e_16 1

We can rotate the square of Figure 1 by:

HARVINDER SINGH

511025273

34


3. D ISCUSS THE HOMOGENEOUS COORDINATES FOR TRANSLATION , ROTATION ANDSCALING (CONTD)square mp rotate 90 0 0 0 10 _10 10 _10 0 0 0 producing the rectangle shown in below figure. The Square, Rotated 90 Degrees

For Scaling: Next we consider the problem of scaling (changing the size of) a 2D line drawing. Size changes are always made from the origin of the coordinate system. The equations for changes in x the y and coordinates are: (3) As before, we consider the coordinates of the point (x,y as a one row two column matrix [ x y ] and the matrix x,y) x,y

then, we can write Equations (3) as the matrix equation (4) We next define a J monad, scale, which produces the scale matrix. This monad is applied to a list of two scale factors for x and y respectively. scale =: monad def '2 2 $ (0 { y.),0,0,(1 { y.)' scale 2 3HARVINDER SINGH 511025273

35


3. D ISCUSS THE HOMOGENEOUS COORDINATES FOR TRANSLATION , ROTATION ANDSCALING (CONTD)20 03 We can now scale the square of Figure 1 by: square mp scale 2 3 0 0 20 0 20 30 0 30 0 0 producing the square shown in below figure.

Scaling a SquareHARVINDER SINGH 511025273

36


4. D ESCRIBE THE FOLLOWING WITH RESPECT TO P ROJECTION :A) Parallel Projection In parallel projection, z coordinate is discarded and parallel lined from each vertex on the object are extended until they intersect the view plane. The point of intersection is the projection of the vertex. We connect the projected vertices by line segments which correspond to connections on the original object.

Parallel projection of an object to the view plane As shown in the Figure above, a parallel projection preserves relative proportions of objects but does not produce the realistic views. B) Perspective Projection The perspective projection, on the other hand, produces realistic views but does not preserve relative proportions. In perspective projection, the lines of projection are not parallel. Instead, they all coverage at a single point called the center of projection or projection reference point. The object positions are transformed to the view plane along these converged projection lines and the projected view of an object is determines by calculating the intersection of the converged projection lines with the view plane, as shown in the shown figure.

Perspective projection of an object to the view planeHARVINDER SINGH 511025273

37


4. D ESCRIBE THE FOLLOWING WITH RESPECT TO P ROJECTION :C) Types of Parallel Projections

(CONTD)

Parallel projections are basically categorized into two types, depending on the relation between the direction of projection and the normal to the view plane. When the direction of the projection is normal (perpendicular) to the view plane, we have an orthographic parallel projection. Otherwise, we have an oblique parallel projection. Figure above illustrates the two types of parallel projection.

Orthographic Projection The orthographic projection can display more than one face of an object. Such as orthographic projection is called axonometric orthographic projection. It uses projection planes (view planes) that are not normal to a principle axis. They resemble the perspective projection in this way, but differ in that the foreshortening is uniform rather than being related to the distance from the center of projection. Parallelism of lines is preserved but angles are not. The most commonly used axonometric orthographic projection is the isometric projection. The isometric projection can be generated by aligning the view plane so that it intersects each coordinate axis in which the object is defined at the same distance from the origin. As shown in the shown figure, the isometric projection is obtained by aligning the projection vector with the cube diagonal. It uses an useful property that all three principle axes are equally foreshortened, allowing measurements along the axes to be made to the same scale (hence the name: iso for equal, metric for measure).

Isometric projection of an object onto a viewing planeHARVINDER SINGH 511025273

38


4. D ESCRIBE THE FOLLOWING WITH RESPECT TO P ROJECTION :Oblique Projection

(CONTD)

An oblique projection is obtained by projecting points along parallel lines that are not perpendicular to the projection plane. Notice that the view plane normal and the direction of projection are not the same. The oblique projections are further classified as the cavalier and cabinet projections. For the cavalier projection, the direction of projection makes a 450 angle with the view plane. As a result, the projection of a line perpendicular to the view plane has the same length as the line itself; that is, there is no foreshortening. Cavalier Projections of the unit cube When the direction of projection makes an angle of arctan (2)=63.40 with the view plane, the resulting view is called a cabinet projection. For this angle, lines perpendicular to the viewing surface are projected at one-half their actual length. Cabinet projections appear more realistic than cavalier projections because of this reduction in the length of perpendiculars. Figure below shows the examples of cabinet projections for a cube.

1 1/2 1/2

1

1 45 (a)

1 = 30 (b)

Cabinet projec

mca 3rd semester assignment

Documents