Unit - 4

Software requirement engineering

Q1. Define Engineering process and explain its 4 main activities in detail?

A 1)

1. Requirement Engineering is the process of defining, documenting and maintaining the requirements. It is a process of gathering and defining service provided by the system. Requirements Engineering Process consists of the following main activities:

1.1 Requirements elicitation

1.2 Requirements specification

1.3 Requirements verification and validation

1.4 Requirements management

1.1 Requirements Elicitation:

1. It is related to the various ways used to gain knowledge about the project domain and requirements.

2. The various sources of domain knowledge include customers, business manuals, the existing software of same type, standards and other stakeholders of the project.

3. The techniques used for requirements elicitation include interviews, brainstorming, task analysis, Delphi technique, prototyping, etc. Some of these are discussed here.

4.  Elicitation does not produce formal models of the requirements understood. Instead, it widens the domain knowledge of the analyst and thus helps in providing input to the next stage.

1.2 Requirements specification:

1. This activity is used to produce formal software requirement models.

2. All the requirements including the functional as well as the non-functional requirements and the constraints are specified by these models in totality.

3. During specification, more knowledge about the problem may be required which can again trigger the elicitation process.

4. The models used at this stage include ER diagrams, data flow diagrams(DFDs), function decomposition diagrams(FDDs), data dictionaries, etc.

1.3 Requirements verification and validation:

1. Verification: It refers to the set of tasks that ensures that the software correctly implements a specific function.

2. Validation: It refers to a different set of tasks that ensures that the software that has been built is traceable to customer requirements.

3. If requirements are not validated, errors in the requirement definitions would propagate to the successive stages resulting in a lot of modification and rework.

The main steps for this process include:

3.1 The requirements should be consistent with all the other

3.2 requirements i.e no two requirements should conflict with each other.

3.3 The requirements should be complete in every sense.

3.4 The requirements should be practically achievable.

1.4 Requirements management:

1. Requirement management is the process of analyzing, documenting, tracking, prioritizing and agreeing on the requirement and controlling the communication to relevant stakeholders.

2. This stage takes care of the changing nature of requirements. It should be ensured that the SRS is as modifiable as possible so as to incorporate changes in requirements specified by the end users at later stages too.

3. Being able to modify the software as per requirements in a systematic and controlled manner is an extremely important part of the requirements engineering process.

Q2. State and explain three types of Types of requirements in detail?

A 2)

Software requirement can be of 3 types:

4.2.1 Functional requirements

4.2.2 Non-functional requirements

4.2.3 Domain requirements

1. Functional Requirements:

1. These are the requirements that the end user specifically demands as basic facilities that the system should offer.

2. All these functionalities need to be necessarily incorporated into the system as a part of the contract.

3. These are represented or stated in the form of input to be given to the system, the operation performed and the output expected.

4. They are basically the requirements stated by the user which one can see directly in the final product, unlike the non-functional requirements.

2. Non-functional requirements:

1. These are basically the quality constraints that the system must satisfy according to the project contract.

2. The priority or extent to which these factors are implemented varies from one project to other. They are also called non-behavioral requirements.

3. They basically deal with issues like:

3.1 Portability

3.2 Security

3.3 Maintainability

3.4 Reliability

3.5 Scalability

3.6 Performance

3.7 Reusability

3.8 Flexibility

4. NFR’s are classified into following types:

4.1 Interface constraints

4.2 Performance constraints: response time, security, storage space, etc.

4.3 Operating constraints

4.4 Life cycle constraints: maintainability, portability, etc.

4.5 Economic constraints

The process of specifying non-functional requirements requires the knowledge of the functionality of the system, as well as the knowledge of the context within which the system will operate.

3. Domain requirements

1. Domain requirements are the requirements which are characteristic of a particular category or domain of projects.

2. The basic functions that a system of a specific domain must necessarily exhibit come under this category.

3.  For instance, in an academic software that maintains records of a school or college, the functionality of being able to access the list of faculty and list of students of each grade is a domain requirement.

4. These requirements are therefore identified from that domain model and are not user specific.

Q3. State the Requirements specifications for real time systems?

A 3)

1. Quality of service (QoS) requirements specify how well a functional requirement shall be accomplished.

2. In real-time and embedded systems, QoS requirements may specify properties of the system (for example, range, speed, throughput, capacity, reliability, maintainability, evolvability, time to market, safety, predictability, schedulability), or properties of the process.

3. As a rule of thumb, if it's something that can be quantified or optimized, then it is a QoS requirement. For example (QoS requirements italicized):

3.1 The angle of the telescope shall be set in units of 0.1 degrees with a maximum error of 0.01 degrees.

3.2 The aesthetic agent shall be controllable from 0.00% to 5.00% by volume in units of 0.01% with an accuracy of 0.005%.

3.3 Locking clamps shall engage in the event of an elevator support cable breakage within less than 0.5 seconds.

3.4 The device shall alarm within 10 seconds if the heart rate falls below 30 beats per minute.

4. The defining characteristic of real-time systems is the level to which QoS timing requirements figure into the correctness of the system.

5. In non-real-time systems, late is acceptable. In real-time systems, late is unacceptable. Put another way, a real-time system is not necessarily fast, but it is predictably timely.

6. Of course, real-time systems may be hard real-time, which means that responses to events for aperiodic systems or actions taken when a periodic task begins (time-driven systems) must complete by a specified deadline.

7. Systems may also be soft real-time. For example:

7.1 Event responses shall be handled on average within a certain time.

7.2 A certain number of event responses shall be handled within a specified timeframe.

7.3 A specified failure rate is permitted.

Q4. Explain in detail Formal methods in software specifications?

A 4)

1. Formal methods are system design techniques that use rigorously specified mathematical models to build software and hardware systems.

2. In contrast to other design systems, formal methods use mathematical proof as a complement to system testing in order to ensure correct behaviour.

3. As systems become more complicated, and safety becomes a more important issue, the formal approach to system design offers another level of insurance.

4. Formal methods differ from other design systems through the use of formal verification schemes, the basic principles of the system must be proven correct before they are accepted .

5. Traditional system design has used extensive testing to verify behavior, but testing is capable of only finite conclusions.

6. Dijkstra and others have demonstrated that tests can only show the situations where a system won't fail, but cannot say anything about the behavior of the system outside of the testing scenarios In contrast, once a theorem is proven true it remains true.

7. Roughly speaking, formal design can be seen as a three step process, following the outline given here:

7.1 Formal Specification: During the formal specification phase, the engineer rigorously defines a system using a modeling language. Modelling languages are fixed grammars which allow users to model complex structures out of predefined types. This process of formal specification is similar to the process of converting a word problem into algebraic notation.

7.2. Verification: As stated above, formal methods differ from other specification systems by their heavy emphasis on provability and correctness. By building a system using a formal specification, the designer is actually developing a set of theorems about his system. By proving these theorems correct, the formal

7.3 Implementation: Once the model has been specified and verified, it is implemented by converting the specification into code. As the difference between software and hardware design grows narrower, formal methods for developing embedded systems have been developed. LARCH, for example, has a VHDL implementation. Similarly, hardware systems such as the VIPER and AAMP5 processors have been developed using formal approaches.

Q5. Write a short note on Structured analysis and design?

A 5)

1. Structured Analysis and Structured Design (SA/SD) is diagrammatic notation which is design to help people understand the system.

2.  The basic goal of SA/SD is to improve quality and reduce the risk of System failure. It establishes concrete management specification and documentation. It focuses on solidity, pliability and maintainability of system.

3. Basically the approach of SA/SD is based on the Data Flow Diagram. It is easy to understand SA/SD but it focuses on well defined system boundary whereas JSD approach is too complex and does not have any graphical representation.

4. SA/SD is combined known as SAD and it mainly focuses on following 3 points:

4.1 System

4.2 Process

4.3 Technology

Q6. State and explain 2 phases involved in structured analysis and structured design?

A 6)

1. SA/SD involves 2 phases:

1.1 Analysis Phase:

 It uses Data Flow Diagram, Data Dictionary, State Transition diagram and ER diagram.

1.2 Design Phase:

It uses Structure Chart and Pseudo Code.

1.1.1 Data Flow Diagram:

1. In the data flow diagram model describe how the data flows through the system. We can incorporate the Boolean operators and & or to link data flows when more than one data flow may be input or output from a process.

For example, if we have to choose between two paths of a process we can add an operator or and if two data flows are necessary for a process we can add and operator. The input of the process “check-order” needs the credit information and order information whereas the output of the process would be a cash-order or a good-credit-order.

1.1.2 Data Dictionary:

1. The content that are not described in the DFD are described in data dictionary. It defines the data store and relevant meaning.

2. A physical data dictionary for data elements which flow between processes, between entities, and between processes and entities may be included. This would also include descriptions of data elements that flow external to the data stores.

3. A logical data dictionary may also be included for each such data element. All system names, whether they are names of entities, types, relations, attributes or services, should be entered in the dictionary.

1.1.3 State Transition Diagram:

1. State transition diagram is similar to dynamic model. It specifies how much time function will take to execute and data access triggered by events.

2. It also describes all of the states that an object can have, the events under which an object changes state, the conditions that must be fulfilled before the transition will occur and the activities undertaken during the life of an object.

1.1.4 ER Diagram:

1. ER diagram specifies the relationship between data store. It is basically used in database design. It basically describes the relationship between different entities.

1.2. Design Phase:

Design Phase involves structure chart and pseudo code.

1.2.1 Structure Chart:

1. It is created by the data flow diagram. Structure Chart specifies how DFS’s processes are grouped into task and allocate to CPU.

2. The structured chart does not show the working and internal structure of the processes or modules, and does not show the relationship between data or data-flows.

3. Similar to other SASD tools, it is time and cost independent and there is no error-checking technique associated with this tool.

4. The modules of a structured chart are arranged arbitrarily and any process from a DFD can be chosen as the central transform depending on the analysts’ own perception.

6. The structured chart is difficult to amend, verify, maintain, and check for completeness and consistency.

1.2.2 Pseudo Code:It is actual implementation of system.It is a informal way of programming which doesn’t require any specific programming language or technology.

Q7. Write a short note on Unified modelling language?

A 7)

1. UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems.

2. UML was created by the Object Management Group (OMG) and UML 1.0 specification draft was proposed to the OMG in January 1997.

3. OMG is continuously making efforts to create a truly industry standard.

3.1 UML stands for Unified Modeling Language.

3.2 UML is different from the other common programming languages such as C++, Java, COBOL, etc.

3.3 UML is a pictorial language used to make software blueprints.

3.4 UML can be described as a general purpose visual modeling language to visualize, specify, construct, and document software system.

3.5 Although UML is generally used to model software systems, it is not limited within this boundary. It is also used to model non-software systems as well. For example, the process flow in a manufacturing unit, etc.

4. UML is not a programming language but tools can be used to generate code in various languages using UML diagrams. UML has a direct relation with object oriented analysis and design. After some standardization, UML has become an OMG standard.

Q8. Explain the concept of organizing the requirements of documents? 

A 8)

1. Documentation ensures that the software development team or other stakeholders are on the same page regarding what needs to be built and are fully aware of the goal, scope, functional requirements, challenges, and budget regarding the software.

2. However, as much as creating software is exciting, documenting its requirements can be boring and tiresome.

3. A software requirements document (also known as software requirements specifications) is a document that describes the intended use-case, features, and challenges of a software application.

4. These documents are created before the project has started development in order to get every stakeholder on the same page regarding the software’s functionality.

5. Software requirements are written up by the tech team depending on the project they are working on. As non-technical colleagues, clients, and partners get involved it’s important to ensure that everyone is on the same page and agree with the scope, budget, and goal of the project.

6. Software requirement documents provide an important map of the product being built, the features that will be included, and much more.

7. This roadmap helps to keep the technical and non-technical team on the same wavelength as to what the expectations are. It helps to ensure that the product is built meeting the needs whether it’s for internal purposes, for users or clients.

Q9. Explain the things required in organizing and writing requirement in software engineering?  

A 9)

A software requirements specification (SRS) is a document that describes what the software will do and how it will be expected to perform. It also describes the functionality the product needs to fulfill all stakeholders (business, users) needs.

A typical SRS includes:

1. A purpose

2. An overall description

3. Specific requirements

Your first step is to create an outline for your software requirements specification. This may be something you create yourself. Or you may use an existing SRS template.

If you’re creating this yourself, here’s what your outline might look like:

1. Start with a Purpose

The introduction to your SRS is very important. It sets the expectation for the product you’re building.

So, start by defining the purpose of your product.

2. Give an Overview of What You’ll Build

2.1 Your next step is to give a description of what you’re going to build. Is it an update to an existing product? Is it a new product? Is it an add-on to a product you’ve already created?

2.2 These are important to describe upfront, so everyone knows what you’re building.

You should also describe why you’re building it and who it’s for.

2.3.1 User Needs

2.3.2 Assumptions and Dependencies

3. Detail Your Specific Requirements

The next section is key for your development team. This is where you detail the specific requirements for building your product.

3.1 Functional Requirements

Functional requirements are essential to building your product.

If you’re developing a medical device, these requirements may include infusion and battery. And within these functional requirements, you may have a subset of risks and requirements.

3.2 External Interface Requirements

External interface requirements are types of functional requirements. They’re important for embedded systems. And they outline how your product will interface with other components.

There are several types of interfaces you may have requirements for, including:

3.2.1 User

3.2.2 Hardware

3.2.3 Software

3.2.4 Communications

3.3 System Features

System features are types of functional requirements. These are features that are required in order for a system to function.

3.4 Other Non-functional Requirements

Q10. Explain the needs of Requirements Validation in software engineering?

A 10)

1. It’s a process of ensuring the specified requirements meet the customer needs. It’s concerned with finding problems with the requirements.

2. These problems can lead to extensive rework costs when these they are discovered in the later stages, or after the system is in service.

3. The cost of fixing a requirements problem by making a system change is usually much greater than repairing design or code errors. Because a change to the requirements usually means the design and implementation must also be changed, and re-tested.

4. During the requirements validation process, different types of checks should be carried out on the requirements. These checks include:

4.1 Validity checks: The functions proposed by stakeholders should be aligned with what the system needs to perform. You may find later that there are additional or different functions are required instead.

4.2 Consistency checks: Requirements in the document shouldn’t conflict or different description of the same function

4.3 Completeness checks: The document should include all the requirements and constrains.

4.4 Realism checks: Ensure the requirements can actually be implemented using the knowledge of existing technology, the budget, schedule, etc.

5. Verifiability: Requirements should be written so that they can be tested. This means you should be able to write a set of tests that demonstrate that the system meets the specified requirements.

6. There are some techniques you can use to validate the requirements, and you may use one or more of them together, depending on your needs.

Q11. Write a short note on need of Requirements Reviews in software engineering?

A 11)

1. A team of system customer; those who interact with the customer to gather requirements, and system developers start reading the requirements in the document, and investigate in a great detail to check for errors, inconsistency, conflicts, and any ambiguity.

2. Then they may negotiate with the customer on how to solve the problems and errors found.

3. Prototyping

3.1 We’ve discussed the prototyping as one of the (non-standalone) software process methodology, which used as part of a full methodologies, and we’ve also mentioned in can be used in the requirements engineering.

3.2 In this approach to validation, an executable model of the system is demonstrated to the customer and end users to validate, and ensure if it meets their needs.

3.3 Prototyping is usually used when the requirements aren’t clear. So, we make a quick design of the system to validate the requirements. If it fails, we then refine it, and check again, until it meets the customer needs.

3.4 This definitely will decrease the cost as a result of having a clear, understandable, consistent requirements.

Q12. What is Coding of real time software? Explain in detail

A 12)

1. Real-time computing (RTC), or reactive computing is the computer science term for hardware and software systems subject to a "real-time constraint", for example from event to system response.

2. Real-time programs must guarantee response within specified time constraints, often referred to as "deadlines".

3. Real-time responses are often understood to be in the order of milliseconds, and sometimes microseconds.

4. A system not specified as operating in real time cannot usually guarantee a response within any timeframe, although typical or expected response times may be given. Real-time processing fails if not completed within a specified deadline relative to an event; deadlines must always be met, regardless of system load.

5. A real-time system has been described as one which "controls an environment by receiving data, processing them, and returning the results sufficiently quickly to affect the environment at that time". The term "real-time" is also used in simulation to mean that the simulation's clock runs at the same speed as a real clock, and in process control and enterprise systems to mean "without significant delay".

6. Real-time software may use one or more of the following: synchronous programming languages, real-time operating systems, and real-time networks, each of which provide essential frameworks on which to build a real-time software application.

7. A system is said to be real-time if the total correctness of an operation depends not only upon its logical correctness, but also upon the time in which it is performed.

8.  Real-time systems, as well as their deadlines, are classified by the consequence of missing a deadline

8.1 Hard – missing a deadline is a total system failure.

8.2 Firm – infrequent deadline misses are tolerable, but may degrade the system's quality of service. The usefulness of a result is zero after its deadline.

8.3 Soft – the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service.

9. Thus, the goal of a hard real-time system is to ensure that all deadlines are met, but for soft real-time systems the goal becomes meeting a certain subset of deadlines in order to optimize some application-specific criteria.

10. The particular criteria optimized depend on the application, but some typical examples include maximizing the number of deadlines met, minimizing the lateness of tasks and maximizing the number of high priority tasks meeting their deadlines

Q13. Explain Assembly programming language in detail?

A 13)

1. An assembly language is a low-level programming language designed for a specific type of processor. It may be produced by compiling source code from a high-level programming language (such as C/C++) but can also be written from scratch. Assembly code can be converted to machine code using an assembler.

2. Since most compilers convert source code directly to machine code, software developers often create programs without using assembly language.

3. However, in some cases, assembly code can be used to fine-tune a program.

4. For example, a programmer may write a specific process in assembly language to make sure it functions as efficiently as possible.

5. While assembly languages differ between processor architectures, they often include similar instructions and operators. Below are some examples of instructions supported by x86 processors.

MOV - move data from one location to another

ADD - add two values

SUB - subtract a value from another value

PUSH - push data onto a stack

POP - pop data from a stack

JMP - jump to another location

INT - interrupt a process

The following assembly language can be used to add the numbers 3 and 4:

mov eax, 3 - loads 3 into the register "eax"

mov ebx, 4 - loads 4 into the register "ebx"

add eax, ebx, ecx - adds "eax" and "ebx" and stores the result (7) in "ecx"

6. Writing assembly language is a tedious process since each operation must be performed at a very basic level.

7. While it may not be necessary to use assembly code to create a computer program, learning assembly language is often part of a Computer Science curriculum since it provides useful insight into the way processors work.

8. Assembly language is a low-level programming language for a computer or other programmable device specific to a particular computer architecture in contrast to most high-level programming languages, which are generally portable across multiple systems. Assembly language is converted into executable machine code by a utility program referred to as an assembler like NASM, MASM, etc.

Q14. Define basic elements and state and explain 3 types of instruction statements that are used to define program operations?

A 14)

Basic elements:  There is a large degree of diversity in the way the authors of assemblers categorize statements and in the nomenclature that they use. In particular, some describe anything other than a machine mnemonic or extended mnemonic as a pseudo-operation (pseudo-op).

A typical assembly language consists of 3 types of instruction statements that are used to define program operations:

9.1 Opcode mnemonics

9.2 Data definitions

9.3 Assembly directives

9.1 opcode mnemonics

1. Instructions (statements) in assembly language are generally very simple, unlike those in high-level languages. Generally, a mnemonic is a symbolic name for a single executable machine language instruction (an opcode), and there is at least one opcode mnemonic defined for each machine language instruction.

2.  Each instruction typically consists of an operation or opcode plus zero or more operands. Most instructions refer to a single value or a pair of values. Operands can be immediate (value coded in the instruction itself), registers specified in the instruction or implied, or the addresses of data located elsewhere in storage.

3.  This is determined by the underlying processor architecture: the assembler merely reflects how this architecture works. Extended mnemonics are often used to specify a combination of an opcode with a specific operand, e.g., the System/360 assemblers use B as an extended mnemonic for BC with a mask of 15 and NOP for BC with a mask of 0.

9.2 Data directives

1. There are instructions used to define data elements to hold data and variables. They define the type of data, the length and the alignment of data.

2. These instructions can also define whether the data is available to outside programs (programs assembled separately) or only to the program in which the data section is defined. Some assemblers classify these as pseudo-ops.

9.3 Assembly directives

1. Assembly directives, also called pseudo-opcodes, pseudo-operations or pseudo-ops, are commands given to an assembler "directing it to perform operations other than assembling instructions".

2.  Directives affect how the assembler operates and "may affect the object code, the symbol table, the listing file, and the values of internal assembler parameters".

3. Sometimes the term pseudo-opcode is reserved for directives that generate object code, such as those that generate data.

Q15. Explain what is Procedural programming language in detail?

A 15)

1. A procedural language is a computer programming language that follows, in order, a set of commands. Examples of computer procedural languages are BASIC, C, FORTRAN, Java, and Pascal.

2. A procedural language, as the name implies, relies on predefined and well-organized procedures, functions or sub-routines in a program’s architecture by specifying all the steps that the computer must take to reach a desired state or output.

3. The procedural language segregates a program within variables, functions, statements and conditional operators. Procedures or functions are implemented on the data and variables to perform a task. These procedures can be called/invoked anywhere between the program hierarchy, and by other procedures as well. A program written in procedural language contains one or more procedures.

4. Procedural languages are some of the common types of programming languages used by script and software programmers. They make use of functions, conditional statements, and variables to create programs that allow a computer to calculate and display a desired output.

5. Using a procedural language to create a program can be accomplished by using a programming editor or IDE, like Adobe Dreamweaver, Eclipse, or Microsoft Visual Studio. These editors help users develop programming code using one or more procedural languages, test the code, and fix bugs in the code.

6. Procedural programming languages are also imperative languages, because they make explicit references to the state of the execution environment.

7. This could be anything from variables (which may correspond to processor registers) to something like the position of the "turtle" in the Logo programming language.

8. Often, the terms "procedural programming" and "imperative programming" are used synonymously.

9. However, procedural programming relies heavily on blocks and scope, whereas imperative programming as a whole may or may not have such features.

10. As such, procedural languages generally use reserved words that act on blocks, such as if, while, and for, to implement control flow, whereas non-structured imperative languages use goto statements and branch tables for the same purpose.

Q16. Write a short note on object oriented programming language?

A 16)

1. An object-oriented language is a computer programming language that revolves around the concept of an object.

2. Object-oriented languages were developed to make it easier to develop, debug, reuse, and maintain software than is possible with earlier languages. Understanding objects, and object-oriented languages, requires knowledge of the evolution of computer programming languages and data structures.

3. Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which can contain data and code: data in the form of fields (often known as attributes or properties), and code, in the form of procedures (often known as methods).

4. A feature of objects is that an object's own procedures can access and often modify the data fields of itself (objects have a notion of this or self). In OOP, computer programs are designed by making them out of objects that interact with one another.

Q17. State and explain Features of object oriented programming language in detail ?

A 17)

1. Object-oriented programming uses objects, but not all of the associated techniques and structures are supported directly in languages that claim to support OOP. The features listed below are common among languages considered to be strongly class- and object-oriented (or multi-paradigm with OOP support), with notable exceptions mentioned

6.1 Shared with non-OOP languages

1. Variables that can store information formatted in a small number of built-in data types like integers and alphanumeric characters. This may include data structures like strings, lists, and hash tables that are either built-in or result from combining variables using memory pointers.

2. Procedures – also known as functions, methods, routines, or subroutines – that take input, generate output, and manipulate data. Modern languages include structured programming constructs like loops and conditionals.

6.2 Objects and classes

1. Languages that support object-oriented programming (OOP) typically use inheritance for code reuse and extensibility in the form of either classes or prototypes. Those that use classes support two main concepts:

2. Classes – the definitions for the data format and available procedures for a given type or class of object; may also contain data and procedures (known as class methods) themselves, i.e. classes contain the data members and member functions

3. Objects – instances of classes

Objects sometimes correspond to things found in the real world. For example, a graphics program may have objects such as "circle", "square", "menu". An online shopping system might have objects such as "shopping cart", "customer", and "product". Sometimes objects represent more abstract entities, like an object that represents an open file, or an object that provides the service of translating measurements from U.S. customary to metric.

6.3. Class-based vs prototype-based

1. In class-based languages the classes are defined beforehand and the objects are instantiated based on the classes.

2. If two objects apple and orange are instantiated from the class Fruit, they are inherently fruits and it is guaranteed that you may handle them in the same way; e.g. a programmer can expect the existence of the same attributes such as color or sugar content or is ripe.

3. In prototype-based languages the objects are the primary entities. No classes even exist. The prototype of an object is just another object to which the object is linked.

4.  Every object has one prototype link (and only one). New objects can be created based on already existing objects chosen as their prototype. You may call two different objects apple and orange a fruit, if the object fruit exists, and both apple and orange have fruit as their prototype

6.4 Dynamic dispatch/message passing

1. It is the responsibility of the object, not any external code, to select the procedural code to execute in response to a method call, typically by looking up the method at run time in a table associated with the object.

2. This feature is known as dynamic dispatch, and distinguishes an object from an abstract data type (or module), which has a fixed (static) implementation of the operations for all instances.

3. If the call variability relies on more than the single type of the object on which it is called (i.e. at least one other parameter object is involved in the method choice), one speaks of multiple dispatch.

6.5 Encapsulation

1. Encapsulation is an object-oriented programming concept that binds together the data and functions that manipulate the data, and that keeps both safe from outside interference and misuse. Data encapsulation led to the important OOP concept of data hiding.

2. If a class does not allow calling code to access internal object data and permits access through methods only, this is a strong form of abstraction or information hiding known as encapsulation. Some languages (Java, for example) let classes enforce access restrictions explicitly, for example denoting internal data with the private keyword and designating methods intended for use by code outside the class with the public keyword.

3. Methods may also be designed public, private, or intermediate levels such as protected (which allows access from the same class and its subclasses, but not objects of a different class).

6.6 Composition, inheritance, and delegation

1. Objects can contain other objects in their instance variables; this is known as object composition. For example, an object in the Employee class might contain (either directly or through a pointer) an object in the Address class, in addition to its own instance variables like "first_name" and "position".

2.  Object composition is used to represent "has-a" relationships: every employee has an address, so every Employee object has access to a place to store an Address object (either directly embedded within itself, or at a separate location addressed via a pointer).

3. Languages that support classes almost always support inheritance. This allows classes to be arranged in a hierarchy that represents "is-a-type-of" relationships. For example, class Employee might inherit from class Person. All the data and methods available to the parent class also appear in the child class with the same names.

4. Subclasses can override the methods defined by superclasses. Multiple inheritance is allowed in some languages, though this can make resolving overrides complicated. Some languages have special support for mixins, though in any language with multiple inheritance, a mixin is simply a class that does not represent an is-a-type-of relationship.

5. Delegation is another language feature that can be used as an alternative to inheritance.

6.7 Polymorphism

Subtyping – a form of polymorphism – is when calling code can be agnostic as to which class in the supported hierarchy it is operating on – the parent class or one of its descendants. Meanwhile, the same operation name among objects in an inheritance hierarchy may behave differently.

For example, objects of type Circle and Square are derived from a common class called Shape. The Draw function for each type of Shape implements what is necessary to draw itself while calling code can remain indifferent to the particular type of Shape being drawn.

6.8 Open recursion

1. In languages that support open recursion, object methods can call other methods on the same object (including themselves), typically using a special variable or keyword called this or self.

2. This variable is late-bound; it allows a method defined in one class to invoke another method that is defined later, in some subclass thereof.

Q18. Give a short Overview of Programming Languages for Real-Time Systems?

A 18)

1. The real-time and embedded systems market is huge and growing all the time. It has been estimated that 100 times more processors are destined for embedded systems rather than the desktop .

 1.1 Embedded real-time systems

1.  Are mainly small (for example, mobile phones) but can also be extremely large and complex (for example air traffic control systems)

2. Have potentially complex mathematical models of their controlled environment

3.  Must be dependable

4.  Are inherently concurrent

5. Must interact within the time frame of the environment

6 must interact with low-level mechanisms such as hardware devices and memory

1.2 Management faculties.

1. The interdependence between functional and real-time semantics of real-time software makes its design, implementation and maintenance especially difficult. Providing a programming language that directly supports the characteristics of embedded real-time software can significantly ease these difficulties.

2.In addition, embedded software systems are not portable as they depend on the particular underlying operating system and hardware architecture.

3. Providing implementation-independent programming models also increases the portability.

Q19. State and explain Real time features of JAVA ?

A 19)

 Following are the notable features of Java:

1. Object Oriented

In Java, everything is an Object. Java can be easily extended since it is based on the Object model.

2. Platform Independent

Unlike many other programming languages including C and C++, when Java is compiled, it is not compiled into platform specific machine, rather into platform-independent byte code. This byte code is distributed over the web and interpreted by the Virtual Machine (JVM) on whichever platform it is being run on.

3. Simple

Java is designed to be easy to learn. If you understand the basic concept of OOP Java, it would be easy to master.

4. Secure

With Java's secure feature it enables to develop virus-free, tamper-free systems. Authentication techniques are based on public-key encryption.

5. Architecture-neutral

Java compiler generates an architecture-neutral object file format, which makes the compiled code executable on many processors, with the presence of Java runtime system.

6. Portable

Being architecture-neutral and having no implementation dependent aspects of the specification makes Java portable. The compiler in Java is written in ANSI C with a clean portability boundary, which is a POSIX subset.

7. Robust

Java makes an effort to eliminate error-prone situations by emphasizing mainly on compile time error checking and runtime checking.

8. Multithreaded

With Java's multithreaded feature it is possible to write programs that can perform many tasks simultaneously. This design feature allows the developers to construct interactive applications that can run smoothly.

9. Interpreted

Java byte code is translated on the fly to native machine instructions and is not stored anywhere. The development process is more rapid and analytical since the linking is an incremental and light-weight process.

10. High Performance

With the use of Just-In-Time compilers, Java enables high performance.

11. Distributed

Java is designed for the distributed environment of the internet.

12. Dynamic

Java is considered to be more dynamic than C or C++ since it is designed to adapt to an evolving environment. Java programs can carry an extensive amount of run-time information that can be used to verify and resolve accesses to objects at run-time.

Q20. Write a short note on C# languages?

A 20)

1. C# (pronounced see sharp, like the musical note C♯, but written with the number sign) is a general-purpose, multi-paradigm programming language encompassing static typing, strong typing, lexically scoped, imperative, declarative, functional, generic, object-oriented (class-based), and component-oriented programming disciplines.

2. The Ecma standard lists these design goals for C#

2.1 The language is intended to be a simple, modern, general-purpose, object-oriented programming language.

2.2 The language, and implementations thereof, should provide support for software engineering principles such as strong type checking, array bounds checking, detection of attempts to use uninitialized variables, and automatic garbage collection. Software robustness, durability, and programmer productivity are important.

2.3 The language is intended for use in developing software components suitable for deployment in distributed environments.

2.4 Portability is very important for source code and programmers, especially those already familiar with C and C++.

2.5 Support for internationalization is very important.

2.6 C# is intended to be suitable for writing applications for both hosted and embedded systems, ranging from the very large that use sophisticated operating systems, down to the very small having dedicated functions.

2.7 Although C# applications are intended to be economical with regard to memory and processing power requirements, the language was not intended to compete directly on performance and size with C or assembly language.

Q21. State and explain Distinguishing features of C# programming languages?

A 21)

3.1 Portability

By design, C# is the programming language that most directly reflects the underlying Common Language Infrastructure (CLI).[58] Most of its intrinsic types correspond to value-types implemented by the CLI framework. However, the language specification does not state the code generation requirements of the compiler

3.2 Typing

1. C# supports strongly typed implicit variable declarations with the keyword var, and implicitly typed arrays with the keyword new[] followed by a collection initializer.C# supports a strict Boolean data type, bool.

2. Statements that take conditions, such as while and if, require an expression of a type that implements the true operator, such as the Boolean type. While C++ also has a Boolean type, it can be freely converted to and from integers, and expressions such as if (a) require only that a is convertible to bool, allowing a to be an int, or a pointer.

3.3 Metaprogramming

Metaprogramming via C# attributes is part of the language. Many of these attributes duplicate the functionality of GCC's and VisualC++'s platform-dependent preprocessor directives.

3.4 Methods and functions

1. A method in C# is a member of a class that can be invoked as a function (a sequence of instructions), rather than the mere value-holding capability of a class property.

2. As in other syntactically similar languages, such as C++ and ANSI C, the signature of a method is a declaration comprising in order: any optional accessibility keywords (such as private), the explicit specification of its return type (such as int, or the keyword void if no value is returned), the name of the method, and finally, a parenthesized sequence of comma-separated parameter specifications, each consisting of a parameter's type, its formal name and optionally, a default value to be used whenever none is provided.

3.5 Property

C# supports class with properties. The properties can be simple accessor functions with a backing field, or implement getter and setter functions.

Since C# 3.0 the syntactic sugar of auto-implemented properties is available,[60] where the accessor (getter) and mutator (setter) encapsulate operations on a single attribute of a class.

3.6 Namespace

A C# namespace provides the same level of code isolation as a Java package or a C++ namespace, with very similar rules and features to a package. Namespaces can be imported with the "using" syntax.

3.7 Memory access

In C#, memory address pointers can only be used within blocks specifically marked as unsafe, and programs with unsafe code need appropriate permissions to run. Most object access is done through safe object references, which always either point to a "live" object or have the well-defined null value; it is impossible to obtain a reference to a "dead" object (one that has been garbage collected), or to a random block of memory.

3.8 Exception

A range of standard exceptions are available to programmers. Methods in standard libraries regularly throw system exceptions in some circumstances and the range of exceptions thrown is normally documented. Custom exception classes can be defined for classes allowing specific handling to be put in place for particular circumstances as needed

3.9 Polymorphism

1. Unlike C++, C# does not support multiple inheritance, although a class can implement any number of interfaces. This was a design decision by the language's lead architect to avoid complications and to simplify architectural requirements throughout CLI.

2. When implementing multiple interfaces that contain a method with the same name and taking parameters of the same type in the same order (i.e. the same signature), similar to Java, C# allows both a single method to cover all interfaces and if necessary specific methods for each interface.

3.10 Language Integrated Query (LINQ)

1. C# has the ability to utilize LINQ through the .NET Framework. A developer can query a variety of data sources, provided IEnumerable<T> interface is implemented on the object. This includes XML documents, an ADO.NET dataset, and SQL databases.

2. Using LINQ in C# brings advantages like Intellisense support, strong filtering capabilities, type safety with compile error checking ability, and consistency for querying data over a variety of sources.

3.11 Functional programming

1. Though primarily an imperative language, C# 2.0 offered limited support for functional programming through first-class functions and closures in the form of anonymous delegates.

2. C# 3.0 expanded support for functional programming with the introduction of a lightweight syntax for lambda expressions, extension methods (an affordance for modules), and a list comprehension syntax in the form of a "query comprehension" language. C# 7.0 adds features typically found in functional languages like tuples and pattern matching.