Friday, May 25, 2012

What is an Operating System? (Extended Machine and Resource Manager)

WHAT IS AN OPERATING SYSTEM?
I think its hard to pin down what an operating system is other than saying it is the software that runs in kernel mode and even that is not always true. Basically operating systems perform two unrelated functions: providing application programmers a clean abstract set of resources instead of the messy hardware ones and managing these hardware resources.

Therefore, OPERATING SYSTEM = EXTENDED MACHINE + RESOURCE MANAGER

Depending on who is doing the talking, you might hear mostly about one function or the other.

But here we will now look at both.

First case: Extended Machine
The architecture (instruction set, memory organization, I/O, and bus structure) of most computers at the machine language level is primitive and awkward to program, especially for input/output. To make this point more concrete, consider how floppy disk I/O is done using the NEC PD765 compatible controller chips used on most Intel-based personal computers. We use the floppy disk as an example, because, although it is obsolete, it is much simpler than a modem hard disk.

[ The PD765 has 16 commands, each specified by loading between 1 and 9 bytes into a device register. These commands are for reading and writing data, moving the disk arm, and formatting tracks, as well as initializing, sensing, resetting, and recalibrating the controller and the drives. The most basic commands are read and write, each of which requires 13 parameters, packed into 9 bytes. These parameters specify such items as the address of the disk block to be read, the number of sectors per track, the recording mode used on the physical medium, the intersector gap spacing, and what to do with a deleted-data-address-mark. When the operation is completed, the controller chip returns 23 status and error fields packed into 7 bytes. As if this were not enough, the floppy disk programmer must also be constantly aware of whether the motor is on or off. If the motor is off, it must be turned on (with a long startup delay) before data can be read or written. The motor cannot be left on too long, however, or the floppy disk will wear out.]
If you do not understand this mumbo jumbo, do not worry; that is precisely the point-it is rather esoteric. The programmer is thus forced to deal with the trade-off between long startup delays versus wearing out floppy disks (and losing the data on them). Without going into the real details, it should be clear that the average programmer probably does not want to get too intimately involved with the programming of floppy disks (or hard disks, which are worse). Instead, what the programmer wants is a simple, high-level abstraction to deal with.
In the case of disks, a typical abstraction would be that the disk contains a collection of named files. Each file can be opened for reading or writing, then read or written, and finally closed. Details such as whether or not recording should use modified frequency modulation and what the current state of the motor is should not appear in the abstraction presented to the application programmer.

Abstraction is the key to managing complexity. Good abstractions turn a nearly impossible task into two manageable ones. The first one of these is defining and implementing the abstractions. The second one is using these abstractions to solve the problem at hand.
One abstraction that almost every computer user understands is the file. It is a useful piece of information, such as a digital photo, saved e-mail message, or Web page. Dealing with photos, e-mails, and Web pages is easier than the details of disks, such as the floppy disk described above. The job of the operating system is to create good abstractions and then implement and manage the abstract objects thus created. Abstractions are one of the keys to understanding operating systems. This point is so important that it is worth repeating in different words. Real processors, memories, disks, and other devices are very complicated and present difficult, awkward, idiosyncratic, and inconsistent interfaces to the people who have to write software to use them. Sometimes this is due to the need for backward compatibility with older hardware, sometimes due to a desire to save money, but sometimes the hardware designers do not realize (or care) how much trouble they are causing for the software. One of the major tasks of the operating system is to hide the hardware and present programs with nice, clean, elegant, consistent, abstractions to work with instead.

Operating systems turn the ugly into the beautiful using abstraction concept.

It should be noted that the operating system's real customers are the application programs (via the application programmers, of course). They are the ones who deal directly with the operating system and its abstractions. In contrast, end users deal with the abstractions provided by the user interface, either a commandline shell or a graphical interface. While the abstractions at the user interface may be similar to the ones provided by the operating system, this is not always the case. To make this point clearer, consider the normal Windows desktop and the line-oriented command prompt. Both are programs running on the Windows operating system and use the abstractions Windows provides, but they offer very different user interfaces. Similarly, a Linux user running Gnome or KDE sees a very different interface than a Linux user working directly on top of the underlying (text-oriented) X Window System, but the underlying operating system abstractions are the same in both cases.That is a large and important subject, but one only peripherally related to operating systems.

Second case: Resource Manager
Modern computers consist of processors, memories, timers, disks, mice, network interfaces, printers, and a wide variety of other devices. The concept of an operating system as primarily providing abstractions to application programs is a top-down view. An alternative, bottom-up, view holds that the operating system is there to manage all the pieces of a complex system. In the alternative view, the job of the operating system is to provide for an orderly and controlled allocation of the processors, memories, and I/0 devices among the various programs competing for them.

Modem operating systems allow multiple programs to run at the same time. Imagine what would happen if three programs running on some computer all tried to print their output simultaneously on the same printer. The first few lines of printout might be from program 1, the next few from program 2, then some from program 3, and so forth. The result would be chaos. The operating system can bring order to the potential chaos by buffering all the output destined for the printer on the disk. When one program is finished, the operating system can then copy its output from the disk file where it has been stored for the printer, while at the same time the other program can continue generating more output, oblivious to the fact that the output is not really going to the printer (yet). When a computer (or network) has multiple users, the need for managing and protecting the memory, 110 devices, and other resources is even greater, since the users might otherwise interfere with one another. In addition, users often need to share not only hardware, but information (files, databases, etc.) as well.

In short, this view of the operating system holds that its primary task is to keep track of which programs are using which resource, to grant resource requests, to account for usage, and to mediate conflicting requests from different programs and users.

Resource management includes multiplexing (sharing) resources in two different ways: in time and in space. When a resource is time multiplexed, different programs or users take turns using it. First one of them gets to use the resource, then another, and so on. For example, with only one CPU and multiple programs that want to run on it, the operating system first allocates the CPU to one program, then, after it has run long enough, another one gets to use the CPU, then another, and then eventually the first one again. Determining how the resource is time multiplexed- who goes next and for how long-is the task of the operating system. Another example of time multiplexing is sharing the printer. When multiple print jobs are queued up for printing on a single printer, a decision has to be made about which one is to be printed next.

Tuesday, May 8, 2012

What design choices have to be made when integrating COTS products to create a COTS-solution system?


What design choices have to be made when integrating COTS products to create a COTS-solution system?
Ans: To develop systems using COTS products, you have to make a number of design choices:
1. Which COTS products offer the most appropriate functionality? Typically, there will be several COTS products available, which can be combined in different ways. If you don’t already have experience with a COTS product, it can be difficult to decide which product is the most suitable.
2. How will data be exchanged? Different products normally use unique data structures and formats. You have to write adaptors that convert from one representation to another. These adaptors are run-time systems that operate alongside the COTS products.
3. What features of a product will actually be used? COTS products may include more functionality than you need and functionality may be duplicated across different products. You have to decide which features in what product are most appropriate for your requirements. If possible, you should also deny access to unused functionality because this can interfere with normal system operation. The failure of the first flight of the Ariane 5 rocket was a consequence of a failure in an inertial navigation system that was reused from the Ariane 4 system. However, the functionality that failed was not actually
required in Ariane 5.

What is an ERP system?


What is an ERP system?
Ans: At a larger scale, an Enterprise Resource Planning (ERP) system may support all of the manufacturing, ordering, and customer relationship management activities in a large company.
ERP systems, such as those produced by SAP and BEA, are large-scale integrated systems designed to support business practices such as ordering and invoicing, inventory management, and manufacturing scheduling. The configuration process for these systems involves gathering detailed information about the customer’s business and business processes, and embedding this in a configuration database. This often requires detailed knowledge of configuration notations and tools and is usually carried out by consultants working alongside system customers. ERP systems are used in almost all large companies to support some or all of their functions. They are, therefore, a very widely used form of software reuse.

What are the main benefits of COTS reuse?


What are the main benefits of COTS reuse?
Ans: The main benefits of COTS reuse are:
1. As with other types of reuse, more rapid deployment of a reliable system may be possible.
2. It is possible to see what functionality is provided by the applications and so it is easier to judge whether or not they are likely to be suitable. Other companies may already use the applications so experience of the systems is available.
3. Some development risks are avoided by using existing software. However, this approach has its own risks, as I discuss below.
4. Businesses can focus on their core activity without having to devote a lot of resources to IT systems development.
            5. As operating platforms evolve, technology updates may be simplified as these are the responsibility of the COTS product vendor rather than the customer.

What are the process steps involved in creating a new member of a software product line?


What are the process steps involved in creating a new member of a software product line?
Ans: The process steps involved in extending a software product line to create a new application are as follows:
1. Elicit stakeholder requirements: You may start with a normal requirements engineering process. However, because a system already exists, you will need to demonstrate the system and have stakeholders experiment with it, expressing their requirements as modifications to the functions provided.
2. Select the existing system that is the closest fit to the requirements: When creating a new member of a product line, you may start with the nearest product instance. The requirements are analyzed and the family member that is the closest fit is chosen for modification.
3. Renegotiate requirements: As more details of required changes emerge and the project is planned, there may be some requirements renegotiation to minimize the changes that are needed.
4. Adapt existing system: New modules are developed for the existing system and existing system modules are adapted to meet the new requirements.
            5. Deliver new family member: The new instance of the product line is delivered to the customer. At this stage, you should document its key features so that it may be used as a basis for other system developments in the future.

List 4 types of specialization of software product lines?


List 4 types of specialization of software product lines?
Ans: Various types of specialization of a software product line may be developed:
1. Platform specialization: Versions of the application are developed for different platforms. For example, versions of the application may exist for Windows, Mac OS, and Linux platforms. In this case, the functionality of the application is normally unchanged; only those components that interface with the hardware and operating system are modified.
2. Environment specialization: Versions of the application are created to handle particular operating environments and peripheral devices. For example, a system for the emergency services may exist in different versions, depending on the vehicle communications system. In this case, the system components are changed to reflect the functionality of the communications equipment used.
3. Functional specialization: Versions of the application are created for specific customers who have different requirements. For example, a library automation system may be modified depending on whether it is used in a public library, a reference library, or a university library. In this case, components that implement functionality may be modified and new components added to the system.
4. Process specialization: The system is adapted to cope with specific business processes. For example, an ordering system may be adapted to cope with a centralized ordering process in one company and a distributed process in another.

What features are supported by most web application frameworks?


What features are supported by most web application frameworks?
Ans: Most web application frameworks support the following features:
1. Security WAFs may include classes to help implement user authentication (login) and access control to ensure that users can only access permitted functionality in the system.
2. Dynamic web pages Classes are provided to help you define web page templates and to populate these dynamically with specific data from the system database.
3. Database support Frameworks don’t usually include a database but rather assume that a separate database, such as MySQL, will be used. The framework may provide classes that provide an abstract interface to different databases.
4. Session management Classes to create and manage sessions (a number of interactions with the system by a user) are usually part of a WAF.
5. User interaction Most web frameworks now provide AJAX support, which allows more interactive web pages to be created.

What are the three classes of application framework discussed by Fayed and Schmidt?


What are the three classes of application framework discussed by Fayed and Schmidt?
Ans: Fayad and Schmidt discuss three classes of frameworks:
1. System infrastructure frameworks: These frameworks support the development of system infrastructures such as communications, user interfaces, and compilers.
2. Middleware integration frameworks: These consist of a set of standards and associated object classes that support component communication and information exchange. Examples of this type of framework include Microsoft’s .NET and Enterprise Java Beans (EJB). These frameworks provide support for standardized component models, as discussed in Chapter 17.
3. Enterprise application frameworks: These are concerned with specific application domains such as telecommunications or financial systems. These embed application domain knowledge and support the development of end-user applications.

What key factors should be considered when considering the most appropriate type of reuse?


What key factors should be considered when considering the most appropriate type of reuse?
Ans: Key factors that you should consider when planning reuse are:
1. The development schedule for the software: If the software has to be developed quickly, you should try to reuse off-the-shelf systems rather than individual components. These are large-grain reusable assets. Although the fit to requirements may be imperfect, this approach minimizes the amount of development required.
2. The expected software lifetime: If you are developing a long-lifetime system, you should focus on the maintainability of the system. You should not just think about the immediate benefits of reuse but also of the long-term implications. Over its lifetime, you will have to adapt the system to new requirements, which will mean making changes to parts of the system. If you do not have access to the source code, you may prefer to avoid off-the-shelf components and systems from external suppliers; suppliers may not be able to continue support for the reused software.
3. The background, skills, and experience of the development team: All reuse technologies are fairly complex and you need quite a lot of time to understand and use them effectively. Therefore, if the development team has skills in a particular area, this is probably where you should focus.
4. The criticality of the software and its non-functional requirements: For a critical system that has to be certified by an external regulator, you may have to create a dependability case for the system. This is difficult if you don’t have access to the source code of the software. If your software has stringent performance requirements, it may be impossible to use strategies such as generator-based reuse, where you generate the code from a reusable domain specific representation of a system. These systems often generate relatively inefficient code.
5. The application domain: In some application domains, such as manufacturing and medical information systems, there are several generic products that may be reused by configuring them to a local situation. If you are working in such a domain, you should always consider these as an option.
6. The platform on which the system will run: Some components models, such as .NET, are specific to Microsoft platforms. Similarly, generic application systems may be platform-specific and you may only be able to reuse these if your system is designed for the same platform.

What are the main problems with software reuse?


What are the main problems with software reuse?
Ans:     Increased maintenance costs: If the source code of a reused software system or component is not available, then maintenance costs may be higher because the reused elements of the system may become increasingly incompatible with system changes.
Lack of tool support: Some software tools do not support development with reuse. It may be difficult or impossible to integrate these tools with a component library system. The software process assumed by these tools may not take reuse into account. This is particularly true for tools that support embedded systems engineering, less so for object-oriented development tools.
Not-invented-here syndrome: Some software engineers prefer to rewrite components because they believe they can improve on them. This is partly to do with trust and partly to do with the fact that writing original software is seen as more challenging than reusing other people’s software.
Creating, maintaining, and using a component library: Populating a reusable component library and ensuring the software developers can use this library can be expensive. Development processes have to be adapted to ensure that the library is used.
Finding, understanding, and adapting reusable components: Software components have to be discovered in a library, understood and, sometimes, adapted to work in a new environment. Engineers must be reasonably confident of finding a component in the library before they include a component search as part of their normal development process.

List the main benefits of software reuse.


List the main benefits of software reuse.
Ans:     Increased dependability: Reused software, which has been tried and tested in working systems, should be more dependable than new software. Its design and implementation faults should have been found and fixed.
Reduced process risk: The cost of existing software is already known, whereas the costs of development are always a matter of judgment. This is an important factor for project management because it reduces the margin of error in project cost estimation. This is particularly true when relatively large software components such as subsystems are reused.
Effective use of specialists: Instead of doing the same work over and over again, application specialists can develop reusable software that encapsulates their knowledge.
Standards compliance: Some standards, such as user interface standards, can be implemented as a set of reusable components. For example, if menus in a user interface are implemented using reusable components, all applications present the same menu formats to users. The use of standard user interfaces improves dependability because users make fewer mistakes when presented with a familiar interface.
Accelerated development: Bringing a system to market as early as possible is often more important than overall development costs. Reusing software can speed up system.