Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

23
Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING 1

Transcript of Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

Page 1: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

1

Software Engineering

Page 2: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

2

Data Flow Diagrams (DFD)DFDs describe the flow of data

or information into and out of a system◦what does the system do to the data?

A DFD is a graphic representation of the flow of data or information through a system

Page 3: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

3

Elements of data-flow diagrams

Information Flow/Data Flow Process/Data Transform

External Entity/Information Sources

Data Store/Information Store

Output

Page 4: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

4

Information Flow/Data FlowInformation flows represent the

information being passed into or out of a system. It is represented as a labeled arrow:

Taxable Income

Page 5: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

5

Data transforms/ProcessData transforms labeled circles

with one or more incoming and outgoing information flows:

Page 6: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

6

Information sources/External EntityInformation sources and sinks are

information that come into the system, or leave the system, and are represented by squares:

Page 7: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

7

Information store/Data storeInformation Stores represent

locations where information can be store for the duration of the system activity:

Page 8: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

8

OutputThis element shows the output of

a system. This is represented as:

Page 9: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

9

Importance of DFDs in a good software design DFD is a very simple formalism – it is simple to

understand and use. Starting with a set of high-level functions that a

system performs, a DFD model hierarchically represents various sub-functions. In fact, any hierarchical model is simple to understand.

DFD is an elegant modeling technique that turns out to be useful not only to represent the results of structured analysis of a software problem

But also for several other applications such as showing the flow of documents or items in an organization.

Page 10: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

10

General Rules:-No internal LogicTo keep it uncluttered(input same then

join)No miracles/Blackholes(only i/p, no o/p)Database cannot sink/source(no data

storing, only reading)No data stores should be there at level 0No direct dataflow between two entities

and two data stores.Direct dataflows between two

processes-yes

Page 11: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

11

Levelled DFDsEven a small system could have

many processes and DFD could be large and messy◦use levelled DFDs - view system at

different levels of detail

Page 12: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

12

Level 0 - Context DiagramIt is the most abstract data flow

representation of a system. It represents the entire system as a single

bubble. This bubble is labelled according to the

main function of the system. The various external entities with which

the system interacts and the data flow occurring between the system and the external entities are also represented.

Only one process and all external entities identified at context level. No new entity can come in level 1 and level 2.

Page 13: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

13

Level 1 - Overview DiagramGives overview of full system Identifies major processes and

data flows between themIdentifies data stores that are

used by the major processesProcess will be decomposed but

external entity will remain same.

Page 14: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

14

Level 2 - Detailed Diagram

Level 1 process is expanded into more detail

Each process in level 1 is decomposed to show its constituent processes

Page 15: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

15

Numbering of Bubbles(Processes) It is necessary to number the different bubbles

occurring in the DFD. These numbers help in uniquely identifying any

bubble in the DFD by its bubble number. The bubble at the context level is usually assigned

the number 0 to indicate that it is the 0 level DFD. Bubbles at level 1 are numbered 0.1, 0.2, 0.3, etc,

etc. When a bubble numbered x is decomposed, its children bubble are numbered x.1, x.2, x.3, etc.

In this numbering scheme, by looking at the number of a bubble we can determine its level, its ancestors, and its successors.

Page 16: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

16

Commonly made errors while constructing a DFD model

Many beginners commit the mistake of drawing more than one bubble in the context diagram. A context diagram should depict the system as a single bubble.

Many beginners have external entities appearing at all levels of DFDs. All external entities interacting with the system should be represented only in the context diagram. The external entities should not appear at other levels of the DFD.

It is a common oversight to have either too less or too many bubbles in a DFD. Only 3 to 7 bubbles per diagram should be allowed, i.e. each bubble should be decomposed to between 3 and 7 bubbles.

Page 17: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

17

A common mistake committed by many beginners while developing a DFD model is attempting to represent control information in a DFD. It is important to realize that a DFD is the data flow representation of a system, and it does not represent control information. For an example mistake of this kind:

Consider the following example. A book can be searched in the library catalog by inputting its name. If the book is available in the library, then the details of the book are displayed. If the book is not listed in the catalog, then an error message is generated. While generating the DFD model for this simple problem, many beginners commit the mistake of drawing an arrow to indicate the error function is invoked after the search book. But, this is a control information and should not be shown on the DFD.

Page 18: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

18

Showing control information on a DFD - incorrect

Another error is trying to represent when or in what order different functions (processes) are invoked and not representing the conditions under which different functions are invoked.

If a bubble A invokes either the bubble B or the bubble C depending upon some conditions, we need only to represent the data that flows between bubbles A and B or bubbles A and C and not the conditions depending on which the two modules are invoked.

Page 19: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

19

A data store should be connected only to bubbles through data arrows. A data store cannot be connected to another data store or to an external entity.

All the functionalities of the system must be captured by the DFD model. No function of the system specified in its SRS document should be overlooked.

Only those functions of the system specified in the SRS document should be represented, i.e. the designer should not assume functionality of the system not specified by the SRS document and then try to represent them in the DFD.

The data and function names must be intuitive. Some students and even practicing engineers use symbolic data names such a, b, c, etc. Such names hinder understanding the DFD model.

Many beginners leave different levels of DFD unbalanced.

Page 20: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

Rules of Data Flow

Data can flow from

◦ External entity to process

◦ Process to external entity

◦ Process to store and back

◦ Process to process

Data cannot flow from

◦ External entity to external entity

◦ External entity to store◦ Store to external entity◦ Store to store

Page 21: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

21

Level 0 - Context Diagram

SuperMarket System

0

Customer

Manager

Sales ClerkCust. Deatils

All Cust. details

Sales details

CN

Winner lists Winner

Lists

Page 22: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

22

Level 1 – Overview Diagram

Register Customer

0.1

Register Sales0.2

Generation of

winner lists0.3

Customer details

Sales Details

Cust. details

Winner lists

Reset

Page 23: Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING1.

INTRODUCTION TO SOFTWARE ENGINEERING

23

Level 2 – Detailed Diagram

Verification

0.3.1

Generation of

Surprise gift

winner list0.3.3

Generation of Gold Coin winner list

0.3.2

Final DataWinner list1

Winner list2