Se Practical File

Experiment No:1

Aim:Introduction to SDLC

System Development Life cycle (SDLC)What is a SDLC and why do we need that?

System - an organized collection of independent tasks and processes that is designed to work together in order to accomplish specific objectives. The processes and tasks typically receive input(s) from and provide output(s) to other processes and tasks and even other systems. The tasks and processes may or may not be supported by automation

SDLC refers to a methodology for developing systems. It provides a consistent framework of tasks and deliverables needed to develop systems. The SDLC methodology may be condensed to include only those activities appropriate for a particular project, whether the system is automated or manual, whether it is a new system, or an enhancement to existing systems. The SDLC methodology tracks a project from an idea developed by the user, through a feasibility study, systems analysis and design, programming, pilot testing, implementation, and post-implementation analysis. Documentation developed during the project development is used in the future when the system is reassessed for its continuation, modification, or deletion.

SDLC Phases

Phases in SDLC are Planning, Analysis, Design, Implementation, and Maintenance/Sustainment/Staging

Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.

Systems analysis, requirements definition: Refines project goals into defined functions and operation of

1

©© 2005 by Prentice Hall2005 by Prentice Hall1-11

SDLC Planning Phase

Identify, analyze, prioritize, and arrange IS needs

plication. Analyzes end-user information needs.

2

©© 2005 by Prentice Hall2005 by Prentice Hall1-12

SDLC Analysis Phase

Study and structure system requirements

Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudo code and other documentation.

3

Convert recommended solution to system specifications

Logical design: functional features described independently of computer platform

Physical design: logical specifications transformed to technology-specific details

Implementation (Development): The real code is written here.

Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.

Acceptance, installation, deployment: The final stage of initial develop-ment, where the software is put into production and runs actual business.

Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more.

4

Code, test, install, and support the information system

Systematically repair and improve the information system

Products and Deliverables

5

Types of SDLC models

Once upon a time, software development consisted of a programmer writing code to solve a problem or automate a procedure. Nowadays, systems are so big and complex that teams of architects, analysts, programmers, testers and users must work together to create the millions of lines of custom-written code that drive our enterprise

Waterfall ModelThe oldest of these, and the best known, is the waterfall: a sequence of stages in which the output of eachstage becomes the input for the next. These stages can be characterized and divided up

6

in different ways, including the following:

The waterfall model is well understood, but it's not as useful as it once was. The prob-lem is that the waterfall model assumes that the only role for users is in specifying re-quirements, and that all requirements can be specified in advance. Unfortunately, re-quirements grow and change throughout the process and beyond, calling for consider-able feedback and iterative consultation. Thus many other SDLC models have been de-veloped.

7

To manage this, a number of system development life cycle (SDLC) models have been created: waterfall, spiral, rapid prototyping, RUP (Rational Unified Process) and incremental etc.

6/3/2005 Page 4

Life Cycle Models

One description of a product life cycle may not be adequate. Therefore, the organization may define a set

of approved product life-cycle models.

Waterfall

PrelDsgn

RqtsDefn

Impl I&T O&SDtlDsgn

System A

Determine objectives,alternatives,constraints.

Plan next phase.

Risk/Analysis

Prototype

O&SAT

I&T

Unit Test

Build

SpiralDevelop, verify next levelproduct.

Incremental

SystemRqtsDefn

PrelDsgn

RqtsDefn

Impl I&T O&SDtlDsgn

PrelDsgn

RqtsDefn

Impl I&T O&SDtlDsgn

PrelDsgn

RqtsDefn

Impl I&T O&SDtlDsgn

Part 1

Part 2 (+Part 1)

System AO&SFinalSys I&T

Part 3 (+Part 1+ Part 2)

8

Spiral model

The spiral model emphasizes the need to go back and reiterate earlier stages a number of times as the project progresses. It's actually a series of short waterfall cycles, each producing an early prototype representing a part of the entire project.

This approach helps demonstrate a proof of concept early in the cycle, and it more accurately reflects the disorderly, even chaotic evolution of technology.

Rapid Prototyping - In the rapid prototyping (sometimes called rapid application development) model, initial emphasis is on creating a prototype that looks and acts like the desired product in order to test its usefulness. The prototype is an essential part of the requirements determination phase, and may be created using tools different from those used for the final product. Once the prototype is approved, it is discarded and the "real" software is written.

9

Incremental

The incremental model divides the product into builds, where sections of the project are created and tested separately. This approach will likely find errors in user requirements quickly, since user feedback is solicited for each stage and because code is tested sooner after it's written.

Iterative models

By definition have an iterative component to the systems development. It allows the de-veloper to take a small segment of the application and develop it in a fashion that, at each recursion, the application is improved. Each of the three main sections: require-ments definition, system design, and coding and testing are improved with each cycle through the process.

Rational Unified Process

10

In its simplest form, RUP consists of some fundamental workflows: Business Engineering: Understanding the needs of the business. Requirements: Translating business need into the behaviors of an automated sys-

tem. Analysis and Design: Translating requirements into software architecture. Implementation: Creating software that fits within the architecture and has the

required behaviors. Test: Ensuring that the required behaviors are correct, and that all required be-

haviors are present. Configuration and change management: Keeping track of all the different ver-

sions of all the work products. Project Management: Managing schedules and resources. Environment: Setting up and maintaining the development environment. Deployment: Everything needed to roll out the project.

Experiment No:- 2

11

Aim:Introduction to Structured Analysis and its Tools

What is Structured Analysis?The aim of the structured analysis is to transform a textual problem into a graphical model. It is used to carry out the top to down decomposition of the set of high level functions depicted in the problem description and to represent them graphically. During structured analysis functional decomposition of the system is achieved i.e each function that the system performs is analysed and is decomposed into more detailed function.

Structured analysis focuses on specifying what the system or application are required to do. It does not state how the requirements should be accomplished or how the application should be implemented. Rather, it allows individuals to see logical elements (what the system should do) apart from the physical components it uses (computers, terminals, storage systems, etc.). Later a physical design can be developed that will be effective for the situation in which it is to be used. Structured Analysis is to organize the tasks associated with requirements determination to provide an accurate and complete understanding of the current situation.

Structured analysis (Organized Set of Activities)

1. Organize the requirements determination process, beginning with documentation of the existing system. 2. The process is organized in such a way that it attempts to include all relevant details that describe the current system.3. It also makes it easy to verify that the relevant details have not been omitted. 4. The identification of requirements will be similar among individual analyst and will include the best solutions and strategies for systems development opportunities. 5. Working papers are produced to document the existing and proposed systems are effective communication devices.

Objectives of structured system development

Improvements in communication: Working documentation should enable im-provement in communication between the users and the analyst. Graphics modeling should be used whenever possible. Ensure the maintainability of the system to be analyzed: Individual analysts em-ploying this method are able to deliver similar requirements specification, solutions and strategies for the development of the system. Useful tools for representing the system: Tools used should assist both the user and the analyst to differentiate between the logical and the physical consideration. The users must be able to identify easily if the there is incomplete information. Must be able to effectively partition a complex problem: Through the use of structured development, the developers must be able to partition a complex system to smaller more manageable components.

12

There are several tools that helps in the structured analysis of the system:

Data flow diagram ( DFD ):

A data flow diagram (DFD) is a graphical representation normally designed by a system analyst and is used as a reference point by the programmer which portrays the "flow" of data through an information system. It is primarily used for the visualization of data processing for the structured design of an information system. It is common practice for a database designer to begin the process by drawing a context-level DFD, which shows the interaction between the system and outside entities. This context-level DFD is then "exploded" to show more detail of the system that is being modeled. A DFD also known as a “bubble chart” has the purpose of clarifying system requirements and identifying major transformations that will become programs in system design. So, it is the starting point of the design phase that functionally decomposes the requirements specifications down to the lowest level of detail. A DFD consists of series of bubbles join by the data flows in the system.

Data flow diagrams have the objective of avoiding the cost of:

user/developer misunderstanding of a system, resulting in a need to redo systems or in not using the system. having to start documentation from scratch when the physical system changes since the logical system, WHAT gets done, often remains the same when technology changes. systems inefficiencies because a system gets "computerized" before it gets "system-atized". being unable to evaluate system project boundaries or degree of automation, result-ing in a project of inappropriate scope.

Data flow diagrams can be used to provide a clear representation of any business function. The technique starts with an overall picture of the business and continues by analysing each of the functional areas of interest. This analysis can be carried out to precisely the level of detail required. The technique exploits a method called top-down expansion to conduct the analysis in a targeted way.

The result is a series of diagrams that represent the business activities in a way that is clear and easy to communicate. A business model comprises one or more data flow diagrams (also known as business process diagrams). Initially a context diagram is drawn, which is a simple representation of the entire system under investigation. This is followed by a level 1 diagram; which provides an overview of the major functional areas of the business. Using the context diagram together with additional information from the area of interest, the level 1 diagram can then be drawn.

The level 1 diagram identifies the major business processes at a high level and any of these processes can then be analysed further - giving rise to a corresponding level 2-business process diagram. This process of more detailed analysis can then continue –

13

through level 3, 4 and so on. However, most investigations will stop at level 2 and it is very unusual to go beyond a level 3 diagrams. Identifying the existing business processes, using a technique like data flow diagrams, is an essential precursor to business process re-engineering, migration to new technology, or refinement of an existing business process. However, the level of detail required will depend on the type of change being considered.

Data Flow Diagrams – Diagram Notation

There are only five symbols that are used in the drawing of business process diagrams (data flow diagrams). These are now explained, together with the rules that apply to them.

Figure A: Banking Process

This above diagram represents a banking process, which maintains customer accounts. In this example, customers can withdraw or deposit cash, request information about their account or update their account details. The five different symbols used in this example represent the full set of symbols required to draw any business process diagram.

External Entity

An external entity is a source or destination of a data flow, which is outside the area of study. Only those entities, which originate or receive data, are represented on a business process diagram. The symbol used is an oval containing a meaningful and unique identifier.

Process

14

A process shows a transformation or manipulation of data flows within the system. The symbol used is a rectangular box, which contains 3 descriptive elements: Firstly an identification number appears in the upper left hand corner. This is allocated arbitrarily at the top level and serves as a unique reference. Secondly, a location appears to the right of the identifier and describes where in the system the process takes place. This may, for example, be a department or a piece of hardware. Finally, a descriptive title is placed in the centre of the box. This should be a simple imperative sentence with a specific verb, for example 'maintain customer records' or 'find driver'.

Data Flow

A data flow shows the flow of information from its source to its destination. A data flow is represented by a line, with arrowheads showing the direction of flow. Information always flows to or from a process and may be written, verbal or electronic. Each data flow may be referenced by the processes or data stores at its head and tail, or by a description of its contents.

Data Store

A data store is a holding place for information within the system: It is represented by an open ended narrow rectangle. Data stores may be long-term files such as sales ledgers, or may be short-term accumulations: for example batches of documents that are waiting to be processed. Each data store should be given a reference followed by an arbitrary number.

Resource Flow

A resource flow shows the flow of any physical material from its source to its destination. For this reason they are sometimes referred to as physical flows. The

15

physical material in question should be given a meaningful name. Resource flows are usually restricted to early, high-level diagrams and are used when a description of the physical flow of materials is considered to be important to help the analysis.

Data Flow Diagrams – The Rules

External Entities: It is normal for all the information represented within a system to have been obtained from, and/or to be passed onto, an external source or recipient. These external entities may be duplicated on a diagram, to avoid crossing data flow lines. Where they are duplicated a stripe is drawn across the left hand corner, like this. The addition of a lowercase letter to each entity on the diagram is a good way to uniquely identify them.

Processes: When naming processes, avoid glossing over them, without really understanding their role. Indications that this has been done are the use of vague terms in the descriptive title area - like 'process' or 'update'. The most important thing to remember is that the description must be meaningful to whoever will be using the diagram.

Data Flows: Double-headed arrows can be used (to show two-way flows) on all but bottom level diagrams. Furthermore, in common with most of the other symbols used, a data flow at a particular level of a diagram may be decomposed to multiple data flows at lower levels.

Data Stores: Each store should be given a reference letter, followed by an arbitrary number.

These reference letters are allocated as follows:

'D' - indicates a permanent computer file.'M' - indicates a manual file. 'T' - indicates a transient store, one that is deleted after processing.

In order to avoid complex flows, the same data store may be drawn several times on a diagram. Multiple instances of the same data store are indicated by a double vertical bar on their left hand edge.

Advantages

Represents data flows May be used at high or low level of analysis. For instance, if the DRE is low during analysis and design, it means you should spend time improving the way you conduct formal technical reviews. Provides good system documentation.

16

Process bubbles can be hierarchically decomposed into sub-DFDs; the inputs and outputs must match at all levels of decomposition, so the design has validation.

Disadvantages

Weak in its display of input and output details.

Data Dictionary

It is a structured repository of data. Although we give descriptive names to the data flows, process and data stores in a DFD, it does not give the details. Hence to keep the details of the contents of data flows, process and data stores we also require a Data Dictionary. This is a structured repository of data. It clearly documents the list of contents of all data flows, processes and data stores.

The three classes to be defined are:

Data Elements: - this is the smallest unit of data. Further decomposition is not possible.Data Structure: - this is a group of Data Elements which together form as a unit in a data structure.Data flows and Data stores: - data flows are data structures in motion. Data Stores are data structures in store. (Data structures in a data store - a data store is a location where data structures are temporarily located.)

Data elements can describe files. Data flow, or processes. For example, suppose you want to print vendor’s name and address at the bottom of a cheque. The data dictionary might define vendor’s name and address as follows:

Vendor Name and Address = Vendor name + Street + City + State + Pin + Phone + Fax + e-mail

This definition becomes a part of the data dictionary that ultimately will list all key terms used to describe various data flows and the files.

Four Rules for Data Dictionary:

1. Words should be defined to stand for what they mean and not the variable names by which they may be described in the programs; use CLIENT_NAME not ABCDZX or COD34.

2. Each word must be unique; we cannot have definitions of the same client name.

3. Aliases, or synonyms, are allowed when two or more entries show the same meaning; vendor number may also call a customer number. However, aliases should be used only when absolutely necessary.

17

4. Self-defining words should not be decomposed.

Advantages

May be used at high or low level of analysis. Provides good system documentation at granular level.

Disadvantages

Does not provide details.

Structured English

Structured English is a way of describing the flow of a process. (It is also used in pro-gramming to develop the requirements of the programme prior to writing the code. In this instance it is referred to as "Pseudo-code".) Most programming languages allow the programmer to insert notes within the code. These notes are purely remarks to remind the programmer why some programming styles were adopted or the purpose of certain variables, they do not play any part in the programme. Similarly in Structured English "Comments" are allowed. The purpose of a structured English business process defini-tion language is to describe a process in unambiguous terms that can be easily read and understood by a non-technical business user.

we can develop our own structured English style that suits our company. Some good style point to follow is:

• Use uppercase for keywords and lower case for everything else. This ensures that the logical structure of the process is easily visible.

• Use indentation to reinforce the logical structure of the process. • Keep the description high-level.

Structured English is a language and syntax, based on the relative strengths of structured programming and natural English, for specifying the underlying logic of elementary processes on DFDs.

The two building blocks of Structured English are

1) structured logic or instructions organized into nested or grouped procedures, and

2) simple English statements such as add, multiply, move, etc. (strong, active, specific verbs)

Five conventions to follow when using Structured English:

1. Express all logic in terms of sequential structures, decision structures, or iterations.

2. Use and capitalize accepted keywords such as: IF, THEN, ELSE, DO, DO WHILE,

18

DO UNTIL, PERFORM

3. Indent blocks of statements to show their hierarchy (nesting) clearly.

4. When words or phrases have been defined in the Data Dictionary, underline those words or phrases to indicate that they have a specialized, reserved meaning.

5. Be careful when using "and" and "or" as well as "greater than" and "greater than or equal to" and other logical comparisons.

A process will follow sequentially but at times a selection needs to be made or a repetitive condition (called "ITERATION”) is required.

SELECTION

Selection uses terms such as:

IF...THEN...ELSE.........ENDIF

An IF statement expects a TRUE or False (YES or NO) answer. If a choice between more than two options is required then a number of IF statements is required, these can be stacked inside each other if required and each if statement needs to be terminated with an ENDIF statement. This process can become rather messy and a tidier way is to use the CASE statement.

Example Making a cup of tea

Put teabag into cup Boil kettle Pour boiling water into cup IF weak tea is required THEN Wait 20 seconds ELSE Wait 2 minutes ENDIF Remove teabag from cup IF white tea is required THEN Add milk ENDIF If sweetened tea is required THEN Add sugar ENDIF Stir

ITERATION

Iteration is sometimes called a "DO LOOP". Iteration will be repeated until an expected

19

condition is met. Iteration uses terms such as: DO.... REPEAT...DO UNTIL

Structured English is a useful way of specifying procedural rules with a natural order. In situations where the rules are non-procedural, without a natural order, a decision table is more suitable.

Decision Tables

Decision Tables and Decision Trees were developed long before the widespread use of computers. They not only isolate many conditions and possible actions, but they help ensure that nothing has overlooked.

`A decision table is a table/chart composed of rows and columns, separated into four separate quadrants/sections.

Conditions Condition Alternatives

Actions Action Entries

The upper left quadrant contains the conditions. The upper right quadrant contains the condition rules of alternatives. The lower left quadrant contains the actions to be taken and the lower right quadrant contains the action rules.

Decision Tables are useful when complex combinations of conditions, actions, and rules are found or you require a method that effectively avoids impossible situations, redundancies, and contradictions. Decision Trees are useful when the sequence of conditions and actions is critical or not every condition is relevant to every action.

In order to build decision tables, you need to determine the maximum size of the table, eliminate any impossible situations, inconsistencies, or redundancies, and simplify the table as much as possible. The following steps provide offer some guidelines to developing decision tables:

1. Determine the number of conditions that may affect the decision. Combine rows that overlap, for example, conditions that are mutually exclusive. The number of conditions becomes the number of rows in the top half of the decision table.

2. Determine the number of possible actions that can be taken. This becomes the number of rows in the lower half of the decision table.

3. Determine the number of condition alternatives for each condition. In the simplest form of decision table, there would be two alternatives (Y or N) for each condition; you will nearly always being dealing with two. In an extended-entry table, there may be many alternatives for each condition.

4. Calculate the maximum number of columns in the decision table by multiplying the

20

number of alternatives for each condition. If there were four conditions and two alternatives (Y or N) for each of the conditions, there would be sixteen possibilities as follows:

2 x 2 x 2 x 2 = 16 possibilities

5. Fill in the condition alternatives. Start with the first condition and divide the number of columns by the number of alternatives for that condition. In the foregoing example, there are sixteen columns and two alternatives (Y and N), so sixteen divided by two is eight. Then choose one of the alternatives and write Y in all of the eight columns. Finish by writing N in the remaining eight columns as follows:

Condition 1 YYYYYYYYNNNNNNNN

Repeat this for each condition using a subset of the table:

Y Y Y Y Y Y Y Y N N N N N N N NY Y Y Y N N N NY Y N NY N

and continue the pattern for each condition, this will give all possible combinations:

CONDITION 1 Y Y Y Y Y Y Y Y N N N N N N N N

CONDITION 2 Y Y Y Y N N N N Y Y Y Y N N N N

CONDITION 3 Y Y N N Y Y N N Y Y N N Y Y N N

CONDITION 4 Y N Y N Y N Y N Y N Y N Y N Y N

6. Complete the table by inserting an X where rules suggest certain actions.

7. Combine rules where it is apparent that an alternative does not make a difference in the outcome; for example:

CONDITION 1 Y YCONDITION 2 Y NACTION 1 X X

Can be expressed as:

CONDITION 1 YCONDITION 2 -ACTION 1 X

21

The dash (-) signifies that condition 2 can be either Y or N and action will still be taken.

8. Check the table for any impossible situations, contradictions, and redundancies.

9. Rearrange the conditions and actions (or even rules) to make the decision table more understandable.

Example

The limited-entry decision table is the simplest to describe. The condition alternatives are simple boolean values, and the action entries are check-marks, representing which of the actions in a given column are to be performed.

A technical support company writes a decision table to diagnose printer problems based upon symptoms described to them over the phone from their clients.

Printer troubleshooterRULES

CONDITIONS

PRINTER DOES NOT PRINT

Y Y Y Y N N N N

A RED LIGHT IS FLASHING

Y Y N N Y Y N N

PRINTER IS UNRECOGNIZED

Y N Y N Y N Y N

ACTIONS

CHECK THE POWER CABLE

X

CHECK THE COMPUTER-

PRINTER CABLEX X

ENSURE PRINTER

SOFTWARE INSTALLED

X X X X

CHECK/REPLACE INK

X X X X

Of course, this is just a simple example (and it does not necessarily correspond to the reality of printer troubleshooting), but even so, it demonstrates how decision tables can scale to several conditions with many possibilities.

Decision Trees At times, dialogue tree is too specific for design teams to work with. What they prefer is an easier-to-follow mapping of a complex design. This mapping should branch points and forks, but not the details of the user dialogue. A decision tree helps to show the paths that are possible in a design following an action or decision by user.

A decision tree takes as input an object or situation described by a set of properties, and

22

outputs a yes/no decision. Decision trees therefore represent Boolean functions. Functions with a larger range of outputs can also be represented

Four major steps in building Decision Trees:

1. Identify the conditions

2. Identify the outcomes (condition alternatives) for each decision

3. Identify the actions

4. Identify the rules.

In many problems chance (or probability) plays an important role. Decision analysis is the general name that is given to techniques for analyzing problems containing risk/uncertainty/probabilities. Decision trees are one specific decision analysis technique and we will illustrate the technique by use of an example.

A decision Tree consists of 3 types of nodes:-1. Decision nodes - commonly represented by squares2. Chance nodes - represented by circles3. End nodes - represented by triangles

Decision nodes represent points at which the company has to make a choice of one alternative from a number of possible alternatives e.g. at the first decision node the company has to choose one of the two alternatives "drop M997" or "test market M997".

Chance nodes represent points at which chance, or probability, plays a dominant role and reflect alternatives over which the company has (effectively) no control.

Terminal nodes represent the ends of paths from left to right through the decision tree.

23

Advantages

Amongst decision support tools, decision trees (and influence diagrams) have several advantages:Decision trees: Are simple to understand and interpret . People are able to understand de-cision tree models after a brief explanation. Have value even with little hard data . Important insights can be generated based on experts describing a situation (its alternatives, probabilities, and costs) and their preferences for outcomes. Use a white box model . If a given result is provided by a model, the explana-tion for the result is easily replicated by simple math. Can be combined with other decision techniques .

24

FLOWCHARTS

A flowchart is common type of chart, that represents an algorithm or process, showing the steps as boxes of various kinds, and their order by connecting these with poo. Flowcharts are used in analyzing, designing, documenting or managing a process or program in various fields.

Flowcharts are used in designing and documenting complex processes. Like other types of diagram, they help visualize what is going on and thereby help the viewer to understand a process, and perhaps also find flaws, bottlenecks, and other less-obvious features within it. There are many different types of flowcharts, and each type has its own repertoire of boxes and notational conventions. The two most common types of boxes in a flowchart are:

a processing step, usually called activity, and denoted as a rectangular box a decision, usually denoted as a diamond.

Flowchart allows the author to locate the responsibility for performing an action or making a decision correctly, showing the responsibility of each organizational unit for different parts of a single process.

SymbolsA typical flowchart may have the following kinds of symbols:

Start and end symbols Represented as lozenges, ovals or rounded rectangles, usually containing the word "Start" or "End", or another phrase signaling the start or end of a process, such as "submit enquiry" or "receive product".

Arrows Showing what's called "flow of control" in computer science. An arrow coming from one symbol and ending at another symbol represents that control passes to the symbol the arrow points to.

Processing steps Represented as rectangles. Examples: "Add 1 to X"; "replace identified part"; "save changes" or similar.

Input/Output Represented as a parallelogram. Examples: Get X from the user; display X.

Conditional or decision Represented as a diamond (rhombus). These typically contain a Yes/No question or True/False test. This symbol is unique in that it has two arrows coming out of it, usually

25

from the bottom point and right point, one corresponding to Yes or True, and one corresponding to No or False. The arrows should always be labeled. More than two arrows can be used, but this is normally a clear indicator that a complex decision is being taken, in which case it may need to be broken-down further, or replaced with the "pre-defined process" symbol.

A number of other symbols that have less universal currency, such as: A Document represented as a rectangle with a wavy base; A Manual input represented by parallelogram, with the top irregularly sloping up from left to right. An example would be to signify data-entry from a form; A Manual operation represented by a trapezoid with the longest parallel side at the top, to represent an operation or adjustment to process that can only be made manually. A Data File represented by a cylinder

Flowcharts may contain other symbols, such as connectors, usually represented as circles, to represent converging paths in the flow chart. Circles will have more than one arrow coming into them but only one going out. Some flow charts may just have an arrow point to another arrow instead. These are useful to represent an iterative process.

EXAMPLE

ENTITY RELATIONSHIP DIAGRAMS

Entity Relationship Diagrams (ERDs) illustrate the logical structure of databases. An entity-relationship (ER) diagram is a specialized graphic that illustrates the interrelationships between entities in a database. ER diagrams often use symbols to represent three different types of information. Boxes are commonly used to represent entities. Diamonds are normally used to represent relationships and ovals are used to represent attributes.

26

Entity Relationship Diagram NotationsEntity

An entity is an object or concept about which you want to store information.

Weak EntityAttributes are the properties or characteristics of an entity.

Key attributeA key attribute is the unique, distinguishing characteristic of the entity. For

example, an employee's social security number might be the employee's key attribute.

Multivalued attributeA multivalued attribute can have more than one value. For example, an

employee entity can have multiple skill values.

Derived attributeA derived attribute is based on another attribute. For example, an employee's

monthly salary is based on the employee's annual salary.

27

RelationshipsRelationships illustrate how two entities share information in the database

structure.

CardinalityCardinality specifies how many instances of an entity relate to one instance of

another entity.Ordinality is also closely linked to cardinality. While cardinality specifies the

occurences of a relationship, ordinality describes the relationship as either mandatory or optional. In other words, cardinality specifies the maximum number of relationships and ordinality specifies the absolute minimum number of relationships.

Recursive relationshipIn some cases, entities can be self-linked. For example, employees can supervise

other employees.

\

28

Experiment No 3

Aim:Case Study of Super Market Prize Scheme

INTRODUCTION TO THE SYSTEM: A Supermarket needs to develop fol-

lowing software to encourage regular customers. For this the customer needs to supply

his residence address, telephone number and the driving license number. Each customer

who registers for this scheme is assigned a unique customer number (CN) by the com-

puter. A customer can present his CN to the check out staff when he makes any pur-

chase. In this case, the value of his purchase is credited against his CN.

Figure - 1 Context Level DFD

At the end of each year, the super market awards surprise gift to 10 customers who

make the highest total purchase over the year. Also it awards a 22 carat gold coin to

every customer who purchases exceeds Rs. 10,000/- .The entries against the CN are

reset on the last day of every year after the prize winners’ lists are generated.

29

Figure - 2 Level 1 DFD

30


DATA DICTIONARY:

Data dictionary in its simplest form, the data dictionary is only a collection of data

element definitions, according to descriptions below. More advanced data dictionary

contains database schema with reference keys, still more advanced data dictionary

contains entity-relationship model of the data elements or objects. The term "data

element" is the same concept as "data object" or "object" in some database texts.

Data dictionary consists of the following :

1. DATA ELEMENT DEFINITIONS :

Data element definitions may be independent of table definitions or a part of each table

definition

Data element number

Data element number is used in the technical documents.

Data element name (caption)

commonly agreed, unique data element name from the application domain. This

is the real life name of this data element.

Short description

Description of the element in the application domain.

Security classification of the data element

Organization-specific security classification level or possible restrictions on use.

This may contain technical links to security systems.

Related data elements

List of closely related data element names when the relation is important.

31

Field name(s)

Field names are the names used for this element in computer programs and data-

base schemas. These are the technical names, often limited by the programming

languages and systems.

Code format

Data type (characters, numeric, etc.), size and, if needed, special representation.

Common programming language notation, input masks, etc. can be used.

Null value allowed

Null or non-existing data value may be or may not be allowed for an element.

Element with possible null values needs special considerations in reports and

may cause problems, if used as a key.

Default value

Data element may have a default value. Default value may be a variable, like

current date and time of the day (DoD).

Element coding (allowed values) and intra-element validation details or ref -

erence to other documents

Explanation of coding (code tables, etc.) and validation rules when validating

this element alone in the application domain.

Inter-element validation details or reference to other documents

Validation rules between this element and other elements in the data dictionary.

Database table references

Reference to tables the element is used and the role of the element in each table.

Special indication when the data element is the key for the table or a part of the

key.

32

Definitions and references needed to understand the meaning of the element

Short application domain definitions and references to other documents needed

to understand the meaning and use of the data element.

Source of the data in the element

Short description in application domain terms, where the data is coming. Rules

used in calculations producing the element values are usually written here.

Validity dates for the data element definition

Validity dates, start and possible end dates, when the element is or was used.

There may be several time periods the element has been used.

History references

Date when the element was defined in present form, references to supersede ele-

ments, etc.

External references

References to books, other documents, laws, etc.

Version of the data element document

Version number or other indicator. This may include formal version control or

configuration management references, but such references may be hidden, de-

pending on the system used.

Date of the data element document

writing date of this version of the data element document.

Quality control references

Organization-specific quality control endorsements, dates, etc.

33

Data element notes

Short notes not included in above parts.

2. TABLE DEFINITIONS :

Table definition is usually available with SQL command help table

name

Table name

Table owner or database name

List of data element (column) names and details

Key order for all the elements, which are possible keys

Possible information on indexes

Possible information on table organization

Technical table organization, like hash, heap, B+ -tree, AVL -tree, ISAM, etc.

may be in the table definition.

Duplicate rows allowed or not allowed

Possible detailed data element list with complete data element definitions

Possible data on the current contents of the table

the size of the table and similar site specific information may be kept with the ta-

ble definition.

Security classification of the table

Security classification of the table is usually same or higher than its elements.

However, there may be views accessing parts of the table with lower security.

3. DATABASE SCHEMA:

Database schema is usually graphical presentation of the whole database. Tables are

connected with external keys and key columns. When accessing data from several

tables, database schema will be needed in order to find joining data elements and in

complex cases to find proper intermediate tables. Some database products use the

schema to join the tables automatically.

4. ENTITY-RELATIONSHIP MODEL OF DATA:

34

Entity-relationship model is database analysis and design tool. It lists real-life

application entities, attributes of entities and relationships amongst entities. The type of

each relationship is also indicated. Entity-relationship model is represented in graphical

form.

5. DATABASE SECURITY MODEL :

Database security model associates users, groups of users or applications (programs)

with database access rights.

PROBLEM: DATA DICTIONARY FOR SUPER MARKET PRIZE

SCHEME

Address : name + house# + street# + city + pin

sales-details : { item + amount } * + CN

CN : integer

customer–data : { address + CN } *

sales – info : { sales – details } *

winner–list : surprise – gift – winner-list + gold – coin – winner – list

surprise – gift – winner –list : { address + CN }

sold – coin – winner – list : { address + CN } *

gen – winner –command : command

total –sales : { CN + integer } *

35

Experiment No: 4

Aim:Case Study of University Management System

INTRODUCTION

University is created to provide quality education to the people. A lot of colleges come

under a single university. The administrator & bindings of different colleges is its

primary goal. The secondary goals would be designed to achieve better results of its

primary goal.

In order to achieve its goals a proper management system is must. Because it’s this

system that develops interrelationship b/w different departments and colleges that come

under a university and also between different universities

DATA FLOW DIAGRAM

36

Figure - 1 Context Level DFD

37


38


39


40


41

Experiment No:5

Aim:Introduction to Software Engineering and its CASE Tools

INTRODUCTION TO SOFTWARE ENGINEERING

Software engineering is the profession concerned with creating and maintaining soft-ware applications by applying technologies and practices from computer science, project management, engineering, application domains, and other fields. Software engi-neering covers not only the technical aspects of building software systems, but also management issues, such as directing programming teams, scheduling, and budgeting.

INTRODUCTION TO CASE TOOLS

Computer-assisted software engineering (CASE) tools are a set of programs and aids that assist analysts, software engineers, and programmers during all phases of the sys-tem development life cycle (The stages in the system development life cycle are: Pre-liminary Investigation, Analysis, Design, Implementation, and Installation). The imple-mentation of a new system requires a lot of tasks to be organized and completed cor-rectly and efficiently. CASE tools were developed to automate these process and to ease the task of coordinating the events that need to be performed in the system development life cycle. CASE tools can be divided into two main groups - those that deal with the first three parts of the system development life cycle (preliminary investigation, analy-sis, and design) are referred to as Front-End CASE tools or Upper CASE tools, and those that deal mainly with the Implementation and Installation are referred to as Back-End CASE tools or Lower CASE tools.

The major reason for the development of CASE tools was to increase the speed of the development of systems. By doing so, companies were able to develop systems without facing the problem of having business needs change before the system could be finished being developed. Quicker installation also allowed the companies to compete more ef-fectively using its newly developed system that matched its current business needs. In a highly competitive market, staying on the leading edge can make the difference between success and failure.

CASE tools also allowed analysts to allocate more time to the analysis and design stages of development and less time coding and testing. Previous methods saw only 35% of the time being spent of analysis and design and 65% of the time being used to develop code and testing. CASE tools allowed analysts to use as much as 85% of the time in the analysis and design stages of the development. This resulted in systems that more closely mirrored the requirement from the users and allowed for more efficient and effective systems to be developed.

42

By using a set of CASE tools, information generated from one tool can be passed to other tools which, in turn, will use the information to complete its task, and then pass the new information back to the system to be used by other tools. This allows for impor-tant information to be passed very efficiently and effectively between many planning tools with practically no resistance. When using the old methods, incorrect information could very easily be passed between designers or could simply be lost in the shuffle of papers.

HISTORY OF CASE TOOLS

CASE tools began with the simple word processor which was used for creating and ma-nipulating documentation. The seventies saw the introduction of graphical techniques and structured data flow diagrams. Up until this point, design and specifications in pic-torial form had been extremely complex and time consuming to change. The introduc-tion of CASE tools to aid this process allowed diagrams to be easily created and modi-fied, improving the quality of software designs. Data dictionaries, a very useful docu-ment that holds the details of each data type and processes within a system, are the di-rect result of the arrival of data flow design and structural analysis made possible through the improvements of CASE tools. Early graphics packages were soon replaced by specialists packages which enabled editing, updating and printing multiple versions of a design. Eventually, graphic tools integrated with data dictionary databases to pro-duce powerful design and development tools that could hold complete design cycle doc-uments. As a final step, error checking and test case generators were included to vali-date software design. All these processes can know be integrated into a single CASE tool that supports all of the development cycle.

Early 80's computer aided documentation

computer aided diagramming

analysis and design tools

Mid 80's automated design analysis and checking

automated system information repositories

Late 80's automated code generation from design specification

linking design automation

Early 90's intelligent methodology driver

reusability as a development methodology

43

ADVANTAGES OF CASE TOOLS

Current trends are showing a significant decrease in the cost of hardware with a corre-sponding increase in the cost of computer software. This reflects the labor intensive na-ture of the software. Developing effective software packages takes the work of many people and can take years to complete. Furthermore, small errors in the logic of the pro-grams can have huge consequences for the user. CASE tools are an important part of re-solving the problems of application development and maintenance. CASE tools signifi-cantly alter the time taken by each phase and the distribution of cost with in the soft-ware life cycle. Software engineers are now placing greater emphasis on analysis and design. Much of the code can now be generated automatically with the development of detailed specifications. Improvements in both these areas made possible through the use of CASE tools are showing dramatic reductions in maintenance costs. The power of CASE tools lies in their central repository which contains descriptions of all the central components of the system. These descriptions are used at all stages of the cycle; cre-ation of input/output designs, automatic code generation, etc. Later tasks continue to add to and build upon this repository so that by the conclusion of the project it contains a complete description of the entire system. This is a powerful device which was not feasible before the introduction of CASE tools.

More specifically CASE tools:

ensure consistency, completeness and conformance to standards encourage an interactive, workstation environment speeds up development process allows precision to be replicated reduces costs, especially in maintenance increases productivity makes structured techniques practical

SELECTION OF A CASE TOOL

With thousands of tools available the decision of which one will best fit your needs is not an easy one. The failure or success of the tool is relative to your expectations. Therefor a clear understanding of the specifications and expectations of the CASE tool are of utmost necessity before beginning your search. There are three common points of failure; the selection process itself, the pre-requisites of the tool, your business. As pre-viously mentioned the evaluation and selection of a CASE tool is a major project which should not be taken lightly. Time and resources need to be allocated to identifying the criteria on which the selection is to be based. Next, examine if these expectations are reasonable. Make sure you have a clear understanding of the tools purpose. There must be a common vision of the systems development environment in which the tools will be used. Finally, know your organization and its needs. Identify the infra structure and in particular, the level of discipline in the information technology department. Is your se-lection of a CASE tool compatible with the personalities, and expertise of the individu-

44

als who will be using it? If these three areas are taken into consideration the tools is sure to be a success and offer all the benefits outlined above to your development project.

UPPER (FRONT-END) CASE TOOLS

During the initial stages of the system development, analysts are required to determine system requirements, and analyze this information to design the most effective system possible. To complete this task, an analyst will use data flow diagrams, data dictionar-ies, process specifications, documentation and structure charts. When completing these tasks manually, it becomes very tedious to have to redraw the diagrams each time a change is made to the system. Computerized CASE tools allows for these types of changes to be made very quickly and accurately. However, using the old methods, a bigger problem arises when changes need to be made to the system - a change to one di-agram may require many changes to occur throughout all the documentation. For a very large system, it is very easy to forget to make the changes in all documentation, leading to an erroneous representation of the system which could lead to problems during the implementation phase. By using CASE tool's analysis feature, information shared throughout the flowcharts and documentation can be checked against each other to en-sure that they match.

CASE tools are also a very helpful tool to use during the design phase of the system de-velopment. CASE provides tools to help develop prototype screens, reports and inter-faces. These prototypes can then be check and approved by the users and management very quickly. This avoids the problem of having to redesign the interfaces during the implementation phase, that users do not like or do not complete the task they are sup-pose to handle.

LOWER (BACK-END) CASE TOOLS

Lower CASE tools are most often used to help with the generation of the program code. Forth generation programming languages and code generators measurably reduce the time and cost needed to produce the code necessary to run the system. Code generators also produce a high quality of code that is easy to maintain and that is portable (i.e. is easily transferable to other hardware platforms).

Forth generation program code is also much easier to test. Since forth generation code tends to focus on the logic of the program, there are much fewer lines of code for the programmer to examine and test. Fewer lines also aids in the maintenance of the pro-gram since fewer lines need to be examined, and only the higher level forth generation code will need to be changed, not the lower level third generation code.

Code generators also have the feature that they are able to interact with the upper CASE tools. Information that was stored from the upper CASE tools can be accessed using the code generators to aid in the development of the code. Code generators also allow for

45

specialized code to be inserted into the generated program code. This allows special fea-tures to be designed and implemented into the program.

VARIOUS CASE TOOLS:

1. Smart Draw

Smartdraw is the easy-to-use program that lets anyone draw great looking flowcharts, diagrams, forms and other business graphics. It can easily develop: 1. Data Flow Diagrams 5. Flowchart 2. Organizational Chart 6. Timelines 3. Floors Plans 7. Software Designs 4. Networks

Smartdraw automatically aligns shapes, lines and text. Its unique, built-in library of de-sign styles lets you pick professional looking color schemes, shadows, and textures for your drawings with the click of a mouse. Libraries of Smartdraw Symbols provide an unlimited selection of clip art that you can use in your own drawings or in any of the ready-made Smartdraw Templates.

Smartdraw works as a stand-alone program, and as part of Microsoft Office and other programs that support Object Linking and Embedding (OLE). We can insert a Smart-draw drawing directly into Microsoft Word for Windows, using the Insert Object com-mand. With the Professional version of Smartdraw, we can also insert Office docu-ments, like graphs, equations, and spreadsheets into your drawings as Smartdraw sym-bols.

VERSIONS OF SMARTDRAW:

Smartdraw Standard

This is the standard edition of Smartdraw. It is a 32-bit Windows application and re-quires a Pentium (or better) PC running Microsoft Windows 95, 98, NT 4.0, ME, 2000, XP or later. Smartdraw Standard comes with the Standard Collection of symbols and templates.

Smartdraw Professional

The Professional Edition of Smartdraw has all the features of Smartdraw Standard plus a collection of our choice and more advanced features, including:

Spelling checker The Microsoft Office Companion Freeform draw capability for creating your own shapes

46

Gradient Fills Layers Find and Replace Advanced import and export filters OLE Client Support

Smartdraw Professional Plus

Professional Plus has the same features as the Professional Edition of Smartdraw, but also includes a license to the Standard Collection and all eleven Smartdraw Library and Template Collections, which include more than 50,000 symbols and example drawings.

Features of Smartdraw Professional: Smartdraw Professional has the following exclusive features .

Spelling Checker Smart Draw’s spelling checker works similarly to the one in Microsoft Office. Words are checked in the background as you type, and misspelled words are underlined with a red wavy line. Right clicking on a misspelled word presents a menu of suggestions.We can also check the spelling of an entire document upon command. Automatic cor-rection of popular misspellings is supported, and we can add our words to our own cus-tom dictionary.

The Microsoft Office Companion If we have Office installed on your system, the Office Companion adds many more ex-citing features to Smartdraw Professional, including the ability to add bitmaps, graphs, equations and WordArt®, directly from the Smartdraw toolbar. The Companion also in-cludes galleries of pre-designed graphs, text styles, and equation symbols, placed at our fingertips in Smartdraw libraries.

Create our own shapes and lines with Freeform Draw Even though nearly every imaginable shape, symbol and form is available in Smart-draw, the Freeform Draw tools can be used to create our own line or shape. Control points along a line or shape help us refine and smooth your drawing. Experiment with line styles and fill colors to customize a design.

Gradient Fill Almost anywhere we can add color; we can apply a Gradient Fill. The Smartdraw fill color menu shows a choice for gradient fill where we can pick from any of the 64 pre-defined gradients. We can also define our own and save them to the list

Layers Smartdraw Professional allows us to define more than one Layer in our drawing. A layer is a group of objects that lay in front of, or behind, another layer.

47

Layers are used to make complex diagrams like floor plans, where the walls may be in a different layer to wiring or the furniture. The layer feature allows you to work with one layer at a time by hiding other layers or locking them.

Global Search and Replace Smartdraw Professional supports global search and replace for an entire drawing

Advanced Import and Export Filters Smartdraw Professional gives us access to Postscript Import and Export, plus the vast li-braries of technical symbols in AutoCAD format. It supports many more file import and export formats than the regular edition of Smartdraw. These include:

Encapsulated Postscript (EPS) AutoCAD (DXF) CGM HPGL PDF Adobe Illustrator CorelDraw (Import Only) MicroGrafx Draw Visio (Import Only)

OLE Client Support Smartdraw Professional is an OLE client. As with Microsoft Word and other Office ap-plications, we can insert graphs, WordArt, Spreadsheets and other OLE objects into Smartdraw Professional drawings. In Smartdraw an OLE object behaves like any shape. It can be flipped, rotated, moved and re-opened for editing by the program that created it. OLE objects in Smartdraw drawings can also be added to Smartdraw symbol libraries, while retaining their OLE object properties. Dragging an OLE symbol (like a graph, for example) from a library into our Smartdraw drawing creates an OLE object that can be edited by the program that created it

SMART DRAW CAN HELP US TO: Illustrate a report Analyze a process Make a presentation Document procedures Communicate clearly

ADVANTAGES OF SMART DRAW: Easy "drag-and-drop" drawing—no skill required! Over 50,000 built-in symbols and clip art Works hand-in-hand with Microsoft Office Automatic alignment for neat, crisp drawings Built-in templates and examples

48

Import our own symbols and clipart Save your drawings for the web as GIF, JPG, or HTML Easily convert drawings made in other software.

2. Umbrello

All actions in Umbrello UML Modeller are accessible via the menu and the toolbars, but Umbrello UML Modeller also makes extensive use of right mouse button context menus. You can right mouse button click on almost any element in Umbrello UML Modeller's work area or tree view to get a menu with the most useful functions that can be applied to the particular element you are working on. Some users find this a little confusing at the beginning because they are more used to working with the menu or tool bars, but once you get used to right clicking it will greatly speed up your work.

User Interface

Umbrello UML Modeller's main window is divided in three areas that will help you keep an overview of your entire system and access the different diagrams quickly while working on your model. These areas are called:

Tree View

The Tree View is usually located on the top left hand side of the window and shows all the diagrams, classes, actors and use cases that build up your model. The Tree View allows you to have a quick overview of the elements composing your model. The Tree View also gives you a quick way to switch between the different diagrams in your model and inserting elements from your model into the current diagram.

If you are working on a model with more than just a few classes and diagrams, the Tree View may help you stay on top of things by organising your model elements in folders. You can create folders by selecting the appropriate option from the context menu (right mouse button click on one of the folders in the tree view) and you can organise your elements by moving them to the appropriate folder (drag and drop)

Documentation Window

The Documentation Window is the small window located on the left bottom of Umbrello UML Modeller, and it gives you a quick preview of the documentation for the currently selected item. The Documentation Window is rather small because it is intended to allow you just a quick pick into the element's documentation while taking as little screen space as possible. If you need to view the documentation in more detail you can always open the item's properties.

49

Work Area

The Work Area is the main window in Umbrello UML Modeller and is where the real action takes place. You use the Work Area to edit and view the diagrams in your model. The Work Area shows the currently active diagram. Currently only one diagram can be shown on the Work Area at any time.

Printing

Umbrello UML Modeller allows you to print individual diagrams. Press the Print button on the application toolbar or selecting the Print option from the File menu will give you a standard KDE Print dialogue from where you can print your diagrams.

Logical Folders

To better organise your model, especially for larger projects, you can create logical folders in the Tree View. Just select the option New->Folder from the context menu of the default folders in the Tree View to create them. Folders can be nested, and you can move objects around by dragging them from one folder and dropping them into another.

Organising a Model with Logical Folders in Umbrello UML Modeller

3. Rational Rose

Why Rational SuiteThink about your last software project:_ Was it delivered on time?

50

_ Was it released within its budget?_ Did it meet requirements, satisfy users, and perform reliably?_ Was communication among team members clear and timely?_ Was your development process repeatable?Many project teams experience problems in these areas. Subsequently:_ Projects finish late (or not at all)._ Results do not match requirements._ Serious design flaws are uncovered late in development._ Defects are found after the software ships, instead of during development.

Making Projects More Successful

Rational Software helps organizations overcome these challenges and developsoftware more successfully by offering:

_ Software engineering best practices._ Integrated tools that automate these best practices._ Professional services that accelerate adoption and implementation of these bestpractices and tools.

Rational Suite Best Practices

51

Rational Suite Tools

Rational puts these best practices to work by offering tools that:_ Unify teams and enhance communication._ Optimize individual productivity._ Simplify adoption with common installation, licensing, and user support plans.Rational Suite editions are customized with sets of tools best suited for each member of your team.

52

53

54

Experiment No:6

Aim:Case study on Library Management System

The Library Management System is able to manage different types of library resources

such as Books, Magazines, News Papers, CD/DVDs, and any other resources which the

management feels in the future could form a resource

The important modules that are going to implement in the proposed system.

Calculating the fines.

Reservation of books.

Searching facility depends upon i) Book name ii) Author.

Log in, depends upon campus Id.

Administrator has all the privileges to add, modify and delete the books.

My account facility for the student so that he can view his account details.

Context Diagram for Library Management System

55

UserUser

Library booking System

AdminAdmin

Issue books

Pending book Details

HistoryReserveBook

Manage Transactions

Create Accounts

Issue Books

Generate Reports

Search Book

2.2 Data flow Diagram

Dataflow diagram is the graphical system model that shows all main requirements for

an IS in one diagram

56

Issue books

UserUser

Issue History

Pending books

issueDetails issueDetails

ReserveBook

Reservation

Book Issue

AdminAdmin

Generates reports

Manages Payments

Payment

ManagesUser

Users

Manages Books

Items

books

books

books

books

books

books

Reserves Reserves

issues

Add, Edit, delete

Add, Edit, delete

Request Books

RequestReques

t for book

Experiment No:7

Aim:Case study on inventory control system

INTRODUCTION:Relevant data flows include payment information, receipt, goods sold information, and inventory information. Three data stores are a goods sold file, an inventory file, and daily sales total file. Processes include update goods sold file, update inventory file, up-date daily sales total file, and produce management reports. Sources/sinks include cus-tomer and store manager. A sample context diagram and level-0 data flow diagram are provided below. In the level-0 data flow diagram, Transform Customer Purchase, Up-date Goods Sold File, Update Inventory File, and Update Sales Total File, were selected as processes rather than as sources/sinks because they were deemed to be central to the point of sale process. Point out why these DFDs are balanced.

Retail StoreContext Level DFD

DATA FLOW DIAGRAM:

Retail Store

Level-0 Diagram

57

0

Point of SaleSystem

StoreManager

Customer

Receipt

Payment

ManagementReport

58

5

ProduceManagement

Reports

2

Update Goods SoldFile

3

UpdateInventory

File

1

TransformCustomerPurchase

4

UpdateSales Total

File

D3

Sales Total FileD2

Inventory FileD1

Goods Sold File

Customer

Receipt

StoreManagerManagement

Report

Goods Sold InventoryData

Sales Data

FormattedGoods SoldAmount

FormattedInventoryAmount

FormattedSales TotalAmount

Goods SoldAmounts

InventoryAmounts Sales Totals

Payment

Experiment No:8

Aim:Case study on Railway Reservation System

INTRODUCTION:The Railway Reservation system has the following main features:Traveler may be able to book tickets from any station to any stationAvailability of seats can be known at any timeStatus of trains can be easily checkedPrevious bookings can be easily seenThe system requires the traveler to give the specific details about traveling schedule; it includes date of journey, source station, destination station, class of traveling, number of seats to be reserved etc. Clerk will then send the account details to the accountant, who calculates the actual fare. Supervisor then checks all the details like availability of seat etc and pass it to the management.

DATA FLOW DIAGRAM:

Figure – 1Context Level DFD

59


60

Se Practical File

Documents

umbrello uml

prel dtl impl

goods sold

mouse button

rational unified

advanced data

update inventory

data flow