Simple Segmentation

Segmentation, like paging, divides a program into a number of smaller blocks called segments, each of which is allocated to memory independently. Unlike paging, segments are variable-size. Responsibility for dividing the program into segments lies with the user (or compiler) the operating system is uninvolved. The hardware sets an upper limit on the size of any segment.

A segment table is very similar to a page table. However, since segments are variable –size, memory cannot be predivided into anything like a page frame. The operating system must maintain a free list and allocate segments to memory holes. The issues of how the allocation is performed are the same as those found in the variable partition scheme.

A segment table entry must have fields for storing the segments starting address in main memory and the size of the segment. If the maximum segment size in m bits, the last m bits of the logical address specify the segment offset. The remaining bits specify the segment number. The logical address is translated into a physical address by extracting the segment number and offset from the logical address. The segment number is used as an index into the segment table. The offset is compared to the segment size. If the offset is greater than the segment size, an invalid-address fault is generates, causing the program to be aborted. Otherwise, the offset is added to the segment’s starting address to generate the physical address. To increase speed, the size check and the physical address generation can be performed concurrently.

Because segments are user defined, it is possible to define certain segments to be read-only. By adding a read-only bit into a segment table entry, the memory management system can check for write operations to read-only segments and generate a fault if such an operation is detected.

If support for read-only segments is present, it may also be possible for multiple processes to share read-only segments, thereby decreasing memory usage. Typically, this occurs when two processes are executing the same program and the code for that program is designated o be in one or more read-only segments.

Shared segments may also be used by processes executing different programs but using the same subroutine library. In this situation, care must be taken that addresses within this shared segment will work with both programs. For addresses to locations within the segments the simplest solution is to use relative addressing.

Relative addressing uses the offset from the current value of the program counter to generate the destination address. For all addresses, indirect addressing though a register pointing to the appropriate segment is also a possibility. Direct addressing, which specifies the segment and offset of the destination address, is possible only if all programs use the same segment number for the segment being access.

Advantages:

·       Eliminates fragmentation

·       Provides large virtual memory

·       Allows dynamic segment growth

·       Assists dynamic linking

·       Facilitates shared segments

·       Enforces controlled access.

Disadvantages:

·       Considerable compaction overhead is incurred in order to support dynamic segment growth and eliminate fragmentation.

·       There is difficulty in managing variable size segments on secondary storage.

·       The maximum size of a segment is limited by the size of the main memory.

·       It is necessary to develop techniques or constraints to prevent segment thrashing.

Concepts Of Deadlocks

Deadlock can be defined formally as follows:

A deadlock is a situation where a group of processes are permanently blocked as a result of each process having acquired a subset of the resources needed for its completion and waiting for release of remaining resources held by others.

Because all the processes are waiting, none of them will ever cause any of the event that could wake up any of the other members of the set and all the processes continue to wait forever. For this model, we assume that processes have only a single thread and that there are no interrupts possible to wake up a blocked process. The no-interrupt condition is needed to prevent an otherwise deadlocked process from being awakened by say, an alarm, and then causing events that release other processes in the set.

In most cases, the event that each process is waiting for is the release of some resource currently possessed by another member of the set. In other words, each number of the set of deadlocked processes is ‘waiting for a resource that is owned by deadlocked process. None of the processes, can run, none of them can release by resources and none of them can be awakened. The number of processes and the number and kind of resources possessed and requested are unimportant. This result holds for any kind of resource, including both hardware and software.

Deadlock characterization: In a deadlock processes never finish executing and system resources are tied up preventing other jobs from starting. Formally, a deadlock occurs when the following four conditions are present simultaneously.

Coffman et al. (1971) showed form necessary conditions must for a deadlock.

1.    Mutual exclusion: Each resource can be assigned to at most one process only that is non-sharable. If some other processes asks for the same resource then it has to wait until that resource has been released i.e. At least one resource (thread) must be held in a non-sharable mode, that is, only one process at a time claims exclusive control of the resource. If another process requests that resource, the requesting process must be delayed until the resource has been released.

2.    Hold and wait: Processes hold a resource and may seek an additional resource that is already held by some other process i.e. there must exist a process that is holding a resource already allocated to it while waiting for additional resource that are currently being held by other processes.

3.    No pre-emption: Processes that have been given a resource cannot be preempted to release their resources i.e. only voluntary release of resources is possible that too after the completion of the task . Resources cannot be removed from the processes are used to completion or released voluntarily by the process holding it.

4.    Circular wait: Every process awaits release of at least one resource held by some other processes. Here the deadlocked processes are involved in circular wait chain such that each process hold one or more resources being requested by the next process in the chain.

   

Major Problems and their Solutions in System Development

In the system development, software is a part of the system i.e. the software is one of the component of the system and this component can be further classified into its subcomponents like software development phases or software’s domains. As such, software is the major part of the system. The success or the unsuccess of the system are also related to the success or the unsuccess of the software

.

The major plan factors of the software like risk, schedule, quality, configuration management may lead to many problems to the software which further become the problems of the system. Now we will discuss the major problems and their solutions into the system development.

Problem 1. Schedule of the System Development

This problem is related to the total development time (schedule) of a large system. Time is a measure which puts the constraints on the development. The task, which is given to be completed within time, must be finished within the time. But two problems may occur regarding this time constraint:

a)      If the development team takes much time to develop the system (for an example two years), then it is quite possible that the technology (computer, hardware, software, operating system) may change and the better technologies may come into the market with good features and attributes, within the time duration of when the system concept is initialized and the time it is ready for release to the customer. This period of time is so much and during this period so many changes may take place

.

b)      Sometimes, during the system development time period, the system requirements may change, so the objective for which system was made no longer exists.

Solution

These time period problems of system development can be solved as:

a)      First problem can be removed or reduced by postponing the technology decisions for as long as possible until that technology is required to complete the task for shortening the system development time. But as we know, that it is quite not possible to delay the technology decisions because from the beginning only they are like the backbone.

   Another solution is that, the reusable codes can be used that reduces the system development time but that reusable codes should fulfill all requirements for which we are using them and should not modify much the already built components of new system.

b)      To solve the problem, the solution is either the system development time duration should be small enough so that the system development must be completed within its time limits and there is no chance to change any requirement or at the beginning stage, when there is a communication between the developer and the customer, all the requirements (of any type) should be clearly mentioned at that time only. If any software or system development model is required it can be used.

Problem 2. System User Interface ( or Man-Machine Interface)

User interface means how the users and the operators of the system can use this system i.e. how user can interact with the system. As such, at the initial stage of the system development, this aspect should be considered fully. But generally, the complete attention is not given on this system- user interface concept during the initial system design phase. And later on, when most of the part of the system has been developed, we come to know that we have to add some more new displays, controls etc. to make the difficult system-user interface. Then, it is required to add some more hardwares, softwares, procedures etc. At this stage, it is very difficult to add them in this already, partial built system.

Solution: Generally, it is very essential to consider all the important and non-important points at the initial developer-customer communication stage. When the requirements specification is made, the requirements of the system-user interface should also be considered. The proper concentration is needed to emphasize this concept because at last the persons who will use this system are the operators, customers or users only and they require the efficient system interface.

That’s why, this concept should be discussed and initially concentrated.

Component of the SRS

The basic issues , an SRS must address are :

1.      Functional Requirements

2.      Performance Requirements

3.      Design Constraints

4.      External Interface Requirements

Conceptually, any SRS should have these components. Now , we will them one by one .

1.Functional Requirements

Functional requirements specify what output should be produced from the given inputs . So, they basically describe the connectivity between the input and output of the system. For each functional requirement :

·         A detailed description of all the data inputs and their sources, the units of measure , and the range of valid inputs must be specified:

·         All the operations to be performed on the input data to obtain the  output should be specified , and,

·         Care must be taken not to specify any algorithms that are not parts of the system but that may be needed to implement the system.

·         It must clearly state what the system should do if systems behaves abnormally when any invalid input is given or due to some error during computation. Specifically when any invalid input is given or due to some error during computation specifically, it should specify the behaviour of the system for invalid inputs and invalid outputs.

2. Performance Requirements ( Speed Requirements )   

This part of SRS specifies the performance constraints on the software system. All the requirements related to the performance characteristics of the system must be clearly specified. Performance requirements are typically expressed as “ Processed Transactions per Second “ or “Response Time from the System for a User Event” or “ Screen Refresh Time “ or a combination of these . It is a good idea to pin down performance requirements for the most used or critical transactions, user events and screens.

3. Design Constraints

The client’s environment may restrict the designer to include some design constraints that must be followed. The various design constraints are standard , compliance , resource limits, operating environment, reliability and security requirements and policies that may have an impact on the design of the system. An SRS should identify and specify all such constraints.

Standard Compliance : It specifies the requirements for the standard , the system must follow. The standards may include the report format and accounting procedures.

Hardware Limitations : The software needs some existing or predetermined hardware to operate , thus imposing restrictions on the design. Hardware limitations can include the types of machines to be used , operating system availability , memory space etc.

Fault Tolerance : Fault tolerance requirements can place a major constraints on how the system is to be designed. Fault tolerance requirements often make the system more complex and expensive , so they should be minimized.

Security :  Currently security requirements have become essential and major for all types of system. Security requirements place restriction on the use of certain commands, control access to database , provide different kinds of access, requirements for different people , require the use of passwords and cryptography techniques , and maintain a log of activities in the system.

4.  External Interface Requirements  

For each external requirements :

·         All the possible interactions of the software with people , hardware , and other software should be clearly specified.

·         The characteristics of each user interface of the software product should be specified, and,

·         The SRS should specify the logical characteristics of each interface between the software product and the hardware components for hardware interfacing.

Software requirements may be specified in a variety of ways .A simple set of guidelines are as follows:

·         Representation format and content should be relevant to the problems. A general outline for the contents of a software requirements specifications can be developed and its format and contents should be like that it should be made to follow the problem exactly.

·         Information contained within the specification should be nested. Representations can have layers of information’s so that a reader can move to the level of  detail that is required . Paragraph and diagram numbering schemes should indicate the level of detail that is being presented.

·         Diagrams and other notational forms should be restricted in number and consistent in use.

So much diagrams and less theory decreases the quality . Confusing or inconsistent notation, whether graphical or symbolic , degrades understanding and lead to errors.

Representations should revisable : The content of a specification will change . Identically, CASe tools should be available to update all representations that are affected by each change.

Characteristics of the SRS

To properly satisfy the basic goals , an SRS should have certain properties and should contain different types of requirement. A “good” SRS document should have the following characteristics

1 .Completeness: A SRS is complete if everything the software is supposed to do and the responses of the software to all classes of input data are specified in SRS. It ensures that everything is indeed specified. It is ont of the most difficult property to spot. To ensure completeness, one has too detect the absence of specifications, which are much harder to determine.

2. Clarity: the documented requirements should lead to only a single interpretation, independent of the person or the time when the interpretation is done. The SRS needs to be unambiguous to the authors, the users, other reviewers as well as the developers and testers who will use the document. So SRS writer should be careful about ambiguity. One way to avoid ambiguity is to use some formal requirements specification language, but it is the major drawback. The formal languages require more effort to write SRS, more cost and the increased difficulty in reading and understanding formally stated requirements.

3. Correctness: The SRS can be considered as correct if every requirement stated in the SR is required in the proposed system. Correctness of an SRS:

·       ensures that what is specified is done correctly.

·       is an easier property to establish as it basically involves examining each requirement to make sure that it represents the user requirements.

There are no real tools or procedures that ensure correctness. If there are any preceding documents then the requirements from those earlier documents need to be traced to the SRS.

4. Consistency: Requirements at all levels must be consistent with each other . any conflict between requirements within the SRs must be identified and resolved. The types of conflicts that generally occur are:

·       Characteristics (format, details) of real-word entity interfacing with the system may be conflicting. For an example, one requirement states that an individual can work up to 6 hours, whereas another requirement state it as 8 hours.

·       The terminology used for some entities/events may be different, for example, different requirements may use different terms to refer to the same object.

There may be logical or temporal conflict between requirements causing inconsistencies. For example, suppose a requirement states that an event a is to occur before another event b. but another set of requirements states that event b should occur before event A directly or indirectly by transitivity.

5. Verifiability: A SRS is verifiable if and only if every stated requirement is verifiable. A requirement is verifiable if there exists some cost- effective process that can check whether the final software meets that requirements. Unambiguity is essential for verifiability. As verification of requirements is often done through reviews, it also implies that SRS is understandable, at least be the developer, the client and the users.

6. Ranking: generally, the requirements are stated according to their priorities. Some are critical, others are important but not critical and there are some which are desirable but not very important. Similarly, some requirements are ‘core’ requirements which are not likely to change as time passes, while others are more dependent on time. A SRS is ranked for importance and stability it for each requirement the importance and the stability of the requirement are indicated.

7. Modification: the SRS needs to be documented in such a manner that a history of changes can be contained on the document. It will also necessary to be able to highlight and trace the changes of the requirements as we progress through the project. Certain good practices that can lead to high modification are – minimal redundancy and the numbering ( labeling0 of the requirements. According to IEEE standard 830-1993 ( Recommended practice for the Software Requirements Specification ), a SRS is modifiable if “its structure and style are such that any necessary changes to the requirements can be made easily while preserving completeness and consistency while retaining its structure and style”.

8. Traceability : An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development. There are two types of traceability.

•      Backward traceability to the documentation/ and other work-products created prior to the requirements phase. This  will depend upon how well referencing and labeling has been provided in the previous documents/work-products,

• Forward traceability will depend upon the how each requirement in the SRS is labeled/numbered. This traceability is extremely important, as this is one of the ways of tracing a requirement to its implementation. Traceability aids verification and validation.

9.Feasibility: Though it any not be possible to confirm the 

feasibility of implementation of all the requirements , any requirement which is apparent infeasible , should be eliminated from the SRS.    

  

  

                                                                                          

Level of SRS

The level of SRS is about the need to restrict the specification as much as possible to specify what the system should do rather than how it should do. As we have seen, the specification should ideally be the user’s view of the system rather than say anything about how the system is to be implemented. This relationship between the specification and the implementation is often explained in terms of the what versus how. The specification states what a system should do; the implementation decides how to do it. In practice, however, the distinction between the two is not often so sharp. For instance, in some cases, the decision as to whether to distribute a banking system throughout the bank’s branches or to keep it centralized in the main branch and use remote terminals at the other branches can be considered a design matter; i.e. a how matter. So, one can claim that physical distribution of system is not a requirement, but an implementation issue.

Software Requirements Specification (SRS)

Software requirements specification is essential as this is the only lasting impression of the requirements elicitation and analysis process that is available to the development team, the users and the customer as the system progresses to the later parts of the software development life cycle. The software requirements specification usually called the Software Requirement Document forms the basis for development as well as testing activities. A one line definition of SRS is given as:

“SRS is a vital piece of documentation that is crucial to the success of any software development project.”

If one cannot precisely state what the system should do, how can we develop the software with any confidence and how can we hope to check that the end-product meets it needs? The specification is the reference document against which all subsequent development is assessed.