Software engineering analysis and design cse3308
Download
1 / 34

Software Engineering: Analysis and Design - CSE3308 - PowerPoint PPT Presentation


  • 171 Views
  • Updated On :

CSE3308/DMS/2002/5. Monash University - School of Computer Science and Software Engineering . Software Engineering: Analysis and Design - CSE3308. Structured Analysis - Part 1. Lecture Outline. History of Structured Analysis Context Diagrams Event Lists Data Flow Diagrams

Related searches for Software Engineering: Analysis and Design - CSE3308

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Software Engineering: Analysis and Design - CSE3308' - fell


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Software engineering analysis and design cse3308 l.jpg

CSE3308/DMS/2002/5

Monash University - School of Computer Science and Software Engineering

Software Engineering: Analysis and Design - CSE3308

Structured Analysis - Part 1


Lecture outline l.jpg
Lecture Outline

  • History of Structured Analysis

  • Context Diagrams

  • Event Lists

  • Data Flow Diagrams

  • Control Flows and Processes

  • Levelled Data Flow Diagrams


History of structured analysis sa l.jpg
History of Structured Analysis (SA)

  • First texts appeared in 1977

    • Tom de Marco - Structured Analysis and System Specification

    • Gane and Sarson - Structured Systems Analysis

  • 1984 - SA is extended

    • McMenamin and Palmer - Essential Structured Analysis

  • 1989 - SA reaches its peak

    • Yourdon publishes Modern Structured Analysis

    • Integrates Chen’s Entity-Relationship Models

  • 1991 Yourdon moves to Object-Oriented Analysis

  • 1995 38% of organisations used SA


Context diagrams l.jpg
Context Diagrams

  • Indicate the people, organisations and systems which communicate with our system

  • Show the data which our system receives from the outside world

  • Show the data produced by the system and sent to the outside world

  • Show the data which is shared by the system with the outside world

  • Show the boundary between the system and the rest of the world


Constructing a context diagram l.jpg

Flights

Constructing a Context Diagram

  • 4 components

    • The System

    • Terminators

      • also know as external entities

    • Data Flows

    • Data Stores

Airline

Booking

System

Customer

reservation


Airline reservation system l.jpg

Credit Card Data

Airline Reservation System

Customer

Airline

Request for

reservation

Flight

confirmation

Flight details

Request

for

reservation

Airline

Reservation

System

Credit

details

Reports

Transaction

details

Management

Finance

System


Guidelines for context diagrams l.jpg
Guidelines for Context Diagrams

Yes

No

  • Use appropriate names

  • Don’t be too specific with names

Customer

Fred

Flintstone

Ready to send input

Order

Entry

System

Customer

Okay, send input

Here’s the input

Great, I got the input


Guidelines 2 l.jpg
Guidelines (2)

  • Can have Dialogue Flows representing two-way data flow

Flight status

response

Credit check

request

Finance

System

Airline

Reservation

System

Customer

Credit check

response

Flight status

request

  • Duplicate terminators if necessary to simplify the diagram


Student enrolment system l.jpg
Student Enrolment System

  • System

    • Student Enrolment system

  • Terminators

    • Student

    • University Management

    • University Staff

  • Data Stores

    • Student Results

  • Data Flows (7)

    • reports to management, enrolment details from student, confirmation of enrolment to student, payment details from staff, student lists to staff, student results from staff to system, student results from Student Results database to system



Event lists l.jpg
Event Lists

  • List of the external events that occur in the outside world which affect the system, i.e. events generated by terminators

  • Events can be

    • Flow - some data flows between the external world and the system

    • Temporal - an event occurs as a result of some timing

    • Control - special case of a temporal event, an external stimulus that occurs at some unpredictable point in time

  • Events are always viewed from the terminator’s point of view


Event examples l.jpg
Event examples

  • Customer places reservation (Flow)

  • Customer cancels reservation (Flow)

  • Accounting System receives transaction details (Flow)

  • Management requests weekly report (Temporal)

  • Airline confirms reservation (Temporal)

  • Credit card to be verified (Control)


Constructing the event list l.jpg
Constructing the Event List

  • Examine each terminator in turn

  • Decide whether it generates a single event or possibly multiple events

    • Customer places order

    • Can be “Customer places order” and “Salesperson places order”

  • Need to allow for failure conditions on the part of the terminator, but no need to allow for system failures


Events l.jpg
Events

  • Look at a system which controls the sales of goods at a supermarket

  • Entities to think about

    • Cash register

    • Checkout Operator

    • Customer

    • Scanner

    • Receipt printer

  • What events can you identify?



Data flow diagrams l.jpg
Data Flow Diagrams

  • Extends the Context Diagram by defining the processes which make up a system

  • 4 components

    • Processes

      • Number - identifies process and indicates place in DFD level heirarchy

      • Name - what the process does

      • Part of system which transforms inputs to outputs

    • Data Flows

    • Data Stores

    • Terminators

}

as in context diagram


Data flows l.jpg
Data Flows

  • Indicate movement of packets of information from one part of the system to another part

  • Flows are named

    • Input flow

    • Output flow

    • Diverging flows - see next slide

Validate

Phone

No.

Phone No.

Flight Schedule

Information

Generate

Flight

Schedule


Diverging data flows l.jpg
Diverging Data Flows

Order

Customer

Address

Produce

Valid

Order

Validate

postcode

Generate

Shipping

Docs

Invalid

orders

postcode

Order details

phone no.

Validate

phone

no.

street

address

Update

Inventory

Generate

Invoice

Validate

street

address


Typical figure 0 dfd l.jpg

Orders

Customers

Invoices

Typical Figure 0 DFD

Note:some analysts do notshow terminators on theFigure 0 DFD

Customers

Warehouse

name,orders

Order

Order

invalidorders

1.

Receive

Order

books

Note:physical flows

2.

Ship

Books

Customer

Invoice

Customer

books

Customer

Invoice

3.

Collect

Payment

invoices, statements

Customers

payments, inquiries


An example l.jpg
An example

  • For the checkout operator example

    • What are the terminators?

    • What are the main processes?

    • What are the main data flows?

  • Draw a data flow diagram to put the above elements together




Guidelines for constructing dfds l.jpg
Guidelines for constructing DFDs

  • Choose meaningful names

  • Number the processes

  • Redraw the DFD as many times as necessary for aesthetics

  • Avoid overly complex DFDs

    • Fit on one A4 page

    • approximately 6 processes and related data stores and terminators


Guidelines 224 l.jpg
Guidelines (2)

  • Make sure the DFD is internally consistent and consistent with any associated DFDs

    • Avoid infinite sinks - processes with inputs but no outputs

    • Avoid spontaneous generation processes - processes with outputs but no inputs (Possible exception is a random number generator)

    • Beware of unlabelled flows and processes

    • Beware read-only/write-only stores

    • Make sure that incoming and outgoing flows from the DFD match those on the DFD at the level above


Control flows and processes l.jpg
Control Flows and Processes

  • Real-time systems need a means to model control (signals/interrupts)

  • Shown with dashed lines and circles

  • A control flow can be regarded as a binary signal - does not carry value-bearing data

  • Used to trigger/wake-up a dormant process

  • Internal behaviour of a control process described by a state-transition diagram

  • Generally one control process in a DFD

  • inputs and outputs of control process consist only of control flows


Example l.jpg

Surveillance data

Example

Process

Satellite

Data

satellite data

satellite signal

Control

Surveillance

System

enable satellite

processing

radar signal

enable radar

processing

Process

Radar

Data

radar data


Doom example l.jpg
Doom Example

Control

Game

enter playmode

start playing

startadministrating

enteradministrationmode

Play Game

Administer

Game

Game Details


Leveled dfds l.jpg
Leveled DFDs

  • Most systems are far too complex to depict on one DFD


Leveled dfds 2 l.jpg
Leveled DFDs (2)

  • Break each process down into sub-processes

  • Numbering of processes indicates their parents process, and thus their position in the hierarchy of levelled DFDs


Guidelines for levelled dfds l.jpg
Guidelines for Levelled DFDs

  • How many levels?

    • Each level should have approximately 6 processes

    • Simple systems: 2-3 levels

    • Medium size: 3-6 levels

    • Large size: 5-8 levels

  • All parts of the system may not need the same numbers of levels

  • Levels must be consistent with each other

    • Data flows coming into and going out of a process at one level must correspond to the data flows coming into and out of the entire figure at the next lower level - this is known as balancing



An unbalanced dfd l.jpg
An Unbalanced DFD

Can you see the problem?


Data stores and levelled dfds l.jpg
Data Stores and Levelled DFDs

  • Show the data store at all relevant levels


References l.jpg
References

  • Yourdon, E., Modern Structured Analysis, Prentice Hall, 1989.


ad