Sie sind auf Seite 1von 58

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

S LC P D lanning P hase
Identify analyze, , p rioritize, and a rrange IS needs

1-11

2005 by Prentice H P rentice all

plication.

Analyzes end-user information needs.

SDLC Analysis Phase


Study and structure system requirements

1-12

2005 by Prentice Hall

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

Convert recommended solution to system specifications

Logical design: functional features described independently of computer platform

Physical design: logical specifications transformed to technologyspecific details

Implementation (Development): The real code is written here. Code, test, install, and support the information system

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 development, 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.

Systematically repair and improve the information system

Products and Deliverables

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 Model
The oldest of these, and the best known, is the waterfall: a sequence of stages in which

the output of each stage becomes the input for the next. These stages can be characterized and divided up in different ways, including the following: The waterfall model is well understood, but it's not as useful as it once was. The problem is that the waterfall model assumes that the only role for users is in specifying requirements, and that all requirements can be specified in advance. Unfortunately, requirements grow and change throughout the process and beyond, calling for considerable feedback and iterative consultation. Thus many other SDLC models have been developed.

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.

Life Cycle Models


Rqts Defn Prel Dtl Impl I&T Dsgn Dsgn O&S

System A

Determine objectives, alternatives, constraints.

Risk/Analysis

Prototype
Build

Waterfall
Plan next phase.

Unit Test O&S AT I&T

Spiral
Part 1

Develop, verify next level product.

System Rqts Defn

Rqts Defn

Prel Dtl Impl I&T Dsgn Dsgn Rqts Defn

O&S

Final Sys I&T

O&S

System A

Prel Dtl Impl I&T Dsgn Dsgn Rqts Defn

O&S

Part 2 (+Part 1) Part 3 (+Part 1 + Part 2)

Incremental

Prel Dtl Impl I&T Dsgn Dsgn

O&S

One description of a product life cycle may not be adequate. Therefore, the organization may define a set of approved product life -cycle models.
6/3/2005 Page 4

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.

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 developer 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: requirements definition, system design, and coding and testing are improved with each cycle through the process.

Rational Unified Process

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 system. 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 behaviors are present. Configuration and change management: Keeping track of all the different versions 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
10

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 improvement 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 employing 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.

11

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 "systematized". being unable to evaluate system project boundaries or degree of automation, resulting 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 2business process diagram. This process of more detailed analysis can then continue

12

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 reengineering, 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

13

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 physical

14

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. 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.

15

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 vendors name and address at the bottom of a cheque. The data dictionary might define vendors 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. 4. Self-defining words should not be decomposed.

Advantages 16

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 programming 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 definition 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, DO UNTIL, PERFORM 3. Indent blocks of statements to show their hierarchy (nesting) clearly.

17

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 condition is met. Iteration uses terms such as: DO.... REPEAT...DO UNTIL

18

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 Actions Condition Alternatives 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 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:

19

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 N Y Y N Y Y N Y N Y N Y N Y N N N N N N N N N

and continue the pattern for each condition, this will give all possible combinations: CONDITION 1 CONDITION 2 CONDITION 3 CONDITION 4 Y Y Y Y Y Y Y N Y Y N Y Y Y N N Y N Y Y Y N Y N Y N N Y Y N N N N Y Y Y N Y Y N N Y N Y N Y N N N N Y Y N N Y N N N N Y N N N 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 CONDITION 2 ACTION 1 Can be expressed as: CONDITION 1 CONDITION 2 ACTION 1 Y X Y Y X Y N X

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.

20

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 troubleshooter RULES PRINTER DOES Y Y Y Y N NOT PRINT A RED LIGHT IS Y Y N N Y FLASHING PRINTER IS Y N Y N Y UNRECOGNIZED CHECK THE X POWER CABLE CHECK THE COMPUTERX X PRINTER CABLE ENSURE PRINTER X X X SOFTWARE INSTALLED CHECK/REPLACE X X X X INK

N N N Y N N N Y N

CONDITIONS

ACTIONS

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 outputs a yes/no decision. Decision trees therefore represent Boolean functions. Functions with a larger range of outputs can also be represented

21

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 squares 2. Chance nodes - represented by circles 3. 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.

22

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 decision 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 explanation for the result is easily replicated by simple math. Can be combined with other decision techniques.

23

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.

Symbols
A 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 from the bottom point and right point, one corresponding to Yes or True, and one

24

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 "predefined 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.

25

Entity Relationship Diagram Notations Entity


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

Weak Entity
Attributes are the properties or characteristics of an entity.

Key attribute
A 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 attribute
A multivalued attribute can have more than one value. For example, an employee entity can have multiple skill values.

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.

26

Relationships
Relationships illustrate how two entities share information in the database structure.

Cardinality
Cardinality 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 relationship
In some cases, entities can be self-linked. For example, employees can supervise other employees.

27

Experiment No 3 Aim:Case Study of Super Market Prize Scheme


INTRODUCTION TO THE SYSTEM: A Supermarket needs to develop following 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 computer. A customer can present his CN to the check out staff when he makes any purchase. 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.

28

Figure - 2

Level 1 DFD

29

Figure - 3

Level 2 DFD

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.

30

Field name(s) Field names are the names used for this element in computer programs and database 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 reference 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.

31

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 elements, 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, depending 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.

32

Data element notes Short notes not included in above parts.

2. TABLE DEFINITIONS: 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 table 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. definition is usually available with SQL command help table

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.

33

4. ENTITY-RELATIONSHIP MODEL OF DATA:


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 customerdata : { address + CN } * sales info : { sales details } * winnerlist : 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 } *

34

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 its this system that develops interrelationship b/w different departments and colleges that come under a university and also between different universities

DATA FLOW DIAGRAM


Figure - 1 Context Level DFD

35

Figure - 2

Level 1 DFD

36

Figure - 3

Level 2 DFD

37

Figure - 4

Level 3 DFD

38

Figure - 5

Level 4 DFD

39

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 software applications by applying technologies and practices from computer science, project management, engineering, application domains, and other fields. Software engineering 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 system development life cycle (The stages in the system development life cycle are: Preliminary Investigation, Analysis, Design, Implementation, and Installation). The implementation of a new system requires a lot of tasks to be organized and completed correctly 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, analysis, 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 effectively 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.

40

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 important 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 manipulating documentation. The seventies saw the introduction of graphical techniques and structured data flow diagrams. Up until this point, design and specifications in pictorial form had been extremely complex and time consuming to change. The introduction of CASE tools to aid this process allowed diagrams to be easily created and modified, improving the quality of software designs. Data dictionaries, a very useful document that holds the details of each data type and processes within a system, are the direct 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 produce powerful design and development tools that could hold complete design cycle documents. As a final step, error checking and test case generators were included to validate 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

41

ADVANTAGES OF CASE TOOLS


Current trends are showing a significant decrease in the cost of hardware with a corresponding increase in the cost of computer software. This reflects the labor intensive nature 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 programs can have huge consequences for the user. CASE tools are an important part of resolving the problems of application development and maintenance. CASE tools significantly alter the time taken by each phase and the distribution of cost with in the software 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; creation 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 previously 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 selection of a CASE tool compatible with the personalities, and expertise of the individuals who will be using it? If

42

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 dictionaries, 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 diagram 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 ensure that they match. CASE tools are also a very helpful tool to use during the design phase of the system development. CASE provides tools to help develop prototype screens, reports and interfaces. 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 suppose 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 program 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

43

specialized code to be inserted into the generated program code. This allows special features 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 design 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 readymade 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 Smartdraw drawing directly into Microsoft Word for Windows, using the Insert Object command. With the Professional version of Smartdraw, we can also insert Office documents, like graphs, equations, and spreadsheets into your drawings as Smartdraw symbols.

VERSIONS OF SMARTDRAW: Smartdraw Standard


This is the standard edition of Smartdraw. It is a 32-bit Windows application and requires 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 Gradient Fills

44

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 Draws 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 correction of popular misspellings is supported, and we can add our words to our own custom dictionary.

The Microsoft Office Companion


If we have Office installed on your system, the Office Companion adds many more exciting features to Smartdraw Professional, including the ability to add bitmaps, graphs, equations and WordArt, directly from the Smartdraw toolbar. The Companion also includes 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 Smartdraw, 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.

45

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 libraries 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 applications, 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" drawingno skill required! Over 50,000 built-in symbols and clip art Works hand-in-hand with Microsoft Office

46

Automatic alignment for neat, crisp drawings Built-in templates and examples 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.

47

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 Suite 48

Think about your last software project: _ Was it delivered on time? _ 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 develop software more successfully by offering: _ Software engineering best practices. _ Integrated tools that automate these best practices. _ Professional services that accelerate adoption and implementation of these best practices and tools.

Rational Suite Best Practices

49

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.

50

51

52

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.
Issue books

User User

Pending book Details

Context Diagram for Library Management System


Search Book

History
ReserveBook

Library booking System

Generate Reports

Issue Books Create Accounts

Admin Admin

Manage Transactions

53

2.2 Data flow Diagram


Dataflow diagram is the graphical system model that shows all main requirements for an IS in one diagram
books

Issue books User User


books books

books

Admin Admin Pending books


Generat es reports
Manages Payments issues
Add, Edit, delete

Issue History
books

books

Reserves

Reserves

issueDetails issueDetails Book Issue

Reserve Book Reservation Request Books


Request for book

Payment
Add, Edit, delete

Manages Books

Items Request

ManagesUse r Users

54

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, update daily sales total file, and produce management reports. Sources/sinks include customer 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, Update 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 Store Context Level DFD
0 Receipt Customer Payment Point of Sale System Management Report Store Manager

DATA FLOW DIAGRAM: Retail Store Level-0 Diagram

55

Receipt

1 Transform Customer Purchase

Customer Payment

Goods Sold

Inventory Data

Sales Data

2 Update Goods Sold File

3 Update Inventory File

4 Update Sales Total File

Formatted Goods Sold Amount

Formatted Inventory Amount

Formatted Sales Total Amount

D 1

Goods Sold File

D 2

Inventory File

D 3

Sales Total File

Goods Sold Amounts

Inventory Amounts 5 Produce Management Reports Management Report

Sales Totals

Store Manager

56

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 station Availability of seats can be known at any time Status of trains can be easily checked Previous bookings can be easily seen The 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 1 Context Level DFD

57

Figure - 2

Level 1 DFD

58

Das könnte Ihnen auch gefallen