f

What is SQL? Why it is needed

By // No comments:
SQL (pronounced "ess-que-el") stands for Structured Query Language. SQL is used to communicate with a database. According to ANSI (American National Standards Institute), it is the standard language for relational database management systems. SQL statements are used to perform tasks such as update data on a database, or retrieve data from a database. Some common relational database management systems that use SQL are: Oracle, Sybase, Microsoft SQL Server, Access, Ingres, etc. 
 
Although most database systems use SQL, most of them also have their own additional proprietary extensions that are usually only used on their system. However, the standard SQL commands such as "Select", "Insert", "Update", "Delete", "Create", and "Drop" can be used to accomplish almost everything that one needs to do with a database. This tutorial will provide you with the instruction on the basics of each of these commands as well as allow you to put them to practice using the SQL Interpreter.
  1. Allows users to access data in relational data base management system
  2. Allows users to describe the data.
  3. Allows users ti define the data in the data base and manipulate that data.
  4. Allows to embedded with in other languages using SQL modules, libraries, per-compilers.
  5. Allows users to create and drop data base and tables.
  6. Allows users to create view, stored procedure, functions in a database.
  7. Allows users to set permission on tables, procedures and views.
Features of SQL
  1. Accepts SQL statements from file. It provides a line editor.
  2. It provides format, iteration and file commands.
  3. Format query design and display reports on the screen.
  4. It supports control environment settings.
  5. It access remote and local data base.

 Source: www.w3schools.com, www.sqlcourse.com 

Requirements Elicitation and Analysis Process in Software Engineering

By // No comments:
It’s a process of interacting with customers and end-users to find out about the domain requirements, what services the system should provide, and the other constrains.

It may also involve a different kinds of stockholders; end-users, managers, system engineers, test engineers, maintenance engineers, etc.

The requirements elicitation and analysis has 4 main process

We typically start by gathering the requirements, this could be done through a general discussion or interviews with your stakeholders, and also it may involve some graphical notation.

Then you organize the related requirements into sub components and prioritize them, and finally, you refine them by removing any ambiguous requirements that may rise from some conflicts.

Here are the 4 main processes of requirements elicitation and analysis.



It shows that it’s an iterative process with a feedback from each activity to another. The process cycle starts with requirements discovery and ends with the requirements document. The cycle ends when the requirements document is complete.

1. Requirements Discovery

It’s the process of interacting with, and gathering the requirements from, the stakeholders about the required system and the existing system (if exist).

It can be done using some techniques, like interviews, scenarios, prototypes, etc, which help the stockholders to understand what the system will be like.

Gathering and understanding the requirements is a difficult process

That’s because stakeholders may not know what exactly they want the software to do, or they may give un-realistic requirements.

They may give different requirements, which will result in conflict between the requirements, so we have to discover and resolve these conflicts.

Also there might be some factors that influence on the stakeholder’s decision, like for example; managers at a company or professors at the university want to take a full control over the management system.

Interviews

In Interviews, requirements engineering teams put the questions to the stakeholder about the system that’s currently used, and the system to be developed, and hence they can gather the requirements from the answers.

The questions fall under two categories:
  1. Closed-Ended questions: A pre-defined set of question.
  2. Open-Ended questions: There is no a pre-defined expected answer, they are more of generic questions. It’s used to explore an issue that’s not clear in a less structured way.
In practice, interviews usually use mixture of both. Usually, start with the open-ended questions, and then use the closed-ended questions to be more specific about some requirements that aren’t clear yet.
Interviews are good to get an overall understanding of what stakeholders need, how they might interact with the new system, and the difficulties they face with the current system.

However, interviews aren’t so helpful in understanding the domain requirements. This is for two reasons:
  1. Domain requirements may be expressed using special domain terminologies, and software engineers often find it difficult to understand and it’s easy for them to misunderstand.
  2. Sometimes stakeholders won’t tell you some requirements because they assume it’s so fundamental and it doesn’t worth mentioning, or they find it difficult to explain, which won’t be taken into consideration in the requirements.
 Use Cases and Scenarios

1)    The use cases and scenarios are two different techniques, but, usually they are used together.
2)    Use cases identify interactions between the system and its users or even other external systems (using graphical notations), while a scenario is a textual description of one or more of these interactions.
Use case involves some symbols to describe the system:


  1. Actors: Are those who interact with the system; human or other systems
  2. Interaction (Use Case): It denotes the name of the interaction (verb). It’s represented as a named ellipse.
  3. Connection: Lines that links between the actors and the interactions.
  4. Include Relationship: It denotes a connection between two interactions when an interaction is invoked by another. As an example, splitting a large interaction into several interactions.
  5. Exclude Relationship: It denotes a connection between two interactions when you want to extend an interaction by adding an optional behavior, but you can use the main interaction on it’s own without the extending interaction.
Now, we are going to use scenarios to describe the interactions in each use case textually. They should have a format and include the following:

  1. A description of the initial situation.
  2. A description of the flow of the events or interactions with the system
  3. A description of the exceptions, or in other words, what can go wrong, and how it can be handled.
  4. Any concurrent activities should be mentioned
  5. A description of the final state.
Here is the example for a scenario for the use case example above.

2. Requirements Classification and Organization

  • It’s very important to organize the overall structure of the system.
  • Putting related requirements together, and decomposing the system into sub components of related requirements. Then, we define the relationship between these components.
  • What we do here will help us in the decision of identifying the most suitable architectural design patterns.

3. Requirements Prioritization and Negotiation

We previously explained why eliciting and understanding the requirements is not an easy process.
One of the reasons is the conflicts that may arise as a result of having different stakeholders involved. Why? because it’s hard to satisfy all parties, if it’s not impossible.

This activity is concerned with prioritizing requirements and finding and resolving requirements conflicts through negotiations until you reach a situation where some of the stakeholders can compromise.

We shouldn’t reach a situation where a stakeholder is not satisfied because his requirements is not taken into consideration.

Prioritizing your requirements will help you later to focus on the essentials and core features of the system, so you can meet the user expectations. It can be achieved by giving every piece of function a priority level. So, functions with higher priorities need higher attention and focus.

4. Requirements Specification

The requirements are then documented.

Feasibility Study in Software Engineering

By // No comments:
The purpose of feasibility study is not to solve the problem, but to determine whether the problem is worth solving. A feasibility study is a short, focused study that aims to answer a number of questions.
  1. Does the system contribute to the overall objectives of the organization?
  2. Can the system be implemented using current technology and with given coast and schedule constraints?
  3. Can the system be integrated with the other systems which are already in place?
The main aim of the feasibility study activity is to determine whether it would be financially and technically feasible to develop the product. The feasibility study activity involves the analysis of the problem and collection of all relevant information relating to the product such as the different data items which would be input to the system, the processing required to be carried out on these data, the output data required to be produced by the system as well as various constraints on the behavior of the system.

Technical Feasibility

This is concerned with specifying equipment and software that will successfully satisfy the user requirement. The technical needs of the system may vary considerably, but might include :
  1. The facility to produce outputs in a given time.
  2. Response time under certain conditions.
  3. Ability to process a certain volume of transaction at a particular speed.
  4. Facility to communicate data to distant locations.

In examining technical feasibility, configuration of the system is given more importance than the actual make of hardware. The configuration should give the complete picture about the system’s requirements:

How many workstations are required, how these units are interconnected so that they could operate and communicate smoothly?

What speeds of input and output should be achieved at particular quality of printing.

Economic Feasibility

Economic analysis is the most frequently used technique for evaluating the effectiveness of a proposed system. More commonly known as Cost / Benefit analysis, the procedure is to determine the benefits and savings that are expected from a proposed system and compare them with costs. If benefits outweigh costs, a decision is taken to design and implement the system. Otherwise, further justification or alternative in the proposed system will have to be made if it is to have a chance of being approved. This is an outgoing effort that improves in accuracy at each phase of the system life cycle.

Operational Feasibility

This is mainly related to human organizational and political aspects. The points to be considered are:
  1. What changes will be brought with the system?
  2. What organizational structures are disturbed?
  3. What new skills will be required? Do the existing staff members have these skills? If not, can they be trained in due course of time?
This feasibility study is carried out by a small group of people who are familiar with information system technique and are skilled in system analysis and design process.

Proposed projects are beneficial only if they can be turned into information system that will meet the operating requirements of the organization. This test of feasibility asks if the system will work when it is developed and installed.

Requirement Engineering Process

By // No comments:
Software specification or requirements engineering is the process of understanding and defining what services are required and identifying the constraints on these services.

Requirements engineering processes ensures your software will meet the user expectations, and ending up with a high quality software.

It’s a critical stage of the software process as errors at this stage will reflect later on the next stages, which definitely will cause you a higher cost.

At the end of this stage, a requirements document that specifies the requirements will be produced and validated with the stockholders.

There are four main activities (or sub-activities) of requirements engineering:



Feasibility study: An estimate is made of whether the identified can be achieved using the current software and hardware technologies, under the current budget, etc. The feasibility study should be cheap and quick; it should inform the decision of whether or not to go ahead with the project.

 Requirements elicitation and analysis: This is the process of deriving the system requirements through observation of existing systems, discussions with stakeholders, etc. This may involve the development of one or more system models and prototypes that can help us understanding the system to be specified.

 Requirements specification: It’s the activity of writing down the information gathered during the elicitation and analysis activity into a document that defines a set of requirements. Two types of requirements may be included in this document; user and system requirements.

 Requirements validation: It’s the process of checking the requirements for realism, consistency and completeness. During this process, our goal is to discover errors in the requirements document. When errors are found, it must be modified to correct these problems.

Requirements management:


Requirement management is the process of analyzing, documenting, tracking, prioritizing and agreeing on the requirement and controlling the communication to relevant stakeholders. 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. Being able to modify the software as per requirements in a systematic and controlled manner in an extremely important part of the requirements engineering process.

A requirement Engineering is a process in which various activates such as discovery, analysis and validation of system requirements are done. The spiral model of requirement engineering process is

Files used in C program

By // No comments:
while creating and running a c program we will use four types of files.

1. source file
2. library file
3. object file
4. executable file


Source file is file where the original source code is present. The source file has .c extension. While creating c language the developers of c defined some predefined files called header files. They contain related programs.

The commonly used header files are

string.h -- for string handling functions.
math.h --- for mathematical functions.
alloc.h --- for dynamic memory allocation.
conio.h --- for clearing the screen.

an object file is a file generated by compiler as result of processing the source code.

The binary executable file is generated by the linker. The linker links various object files to produce a binary file that can be directly executed on windows operating system. The executable file have .exe extension.

Writing first C program | How to write C program

By // No comments:
C program is a collection of different functions. A function is a self contained block that performs a single task. For example consider the following program




/* this program prints a value */
int show(int a);
void main()
{
 int a;
 printf(" enter a value");
 scanf("%d",&a);
 show(a);

}

int show()
{
 printf(" value of a is=%d",a);
}
In the above program the first line is a comment line, and it follows a global declaration section, then it follows main() method.

In main() method we are declaring a variable to hold values. The after we are reading the value using standard input and output functions scanf() and printf(). Then we are calling the user defined function with some parameters. The sun program section contains implementation for user defined function. It calculates 'a' value and print it on the screen.

Why multiple inheritance not support in Java

By // No comments:
In languages like C++ multiple inheritance play a important role to implement many of applications. In multiple inheritance we inherit the properties and behaviors of more than one class into a single class. For example

In this diagram class C inherits the properties and behaviors of class A and class B. This type of implementation is called " multiple inheritance" and it is not supported in java using classes. But we implement multiple inheritance using classes.


Why multiple inheritance is not directly supported in Java?

To reduce the complexity and simplify the language. multiple inheritance is not supported in java.

Consider a scenario where A and B are super classes and C is derived class derived from A and B like below

Since both super classes contains same method and you need to call those two methods using sub class object. that class C object.

Since compile time errors are better than run time errors, java renders compile time error if you inherit two classes in the above form. so whether you have same method or different there will be a compile time error.

For example consider the java program

class A
{
 void display()
 {
  System.out.println(" hellp");
 }
}
class B
{
 void display()
 {
  System.out.println("world");
 }
}

class C extend A,B
{
 public static void main(String args[])
 {
  C c1=new C();
  c1.display();
}
}
The above program generated the following output


 The error is at line " class C extend A,B" where we try to inherit two class.

Different types of functions in C

By // No comments:
A function is a self contained block that always reduces to a single value when executed. In C there are two types of functions are available: User defined functions and predefined functions / library functions.


Predefined functions:

The functions which are already defined in C libraries are called predefined functions or library functions. To use any predefined function in your C program, first you must include the appropriate header file and then call the library function with proper syntax. There is no to declared and define it. The declamation and definition are present in libraries itself.

For the following C program uses a power() function in 'math.h' header file


void main()
{
 int a=5,b=3,result;
 result=pow(a,b);
printf("result=%",result);
getch();
}

User Defined Functions

Functions provided by library are not enough for user so to complete their needs user has to define some functions themselves, these are called user defined functions.

To use user defined functions in C, you must declare it, you must call it, and you must define it. The following C program show a user define function is used.

void display();

void main()
{
 display();
getch();
}

void display()
{
 printf(" Hi, I am user defined function");
}