Processoriented approaches Colin Potts Georgia Tech Colin Potts

  • Slides: 11
Download presentation
Process-oriented approaches Colin Potts Georgia Tech © Colin Potts C 5 -1

Process-oriented approaches Colin Potts Georgia Tech © Colin Potts C 5 -1

Process-oriented philosophy l A system is what it does » so model it as

Process-oriented philosophy l A system is what it does » so model it as a hierarchy of functions l Functional decomposition for description » but not necessarily for deriving the description l Requirements drive the decomposition process » but decomposition furthers understanding of the requirements © Colin Potts C 5 -2

Overview: Structured Analysis l Structured Analysis » Functional decomposition based on data flow »

Overview: Structured Analysis l Structured Analysis » Functional decomposition based on data flow » Widely used » Intuitively simple © Colin Potts C 5 -3

Mapping the system’s context l Describe system’s interfaces to its environment Alarm notificn Security

Mapping the system’s context l Describe system’s interfaces to its environment Alarm notificn Security company Sensor Time Status signal Burglar alarm system Alarm cmd Settings Householder © Colin Potts Clock Security code Warning tone cmd Tone generator C 5 -4

Team exercise: Context mapping l In teams of 2 -3 » Think about the

Team exercise: Context mapping l In teams of 2 -3 » Think about the system described in the requirements document » Draw a context diagram for the system l As a class » Discuss insights gained into the system’s requirements © Colin Potts C 5 -5

Data flow diagrams l Define sub-functions & essential internal data flows Alarm Security Settings

Data flow diagrams l Define sub-functions & essential internal data flows Alarm Security Settings Set alarm Active sensors © Colin Potts Alarm notificn Raise alarm Alarm signal Noninhibited alarm Determine alarm conditions Monitor sensors Intruder signal cmd code Time Warning tone cmd C 5 -6

Layered DFDs l Functional architecture is hierarchical » System is a collection of interacting

Layered DFDs l Functional architecture is hierarchical » System is a collection of interacting functions which may be decomposed further » Net inputs and outputs should be consistent across levels © Colin Potts C 5 -7

Structured system specification l Structured Analysis has recommended document structure » Data flow diagrams

Structured system specification l Structured Analysis has recommended document structure » Data flow diagrams form core models » Data dictionary » Process specs. B A D P Q C E R Data element A B Definition Integer* Integer, Float Process P Find sum of elements Find mean of elements © Colin Potts C 5 -8

Detailed specification l Data dictionary » Definitions of data elements that flow along data

Detailed specification l Data dictionary » Definitions of data elements that flow along data flows l Backus-Naur Form » Settings : : = Out | In | Off » Security_Code : : = Digit » Security_Code : : = Digit* » Alarm_Notificn : : = Time House_Id Sensor_Id © Colin Potts l Process specs » Data flow diagram decomposition – Sub-diagram with consistent I/O » Pseudo-code defs C 5 -9

Structured Analysis: Evaluation l Advantages » Basic ideas and notations are simple » Many

Structured Analysis: Evaluation l Advantages » Basic ideas and notations are simple » Many organizations have major investment in SA » Widespread tool support for notations and analyses l Limitations » Top-down decomposition is better for explaining than for deriving » Essential architecture and implementation architecture often different – Document maintenance » Significant ambiguities – Serious for RT systems © Colin Potts C 5 -10

How to find out more: Structured specification l Methodology-specific textbook » De Marco: Structured

How to find out more: Structured specification l Methodology-specific textbook » De Marco: Structured Analysis & System Specification l Book on methods, incl. SA » Wieringa: Requirements Engineering © Colin Potts C 5 -11