Sw Engg Exp1,2,3,4,5,6,7,8,9,10

EXPERIMENT NO-1. AIM: - Introduction to Data Flow Diagrams. Data Flow Diagrams:A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system. The DFD is a diagram that shows how the data manipulated by a system flows through the various processes. A DFD is not a flow chart! A flow chart actually describes a process, whereas in a DFD the entire process is simply denoted by a symbol. Data Flow Diagram is a diagram that shows how data moves through a system. A graphical notation used to describe how data flows between processes in a system. Data flow diagrams are an important tool of most structured analysis techniques. Data flow diagrams illustrate how data is processed by a system in terms of inputs and outputs.

Fig. A data flow diagram

1

Data Flow Diagram Notations:-

External Entity: The External Entity symbol represents sources of data to the system or destinations of data from the system. External entities are objects outside the system, with which the system communicates. Process: The Process symbol represents an activity that transforms or manipulates the data (combines, reorders, converts, etc.). Data Store: The Data Store symbol represents data that is not moving (delayed data at rest). Data stores are repositories of data in the system. They are sometimes also referred to as files. Dataflow: The Data Flow symbol represents movement of data. Data flows are pipelines through which packets of information flow. Label the arrows with the name of the data that moves through it.

2

Levels of DFDs:Data flow diagrams can be expressed as a series of levels. We begin by making a list of business activities to determine the DFD elements (external entities, data flows, processes, and data stores). Next, a context diagram is constructed that shows only a single process (representing the entire system), and associated external entities. The Diagram-0, or Level 0 diagram, is next, which reveals general processes and data stores. Following the drawing of Level 0 diagrams, child diagrams are drawn (Level 1 diagrams) for each process illustrated by Level 0 diagrams, and so on. Context Diagram: A Context Diagram (CD) is a graphical representation of a system which must only use one process to represent the entire system and deliberately does not go into defining all the processes so as to prevent people getting bogged down in complex details at an early stage.A context diagram is a top level (also known as Level 0) data flow diagram. It only contains one process node (process 0) that generalizes the function of the entire system in relationship to external entities. A good DFD starts with a Context Diagram -- a diagram with your component in the middle and all the external entities it talks to on the outside. An example for the bank teller might be something like this:

Fig An example of a Context or level 0 Diagram 3

Level 1 DFD: A data flow diagram is the next level up in detail from a context diagram. It will show processes, inputs, outputs and storage. The DFD shows the data flow between the processes within a system. A DFD can become as detailed as the user requires. The DFD will become increasingly detailed as the levels go higher. However each level will tend to focus on extending one or more of the processes rather than the entire system. The first level DFD shows the main processes within the system. Each of these processes can be broken into further processes.

Fig. An example of a first-level data flow diagram The steps to develop DFD level 1 are:

• • • •

Given the abstract data flows in Context Diagram, explicitly define in-flows and out-flows in your software in details. For each type of in-flow, we should create a bubble (a process) to handle the in-flow. For each type of out-flow, we should use a bubble created in the last step or create a new bubble to handle it. Define the necessary internal processes and data flows that are necessary to handle all functionalities of our software, such that all in-flows (sources) and out-flows (sinks) are connected.

Level 2 DFD: DFD level 2 is a further decomposition of DFD level 1. The steps to develop DFD level 2 are extremely similar to those for DFD level 1, but there are some extra requirements: • Each bubble should both be clearly defined and also easy enough to implement and do testing in later stages. • The data flows should be consistent with DFD level 1 and Context Diagram. 4

Data Flow Diagram Layers:Draw data flow diagrams in several nested layers. A single process node on a high level diagram can be expanded to show a more detailed data flow diagram. Draw the context diagram first, followed by various layers of data flow diagrams.

Fig The nesting of data flow layers Advantages of DFDs:• • •

The DFD method is an element of object oriented analysis and is widely used. Use of DFDs promotes quick and relatively easy project code development. DFDs are easy to learn with their few and simple-to-understand symbols. The structure used for designing DFDs is simple, employing English nouns or noun-adjectiveverb constructs.

Disadvantages of DFDs:• • •

DFDs for large systems can become cumbersome, difficult to translate and read, and be time consuming in their construction. Data flow can become confusing to programmers, but DFDs are useless without the prerequisite detail. Different DFD models employ different symbols (circles and rectangles, for example, for entities). 5

EXPERIMENT NO-2. AIM: - Create level 0 DFD using Smart Draw (case study of website development) OBJECTIVE: - Study of Website Development Procedure. HARDWARE REQUIREMENTS:• • • • •

Develop software in either VB or HTML or .NET 2 or JAVA. Microsoft SQL server. Windows 2003 server with Microsoft Internet Information Server (IIS). Application should well commented. Applications should support multiple simultaneous read and write requests from different clients.

SOFTWARE REQUIREMENTS:Platform

-

Windows 2003 server

Front End

-

HTML, CSS, ASP, Macromedia Flash

Tools used

-

Macromedia Flash, Photoshop

Back End

-

SQL server

Software Required

-

Smart draw 6

THEORY:-

• ABSTRACT This document describes the features and timeframe desired for web-based survey software. The software displays multiple questions and answer options and assigns score based on a predefined score chart. The questions, answer options and score will be uploaded using an excel spread sheet.

6

•

GOALS, JUSTIFICATION AND SUCCESS CRITERIA  GOALS

Develop web-based survey software to integrate into an existing .Net 2 application. Display multiple questions per pages as specified by survey administrator, each with two to four answer options and compile a total score based on answer responses.

 JUSTIFICATION The survey software will be utilized to gather information on user habits and obtain feedback on products or services.

 SUCCESS CRITERIA The survey software should display multiple navigable web pages with questions and answers choices. Administrator specifies of question and answers choices that appear on each page. A user is able to select either on answer option or multiple answer choices; this is based on answer response (S-Single or M-Multiple) properties as setup by survey administrator. Each answer response is assigned a score as setup by survey administrator and linked to a URL. The survey administrator can determine if the URL opens in a new window or in the same window. At end of survey a total score is compiled and displayed to user and recorded in a survey database.

•

ROLES  SURVEY USER

A survey user accesses the web based survey and responds to each question by selecting either on or multiple answer responses depending on the question.

 SURVEY ADMINISTRATOR Survey administrator uploads questions, answer choices and scores. Survey administrator determines number of questions per page, edits questions, answers and scores in survey system. Administrator decides what answers choices are selected by default and which questions are allowed multiple answers. Administrator generates usage reports.

7

 SURVEY REQUIREMENTS Each survey page will have a combination of questions and answers in the following format: (Q1 and Q2 are single answer choice questions; Q3 is multiple answer choice questions) Q1 How often do you check you demate account? Answer:

weekly

semimonthly

monthly

Q2 Do you know what HACKING is? Answer:

Yes

No

Q3 Which software you have used to project you computer system from malicious users. Answers:

Anti spy ware Antivirus Firewall IDS

Each survey page (except first and last pages) will have the following buttons Restart survey – on clicking this button the survey restart from first page Previous on clicking this button user goes to previous survey page with answer responses to current page saved in database.

Continue on clicking this button current page answer responses are saved in database and user advances to survey’s next page Survey’s first page will have one button only ‘continue’.

8

SURVEY SAMPLE Survey sample is attached file survey-quiz.xls This file contains. Questions 1. Answer choice selection.

2. ‘S’: User can select only on answer form choices. 3. ‘M’: User can select multiple answers from choices. 4. Possible answers. 5. Each possible answer will have a text response, unless it is a multiple (M) selection answer choice only has one response. Three score levels: Very high risk, High risk and low risk. Three levels are categorized in table below. Score

Risk Level

0-300

Very High Risk

300-600

High Risk

600-900

Low Risk

 ADMIN INTERFACE The admin interface has two functions: Create, Read, Update and Delete (C.RU.D)

9

An administrator is able to make quick changes (correcting typos, editing text and scores, etc) and then update survey system with changes, which are then made live.

 GENERATING USAGE REPORTS In this feature an administrator can generate usage reports, with statistics on which questions got what type of responses, etc (an excel pie/bar chart type report is expected for each question and answer combination), the report can be customized to select data and range of questions. And export facility to export questions, answers, responses, explanations ans scores into a CSV file. •

DATABASE NOTES Design tables, relationships and keys per database schema attached (survey schema.xsd)  PERFORMANCE AND RESPONSE TIME REQUIREMENTS Survey software should be designed to be capable of handling nominal amount of concurrent users and is expected to provide response time between pages not exceeding 3 seconds. Platform dependent and installation requirements. Survey is web based and should be capable of being executed on any browser, internet explorer, Mozilla firefox.

• FEASIBILITY STUDY A feasibility study is carried out to select the best system that meets performance requirements. Feasibility is the determination of whether or not a project is worth doing. The process followed in making this determination is called a feasibility study. This type of study determines if a project can should be taking.

10

Since the feasibility study may lead to the commitment of large resources, it becomes necessary that is should be conducted competently and that no fundamental errors of judgment are made.

 TECHNICAL FEASIBILITY This is concerned with specifying equipment and software that will successfully satisfy the user requirement. The technical needs of the system may 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 location. 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. The proposed system is technically feasible because of following reason: 1. The organization already has server client setup so this system can run in organization. 2. The organization does not require any new package in their computer system as it already has all the required software’s. 3. The organization is already working with the system made in dbase3 and has knowledge about the processes, databases, and expected outputs. The proposed system is to be implemented using COM technology, the server components are to be installed on server and client components on client. All the clients will get response according to the application loads on their terminals.

 OPERATIONAL FEASIBILITY 11

It 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 skill will require? Do the existing staff members have these skills? If not, can they be trained in due course of time?

Such considerations are likely to critically affect eh nature and scope of the eventual recommendations. This feasibility study is carried out by a small group of people who are familiar with information system techniques, who understate the parts of the business that are relevant to the project and are skilled in system analysis and design process. The proposed system is operationally feasible because of following reasons: The organization is already working with the computerized system and has knowledge about functioning and databases. The interactivity of existing system is very poor as each command ahs to be written manually on the system and the proposed system is much faster. The proposed system is better in use and more user friendly as it generates proper messages at run time. The input from the user is much as field like DATA, PRODUCTION, DETAILS, ORDER DETAILS are includes itself by the system.  ECONOMIC FEASIBILITY Economic analysis is the most frequently used technique for evaluating the effectiveness of proposes system. In this we determine the benefits and savings that are expected from a proposed system. In this we determine the benefits and saving that are expected form a proposed system and compare them with cost. It benefits outweigh costs; a decision is taken to design and implement the system. This is an ongoing effort that improves in accuracy at each phases of the system life cycle. The proposed system is financial feasible because of following reasons: 12

1. The cost of system development is nil as a trainee student is developing it. 2. The organization already has server client setup so this system can run in organization so hardware investment is nil. 3. The organization does system is economic as it will reduce the time investment in running the daily transactions.

4. The employees are already working with the old system so cost of learning to work with new system is very low. 5. The system itself will be very much interactive and self explanatory and also contains user manuals to assist operator. 6. No extra cost for salary of operational staff.  SOCIAL FEASIBILITY Social feasibility is a determination of whether a proposed project will be acceptable to the people or not. This determination typically examines the probability of the project being accepted by the group directly affected by the proposed system change. This project is proved to be socially acceptable and thus social feasible.  MANAGEMENT FEASIBILITY It is a determination of whether a proposed project will be acceptable to management. This is also accepted by the management therefore management feasibility is present here.

• DATA FLOW DIAGRAM OF WEBSITE DEVELOPMENT

Loging

Survey Survey system

User Score

Administrator Backend and score

13

Fig Level 0 DFD of Website development

EXPERIMENT NO-3. AIM: - Create level 1 DFD using Smart Draw (case study of website development) OBJECTIVE: - Study of Website Development Procedure. HARDWARE REQUIREMENTS:• • • • •

Develop software in either VB or HTML or .NET 2 or JAVA. Microsoft SQL server. Windows 2003 server with Microsoft Internet Information Server (IIS). Application should well commented. Applications should support multiple simultaneous read and write requests from different clients.

SOFTWARE REQUIREMENTS:Platform

-

Windows 2003 server

Front End

-

HTML, CSS, ASP, Macromedia Flash

Tools used

-

Macromedia Flash, Photoshop

Back End

-

SQL server

Software Required

-

Smart draw 6

THEORY:Level 1 DFD (overview diagram) gives overview of full system. A level 1 DFD depicts the main functional areas of the system under investigation. The level 1 diagram is surrounded by the outline of a process box that represents the boundaries of the system. Level-1 DFD shows the subprocesses of one of the processes in the Level-0 DFD. 14

The level 1 DFD is expanded from the level 0 DFD. This level basically explains the context level bubble in detail. Level 1 DFD gives overview of full system. It identifies major processes and data flows between them. It identifies data stores that are used by the major processes

LEVEL 1 DFD FOR USER

Fig. LEVEL 1 Data Flow Diagram

15

LEVEL 1 DFD FOR ADMINISTRATOR

Fig. LEVEL 1 Data Flow Diagram

16

EXPERIMENT NO-4. AIM: - Create level 2 DFD using Smart Draw (case study of website development) OBJECTIVE: - Study of Website Development Procedure. HARDWARE REQUIREMENTS:• • • • •

Develop software in either VB or HTML or .NET 2 or JAVA. Microsoft SQL server. Windows 2003 server with Microsoft Internet Information Server (IIS). Application should well commented. Applications should support multiple simultaneous read and write requests from different clients.

SOFTWARE REQUIREMENTS:Platform

-

Windows 2003 server

Front End

-

HTML, CSS, ASP, Macromedia Flash

Tools used

-

Macromedia Flash, Photoshop

Back End

-

SQL server

Software Required

-

Smart draw 6

THEORY:DFD level 2 is a further decomposition of DFD level 1. The steps to develop DFD level 2 are extremely similar to those for DFD level 1, but there are some extra requirements: • Each bubble should both be clearly defined and also easy enough to implement and do testing in later stages. • The data flows should be consistent with DFD level 1 and Context Diagram. 17

LEVEL 2 DFD FOR ADMINISTRATOR

18

LEVEL 2 DFD FOR USER

19

EXPERIMENT NO-5. AIM: - Drawing Entity Relationship Diagram (ERD) in Smart Draw (Case study of Website Development)

OBJECTIVE: - Study of Website Development Procedure. HARDWARE REQUIREMENTS:• • • • •

Develop software in either VB or HTML or .NET 2 or JAVA. Microsoft SQL server. Windows 2003 server with Microsoft Internet Information Server (IIS). Application should well commented. Applications should support multiple simultaneous read and write requests from different clients.

SOFTWARE REQUIREMENTS:Platform

-

Windows 2003 server

Front End

-

HTML, CSS, ASP, Macromedia Flash

Tools used

-

Macromedia Flash, Photoshop

Back End

-

SQL server

Software Required

-

Smart draw 6

THEORY:An entity-relationship diagram is a data modeling technique that creates a graphical representation of the entities, and the relationships between entities, within an information system. Entity Relationship Diagrams (ERDs) illustrate the logical structure of databases. An Entity Relationship Diagram (ERD) is a snapshot of data structures. ERDs show entities in a database and relationships between tables within that database. 20

There are three basic elements in ER models:

• Entities are the "things" about which we seek information. • Attributes are the data we collect about the entities. • Relationships provide the structure needed to draw information from multiple entities. The steps involved in creating an ERD are: • • • •

Identify the entities. Determine all significant interactions. Analyze the nature of the interactions. Draw the ERD.

In software engineering, an Entity-Relationship Model (ERM) is an abstract and conceptual representation of data.

 ENTITY RELATIONSHIP DIAGRAM (ERD) NOTATIONS There are a number of conventions for entity-relationship diagrams (ERDs). The classical notation is described in the remainder of this article, and mainly relates to conceptual modeling. There are a range of notations more typically employed in logical and physical database design, such as IDEF1X.Peter Chen developed ERDs in 1976. Since then Charles Bachman and James Martin have added some slight refinements to the basic ERD principles. •

Entity: An entity is an object or concept about which you want to store information. Each entity is represented by a box within the ERD. An entity may be defined as a thing which is recognized as being capable of an independent existence and which can be uniquely identified. An entity is an abstraction from the complexities of some domain. An entity-type is a category. An entity, strictly speaking, is an instance of a given entity-type. There are usually many instances of an entity-type. Because the term entity-type is somewhat cumbersome, most people tend to use the term entity as a synonym for this term. Symbol of entity:-

21

•

Weak entity: A Weak Entity is an entity that cannot be uniquely identified by its attributes alone. Entities that do not have key attributes of their own are called weak entities. Symbol of weak entity:-

•

Relationship: -

Relationship illustrates how two entities share information in the database structure. Relationships illustrate how two entities share information in the database structure. A relationship type is a set of associations among entity types. A relationship or relationship instance is an ordered pair consisting of particular related entities. The degree of a relationship type is the number of entity types that participate. If two entity types participate, the relationship type is binary. A role name indicates the purpose of an entity in a relationship. Symbol of relationship:-

•

Identifying relationship: Relationship between weak entity and owner entity is known as identifying relationship. A weak entity can be identified uniquely only by considering the primary key of another “owner” entity. To be identified, instances of weak entity type require an identifying relationship type that relates them to an identifying entity type. Such relations are displayed by doublediamond nodes. Symbol of identifying relationship:-

22

•

Attribute: Attributes are the properties or characteristics of an entity. Attributes are the properties or characteristics of an entity. Each entity has attributes, or particular properties that describe the entity. Most of the data in a database consists of values of attributes. The set of all possible values of an attribute, such as integers from 0 to 100 for a grade, is the attribute domain. Symbol of attribute:-

•

Key attribute: A key attribute is the unique, distinguishing characteristic of the entity. An attribute of an entity type for which the entity must have a UNIQUE value.

•

Multi valued attribute: A multi valued attribute can have more than one value. For example, an employee entity can have multiple skill values.

•

Composite attribute: A composite attribute consists of a group of values from more than one domain. For example, the Address attribute consists of several domains such as house number, street number, city, country, etc. 23

•

Derived attribute: - A derived attribute is based on another attribute. For example, an employee's monthly salary is based on the employee's annual salary.

•

Total participation of E2 in R: - An entity has to participate in the relation AT LEAST ONCE. Double lines in E/R

•

Cardinality ratio 1:N for E1:E2 in R

24

Entity Relationship Diagram (ERD) of Website Development:-

25

EXPERIMENT NO-6. AIM: - Representing mapping cardinalities and relationships in ER diagram using Smart Draw.

OBJECTIVE: - Study of Website Development Procedure. HARDWARE REQUIREMENTS:• • • • •

Develop software in either VB or HTML or .NET 2 or JAVA. Microsoft SQL server. Windows 2003 server with Microsoft Internet Information Server (IIS). Application should well commented. Applications should support multiple simultaneous read and write requests from different clients.

SOFTWARE REQUIREMENTS:Platform

-

Windows 2003 server

Front End

-

HTML, CSS, ASP, Macromedia Flash

Tools used

-

Macromedia Flash, Photoshop

Back End

-

SQL server

Software Required

-

Smart draw 6

THEORY:A mapping cardinality is a data constraint that specifies how many entities an entity can be related to in a relationship set. A binary relationship set is a relationship set on two entity sets. Mapping cardinalities on binary relationship sets are simplest.

Consider a binary relationship set R on entity sets A and B. There are four possible mapping cardinalities in this case: 26

1. ONE-TO-ONE - an entity in A is related to at most one entity in B, and an entity in B is

related to at most one entity in A.

2. ONE-TO-MANY - an entity in A is related to any number of entities in B, but an entity in B is

related to at most one entity in A.

3. MANY-TO-ONE - an entity in A is related to at most one entity in B, but an entity in B is

related to any number of entities in A.

27

4. MANY-TO-MANY - an entity in A is related to any number of entities in B, but an entity in B is related to any number of entities in A.

 MAPPING CARDINALITY FOR CASE STUDY:

 One to One Relationship:

1 SURVEY

1 RESULT

E V A L U A T IO N

One survey can evaluates only one result at one time. So, therefore one to one relationship is there in survey and result.

 One to Many Relationship:

1 SURVEY

N C O N SIST S O F

T O P IC S

One survey can consist of various topics. So, therefore, one to many relationship obtain in survey and topics.

 Many to One Realtionship: 28

N

Q U E S T IO N S A N D O P T IO N S

1 SURVEY

C O N SIST S O F

Different questions and options can be contain in one survey and therefore, obtain the many to one relationship between questions and survey.  Many to Many Relationship:

N USER

N SURVEY

P A R T IC IP A T E

Different users can participate in different surveys and vice versa and therefore, many to many relationship exist.

 RELATIONSHIPS A relationship is an association that exists between two entities. Most relationships can also be stated inversely. The relationships on an Entity-Relationship Diagram are represented by lines drawn between the entities involved in the association. The name of the relationship is placed either above, below, or beside the line.  Relationship Between Entities: There can be a simple relationship between two entities. For example, user participates in the surveys. Some relationships involve only one entity. For example, Employee reports to Employee: •

Relationship between two entities:1 :M USER

•

1 :M P A R T IC IP A T E

Relationship between One entity:29

SURVEY

R E L A T IO N S H IP 1 :1 E N T IT Y 1 :M

This type of relationship is called a recursive relationship. There can be a number of different relationships between the same two entities. For example: •

Different Relationships Between two Entities:-

1 :M

1 :M

E N T IT Y 1

E N T IT Y 2 1 :M

•

1 :M

Different relationships involving different entities:-

One entity can participate in a number of different relationships involving different entities. For example: 1 :M

E N T IT Y 2

1 :1 1 :M

1 :1

E N T IT Y 1

E N T IT Y 3

1 :1

1 :M

30

E N T IT Y 4

 CHARACTERISTICS OF RELATIONSHIPS A relationship may be depicted in a variety of ways to improve the accuracy of the representation of the real world. The major aspects of a relationship are: •

Naming the Relationship: Place a name for the relationship on the line representing the relationship on the E-R diagram. Use a simple but meaningful action verb (e.g., buys, places, takes) to name the relationship. Assign relationship names that are significant to the business or that are commonly understood in everyday language.

•

Bi-directional Relationships: Whenever possible, use the active form of the verb to name the relationship. Note that all relationships are bi-directional. In one direction, the active form of the verb applies. In the opposite direction, the passive form applies

 RELATIONSHIP TITLE:-

E N T IT Y 1

1 :M

1 :M

R e la t io n s h ip

E N T IT Y 2

By convention, the passive form of the relationship name is not included on the E-R diagram. This helps avoid clutter on the diagram.

31

 RELATIONSHIP DEPENDENCY Types of Relationship Depencies:Three relationship dependencies are possible: 

Mandatory.



Optional.



Contingent.

Relationship dependencies may be of different degrees. Each relationship dependency is illustrated differently.  Mandatory Relationship:A mandatory relationship indicates that for every occurrence of entity A there must exist an entity B, and vice versa.

32

When specifying a relationship as being mandatory one-to-one, you are imposing requirements known as integrity constraints. For example, there is one Project Manager associated with each Project, and each Project Manager is associated with one Project at a time. A Project Manager may not be removed if the removal causes a Project to be without a Project Manager. If a Project Manager must be removed, its corresponding project must also be removed. A Project may not be removed if it leaves a Project Manager without a Project. A new project may be added if it can be managed by an existing Project Manager. If there is no Project Manager to manage the Project, a Project Manager must be added with the addition of a new Project.  Optional Relationship:An optional relationship between two entities indicates that it is not necessary for every entity occurrence to participate in the relationship. In other words, for both entities the minimum number of instances in which each participates, in each instance of the relationship is zero (0). As an example, consider the relationship Man is married to Woman. Both entities may be depicted in an Entity-Relationship Model because they are of interest to the organization. However, not every man, or woman, is necessarily married. In this relationship, if an employee is not married to another employee in the organization, the relationship could not be shown.

The optional relationship is useful for depicting changes over time where relationships may exist one day but not the next. For example, consider the relationship "Employee attends Training Seminar." There is a period of time when an Employee is not attending a Training Seminar or a Training Seminar may not be held.

33

 Contingent Relationship:A contingent relationship represents an association which is mandatory for one of the involved entities, but optional for the other. In other words, for one of the entities the minimum number of instances that it participates in each instance of the relationship is one (1), the mandatory association, and for the other entity the minimum number of instances that it participates in each instance of the relationship is zero (0), the optional association. Contingent relationships may exist due to business rules, such as Project is staffed by Consultant.

In this case, a Project may or may not be staffed by a Consultant. However, if a Consultant is registered in the system, a business rule may state that a Consultant must be associated with a Project.

34

EXPERIMENT NO. 7

AIM : Techniques used in Black Box testing. OBJECTIVE: - Study of techniques of black box testing. HARDWARE REQUIREMENT:•

Develop software in either VB or HTML or .NET 2 or JAVA.

•

Microsoft SQL server.

•

Windows 2003 server with Microsoft Internet Information Server (IIS).

•

Application should well commented.

•

Applications should support multiple simultaneous read and write requests from different clients.

SOFTWARE REQUIREMENT:Platform

-

Windows 2003 server

Front End

-

HTML, CSS, ASP, Macromedia Flash

Tools used

-

Macromedia Flash, Photoshop

Back End

-

SQL server

Software Required

-

Smart draw 6

THEORY:Black box testing is also known as functional testing. A software testing technique whereby the internal structure of the item being tested are not known by the tester .For example, in a black box test on a software designer the tester only knows the inputs and what the expected outcomes should be and not how the program arrives at those outputs .

35

The tester doesn’t ever examine the programming code and doesn’t need any further knowledge of the program other than its specifications. Black box testing is not a type of testing; it instead is a testing strategy, which doesn’t need any knowledge of internal design or code etc. As the name “black box” suggests, no knowledge of internal logic or code structure is required. The base of the black box testing strategy lies in the selection of appropriate data as per functionality and testing it against the functional specifications in order to check for normal and abnormal behavior of the system. In order to implement black box strategy, the tester is needed to be through with the requirement specifications of the system and as user, should know, how the system should behave in response to the particular action. The types of testing under this strategy are totally based on the testing for requirements and functionality of the work product or software application. Black box testing is sometimes also known as “Opaque Testing”, “Functional or Behavioral Testing” and also as “Closed Box Testing”. Black box testing uncovers following types of errors. 1. 2. 3. 4. 5.

Incorrect or missing functions Interface errors External database access Performance errors Initialization and termination errors.

There are essentially the following two main approaches to designing black box test cases. o

Equivalence class partitioning

o

Boundary value analysis



EQUIVALENCE CLASS PARTITIONING

In this approach the domain of the input values to a program is partitioned into a set of equivalence classes. This partitioning is done such that the behavior of the program is similar for every input data belonging to the same equivalence class. The main idea of defining the equivalence class is that testing the code with any one value belonging to an equivalence class is as good as testing the software with any other value belonging to that equivalence class. Equivalence classes for the software can be designed by examining the input data. Some general guidelines for designing the equivalence class are:1. If an input condition specifies a range, one valid and two invalid equivalence classes are defined. 2. If an input condition requires a specific value, then one valid and two invalid equivalence classes are defined.

36

3. If an input condition specifies a member of a set, then one valid and one invalid equivalence class are defined. 4. If an input condition is Boolean, then one valid and one invalid equivalence class are defined. Example : For software that computes the square root of an input integer which can assume values in the range from 1 to 5000, there are three equivalence classes: the set of negative integers, the set of integers in the range of 1 to 5000, and the integers larger than 5000. Therefore, the test cases must include representatives from each of the three equivalence classes and a possible test set can be {-5, 500, 6000}. 

BOUNDARY VALUE ANALYSIS:

Some typical programming errors occur at the boundaries of different equivalence classes of inputs. The reason for such errors is unknown since programmers failed to see the special processing required by the input values that lie at the boundary. It has been observed that programs that work correctly for a set of values in an equivalence class fail on some special values. These values often lie on the boundary of the equivalence class. Test cases that have values on the boundaries of equivalence classes are therefore likely to be error producing so selecting such test cases for those boundaries is the aim of boundary value analysis. In boundary value analysis, we choose input for a test case from an equivalence class, such that the input lies at the edge of the equivalence classes. Boundary values for each equivalence class, including the equivalence classes of the output, should be covered. Boundary value test cases are also called “extreme cases”.Hence, a boundary value test case is a set of input data that lies on the edge or boundary of a class of input data or that generates output that lies at the boundary of a class of output data. In case of ranges, for boundary value analysis it is useful to select boundary elements of the range and an invalid value just beyond the two ends (for the two invalid equivalence classes. For example, if the range is 0.0 <= x <= 1.0, then the test cases are 0.0,1.0for valid inputs and –0.1 and 1.1 for invalid inputs. For boundary value analysis, the following guidelines should be used: 1. For input ranges bounded by a and b, test cases should include values a and b and just above and just below a and b respectively. 2. If an input condition specifies a number of values, test cases should be developed to exercise the minimum and maximum numbers and values just above and below these limits. 3. If internal data structures have prescribed boundaries, a test case should be designed to exercise the data structure at its boundary.

37

Example: For a function that computes the square root of integer values in the range from 1 to 5000, the test cases must include the following values: {0,1,500,6000},

Advantages of Black Box Testing :      

More effective on larger units of code than glass box testing. Tester needs no knowledge of implementation, including specific programming languages. Tester and programmer are independent of each other. Tests are done from a user's point of view. It will help to expose any ambiguities or inconsistencies in the specifications. Test cases can be designed as soon as the specifications are complete.

Disadvantages of Black Box Testing : Only a small number of possible inputs can actually be tested, to test every possible input stream would take nearly forever.   



Without clear and concise specifications, test cases are hard to design. There may be unnecessary repetition of test inputs if the tester is not informed of test cases the programmer has already tried. May leave many program paths untested. Cannot be directed toward specific segments of code which may be very complex. Most testing related research has been directed toward glass box testing.

38

EXPERIMENT NO. 8

AIM : Techniques used in White Box testing. OBJECTIVE: - Study of techniques of

white box testing.

HARDWARE REQUIREMENT:•

Develop software in either VB or HTML or .NET 2 or JAVA.

•

Microsoft SQL server.

•

Windows 2003 server with Microsoft Internet Information Server (IIS).

•

Application should well commented.

•

Applications should support multiple simultaneous read and write requests from different clients.

SOFTWARE REQUIREMENT:Platform

-

Windows 2003 server

Front End

-

HTML, CSS, ASP, Macromedia Flash

Tools used

-

Macromedia Flash, Photoshop

Back End

-

SQL server

Software Required

-

Smart draw 6

THEORY:White box test cases require thorough knowledge of the internal structure of the software. Therefore, it is also known as structural testing. White box testing strategy deals with the internal logic and structure of the code. White box testing is also called as glass, structural, open box or clears box testing. The tests written based on the white box testing strategy incorporate coverage of the code written, branches, path, statements in internal logic of the code etc.

39

Purpose of white box testing is to make sure that • •

Functionality is proper Information on the code coverage

The different approaches to white box testing are explained below:  Statement coverage: The statement coverage methodology aims to design test cases so as to force the execution of every statement in a program at least once. The principle idea behind this methodology is that unless the statement is executed we have no way of determining if an error existing in that statement. In other words the criteria are based on the observations that an error existing in one part of program cannot be discovered if the part of program containing error and generating a failure is not executed. However, the executing a statement and that to for just one input and observing that the programs behaves properly doesn’t guarantee that it will work correctly for all the inputs values. For example: - consider the following program: int compute_gcd(x,y) int x,y; { while (x!=y) if (x > y) then x=x-y; else y=y-x; } return x; By choosing the test set {(x=3, y=3), (x-4, y=3), (x=3, y=4)}, we exercise the program such that all statements are executed atleast once.  Branch coverage: In branch coverage based testing methodology test cases are designed such that different branches are given true or false values in turn. The branch testing guarantees statement coverage and thus is a stronger testing criterion then statement based coverage. 40

For example: int compute_ gcd(x, y) int x, y; { while (x!=y) if (x > y) then x=x-y; else y=y-x; } return x; By choosing the test cases {(x=3, y=3), (x=3, y=2), (x=4, y=3), (x=3, y=4)}all the branches of the program can be executed at least once.  Condition coverage: In this white box testing test cases are designed such that each component of a condition in composite conditional expression is given both true and false values. For example: in conditional expression (c1and c2or c3).c1,c2and c3 are exercised at least once i.e. there are given true or false values. Condition testing is a stronger testing method than the branch testing and branch testing is greater than the statement coverage testing. However for a Boolean expression of ‘n’ variables for condition coverage 2n test cases are required. Therefore a condition coverage based testing technique is practical only if ‘n’ is small.  Path Coverage: Path coverage based testing stratergy requires us to design test cases such that all linearly independent paths in the program are executed atleast once. A linearly independent path is defined in terms of a control flow graph(CFG) , which describes the sequence in which the different instructions of a program get executed .in other words a CFG describes how the flow of control passes through the program. In order to draw the CFG of a program we first number all the statements of a program.

41

For Example:Int compute gcd(x,y) Int x,y; { 1.while (x!=y) 2.if(x>y)then 3.x=x-y; 4.else y=y-x; 5} 6.return x; The different numbered statements served as nodes of the CFG and edge from one node to another exists if the execution of the control statement representing a first node can result in the transfer of control to the other node. A path through the program is a node and edge sequence from the starting node to a terminal node of a CFG of a program. An independent path is any path through the program that introduces atleast one new node that is not included in any other linearly independent path. CFG for the example program above is as follows:

1

2

3

4

5

6

42

Fig Control Flow Diagram

Advantages of White Box Testing :   

As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out which type of input/data can help in testing the application effectively. The other advantage of white box testing is that it helps in optimizing the code It helps in removing the extra lines of code, which can bring in hidden defects.

Disadvantages of White Box Testing :  

As knowledge of code and internal structure is a prerequisite, a skilled tester is needed to carry out this type of testing, which increases the cost. And it is nearly impossible to look into every bit of code to find out hidden errors, which may create problems, resulting in failure of the application.

43

EXPERIMENT NO. 9

AIM : Representing sequence in a structured chart. OBJECTIVE: - To familiarize with the concept of structured charts HARDWARE REQUIREMENT:•

Develop software in either VB or HTML or .NET 2 or JAVA.

•

Microsoft SQL server.

•

Windows 2003 server with Microsoft Internet Information Server (IIS).

•

Application should well commented.

•

Applications should support multiple simultaneous read and write requests from different clients.

SOFTWARE REQUIREMENT:Platform

-

Windows 2003 server

Front End

-

HTML, CSS, ASP, Macromedia Flash

Tools used

-

Macromedia Flash, Photoshop

Back End

-

SQL server

Software Required

-

Smart draw 6

THEORY:Structured software design is arranged hierarchically. Structured software follows rules:

44

•

Modules are arranged hierarchically.

• • • •

There is only one root (i.e., top level) module. Execution begins with the root module. Program control must enter a module at its entry point and leave at its exit point. Control returns to the calling module when the lower level module completes execution.

 DESCRIPTION OF A MODULE: Logically, a module is one problem-related task that the program performs, such as Create Invoice or Validate Customer Request. Physically, a module is implemented as a sequence of programming instructions bounded by an entry point and an exit point.

 COMMON MODULES: There are two categories of common modules: • •

system (e.g., I/O handlers, locking), application (e.g., edits, calculations).

Some common modules (e.g., security, navigation, audit trails, and help) do not fall clearly in either category. These modules may be common to more than one application but are not system level modules. System common modules should be defined as part of the preliminary design. Application common modules should be defined as early as possible but many may not be identified until detailed design.

 CONSTRUCTS OF STRUCTURED SOFTWARE DESIGN:

Tree-structure diagrams are used to illustrate modules that follow the rules of structured software design. A tree-structure can be drawn as a set of blocks, for example, a Structure Chart, or a set of brackets, such as an Action Diagram.

When designing structured software, three basic constructs are represented:

 Sequence - items are executed from top to bottom.

45

 Repetition - a set of operations is repeated. repetition test.

The repetition is terminated based on the

 Condition - a set of operations are executed only if a certain condition or CASE statement applies.

46

RESULT: This experiment introduces the concept of structured charts.

47

EXPERIMENT NO. 10

AIM : Creating modules in a structured chart. OBJECTIVE: - To familiarize with the concept of structured charts HARDWARE REQUIREMENT:•

Develop software in either VB or HTML or .NET 2 or JAVA.

•

Microsoft SQL server.

•

Windows 2003 server with Microsoft Internet Information Server (IIS).

•

Application should well commented.

•

Applications should support multiple simultaneous read and write requests from different clients.

SOFTWARE REQUIREMENT:Platform

-

Windows 2003 server

Front End

-

HTML, CSS, ASP, Macromedia Flash

Tools used

-

Macromedia Flash, Photoshop

Back End

-

SQL server

Software Required

-

Smart draw 6

THEORY:A rectangle is used to represent a module on a Structure Chart. The module name is written inside the rectangle. Other than the module name, the Structure Chart gives no information about the internals of the module.

48

 MODULE NAMES AND NUMERICAL IDENTIFIERS: Each module must have a module name. Module names should consist of a transitive (or action) verb and an object noun. Module names and numerical identifiers may be taken directly from corresponding process names on Data Flow Diagrams or other process charts. The name of the module and the numerical identifier is written inside the module rectangle. Other than the module name and number, no other information is provided about the internals of the module.

 EXISTING MODULE: Existing modules may be shown on a Structure Chart. An existing module is represented by double vertical lines.

 UNFACTORING SYMBOL:

An unfactoring symbol is a construct on a Structure Chart that indicates the module will not be a module on its own but will be lines of code in the parent module. An unfactoring symbol is represented with a flat rectangle on top of the module that will not be a module when the program is developed.

49

An unfactoring symbol reduces factoring without having to redraw the Structure Chart. Use an unfactoring symbol when a module that is too small to exist on its own has been included on the Structure Chart. The module may exist because factoring was taken too far or it may be shown to make the chart easier to understand. (Factoring is the separation of a process contained as code in one module into a new module of its own). RESULT: This experiment introduces the concept of creating modules in structured charts

50