Structured Analyygsis and Structured Design
- Introduction to SASD - Structured Analysis - Structured Design
Lecturer: JUNBEOM YOO [email protected] Ver. 1.5 http://dslab.konkuk.ac.kr References
• Mo dern Structure d Ana llys is, Edwar d Your don, 1989. • Introduction to System Analysis and Design: a Structured Approach, Penny A. Kendall, 1996.
• Zhou Qun, Kendra Hamilton, and Ibrahim Jadalowen (2002). Structured Analysis and Structured Design (SASD) - Class Presentaion http://pages.cpsc.ucalgary.ca/~jadalow/seng613/Group/
Konkuk University 2 Structured Analysis
• SdliiStructured analysis is [Kendall 1996] – a set of techniques and graphical tools – that allow the analyypsts to develop a new kind of sy ypstem specification – that are easily understandable to the users. – Analysts work primarily with their wits, pencil and paper.
• SASD – Structured Analysis and Structured Design
Konkuk University 3 History of SASD
• Deve lope d in t he late 1970s by b DMDeMarco, YdYourdon an d Constantine after the emergence of structured programming.
• IBM incorporated SASD into their development cycle in the late 1970s and early 1980s.
• Yourdon published the book “Modern Structured Analysis” in 1989.
• The availability of CASE tools in 1990s enabled analysts to dldevelop an d mo difthhilSASDdldify the graphical SASD models.
Konkuk University 4 Philosophy of SASD
• Ana llysts attempt to divid e large, comp lex pro blems into sma ller, more easily handled ones. Æ “Divide and Conquer”
• Top-Down approach
• Functional view of the problem
• Analysts use graphics to illustrate their ideas whenever possible.
• Analysts must keep a written record.
Konkuk University 5 Philosophy of SASD
• “ Th e purpose of SASD i s to d evel op a use fu l, hihigh h quali ty information system that will meet the needs of the end user. [Yourdon 1989] “
Konkuk University 6 Goals of SASD
• IliddhikffilImprove quality and reduce the risk of system failure.
• Establish concrete requirements specifications and complete requirements documentations.
• Focus on reliability, flexibility and maintainability of system.
Konkuk University 7 Elements of SASD
Essential Model
Environmental Behavioral Model Model
Implementation Model
Konkuk University 8 Essential Model
• MdlModel o f what thdhe system must do
• Not define how the system will accomplish its purpose .
• A combination of environmental and behavioral models
Essential Model
Environmental Behavioral Model Model
Konkuk University 9 Environmental Model
• DfiDefines t he scope ofhf the proposed system.
• Defines the boundary and interaction between the system and the outside world.
• Composed of – Statement of purpose – System Context diagram – Event list
Konkuk University 10 Behavioral Model
• MdlModel o fhf the ilbhiinternal behavior and diidata entities ofhf the system
• Models functional requirements.
• Composed of – Data Dictionary – Data Flow Diagram (DFD) – Entity Relationship Diagram (ERD) – Process Specification – State Transition Diagram
Konkuk University 11 Implementation Model
• MhfiliMaps the functional requirements to hddfhardware and software. • Minimizes the cost of the development and maintenance. • Determines which functions should be manual vs. automated. • Can be used to discuss the cost-benefits of functionality with user/stakeholders. • Defines the Human-Computer interface. • Defines non-functional requirements.
• Composed of – Structure Charts
Konkuk University 12 SASD Process
Activity
Environmental Model
Statement of Purpose System Context Diagram
Event List Behavioral Model
Data Dictionary
ERD
DFD Process Specification
State Transition Implementation Diagram Model
Structured Chart
Time
Konkuk University 13 Statement of Purpose
• AlA clear an d conc ise textua ldl descr iiiption o fhf the purpose for t he system to develop • It should be deliberatelyyg vague. • It is intended for top level management, user management and others who are not directly involved in the system.
Konkuk University 14 Statement of Purpose – RVC Example
Robot Vacuum Cleaner (RVC)
- An RVC automatically cleans and mops household surface. - It goes straight forward while cleaning. - If its sensors found an obstacle, it stops cleaning, turns aside , and goes forward with cleaning. - If it detects dust, power up the cleaning for a while - We do not consider the detail design and implementation on HW controls. - We only focus on the automatic cleaning function.
Konkuk University 15 System Context Diagram
• HiHighligh hli hts th e b ound ary b etween th e system and outsid e world . • Highlights the people, organizations and outside systems that interact with the syypstem under development.
• A special case of DFD
Konkuk University 16 System Context Diagram - Notation
Process : represents the proposed system
Terminator : represents the external entities
Flow : represents the in/out data flows
Konkuk University 17 System Context Diagram – RVC Example
Motor
RVC Sensor Control
Cleaner
Konkuk University 18 Event List
• AliA list o f t he event /st imu li outs ide o f t he system to w hihihich it must respond. • Used to describe the context diagram in details.
• Types of events – Flow-oriented event : triggered by incoming data – Temporal event : triggered by internal clock – Control event : triggered by an external unpredictable event
Konkuk University 19 Event List – RVC Example
Input/ Output Event Description
Front Sensor Input Detects obstacles in front of the RVC
Left Sensor Input Detects obstacles in the left side of the RVC periodically
Right Sensor Input Detects obstacles in the right side of the RVC periodically
Dust Sensor Input Detects dust on the floor periodically
Direction commands to the motor Direction (go forward / turn left with an angle / turn right with an angle)
Clean Turn off / Turn on / Power-Up
Context Diagram for RVC Konkuk University 20 System Context Diagram – RVC Example
Direction Motor Front Sensor Input Left Sensor Input Right Sensor Input Dust Sensor Input RVC Sensor Control
Clean
Cleaner
Konkuk University 21 Data Flow Diagram (DFD)
• PidProvides a means f ffor funct iona ldl decompos iiition. • Composed of hierarchies(levels) of DFDs.
• Notation (A kind of CDFD)
Data Process
Data Flow
Control Process
Control Flow TiTerminator
Data Store
Konkuk University 22 DFD Level 0 – RVC Example
Front Sensor Front Sensor Input Direction Motor
Left Sensor Left Sensor Input RVC Right Sensor Control Right Sensor Input 0 Clean
Dust Sensor Dust Sensor Input Cleaner Tick
Digital Clock
Konkuk University 23 DFD Level 0 – RVC Example
(A kind of) Data Dictionary
Input/ Output Description Format / Type Event
Front Sensor Input Detects obstacles in front of the RVC True / False , Interrupt
Left Sensor Input Detects obstacles in the left side of the RVC periodically True / False , Periodic
Right Sensor Input Detects obstacles in the right side of the RVC periodically True / False , Periodic
Dust Sensor Input Detects dust on the floor periodically True / False , Periodic
Direction commands to the motor Direction Forward / Left / Right / Stop (go forward / turn left with an angle / turn right with an angle)
Clean Turn off / Turn on / Power-Up On / Off / Up
Konkuk University 24 DFD Level 1 – RVC Example
Front Sensor Input Direction
Left Sensor Input Obstacle Cleaner & & Dust Obstacle & Dust Motor Right Sensor Detection Location Control Input 1 2 Clean
Dust Sensor Input
Tick
Konkuk University 25 DFD Level 2 – RVC Example
Front Sensor Input Front Sensor Interface Front Obstacle 1.1
Left Sensor Input Left Determine Left Obstacle Obstacle Sensor Obstacle Interface LtiLocation Location Tick 1.2 1.5
Rig ht Right Sensor Input Sensor Right Obstacle Interface 1.3 Determine Tick Dust Dust Existence Existence Dust 1.6 Dust Sensor Input Sensor Dust Existence Interface 1.4
Tick Konkuk University 26 DFD Level 2 – RVC Example
Direction Motor Motor Command Interface 2.2 Obstacle Location Main Control 2.1 Dust Existence Cleaner Clean Cleaner Command Interface 2.3
Tick
Konkuk University 27 DFD Level 3 – RVC Example
Tick Move Motor Command Forward Enable 2122.1.2
Obstacle Disable Location
Controller Trigger MtMotor Comman d 2.1.1 Turn Left 2.1.3 Tick Dust Trigger Existence Tick
Turn Motor Command Right 2142.1.4 Cleaner Command
Konkuk University 28 DFD Level 4 – RVC Example
State Transition Diagram for Controller 2 .1 .1
/ Enable “Move Forward”, Cleaner Command (On)
Move Forward Tick [F && !L] Tick [F && !R] / Disable “Move Forward”, / Disable “Move Forward”, Cleaner Command (Off), Cleaner Command (Off), Trigger “Turn Left” Trigger “Turn Right”
Tick Tick /Enable/ Enable “Move Forward ”, /Enable/ Enable “Move Forward ”, Cleaner Command (On) Cleaner Command (On)
Turn Left Turn Right
Tick [F && L && R] / Disable “Move Forward”, Cleaner Command (Off), Many problems in this model: 1. “Stop” state Stop 2. Do not consider “Dust” 3. … Konkuk University 29 DFD – RVC Example
Konkuk University 30 Process Specification
• Shows process d etail s w hich are i mpli ed b ut not sh own i n a DFD . • Specifies the input, output, and algorithm of a module in a DFD. • Normally written in pseudo-code or table format .
• Example – “Apply Payment”
For all payments If payment is to be applied today or earlier and has not yet been applied Read account Read amount Add amount to account’s open to buy Add amount to account ’s balance Update payment as applied
Zhou Qun, Kendra Hamilton, and Ibrahim Jadalowen (2002)
Konkuk University 31 Process Specification – RVC Example
Reference No. 1.2
Name Left Sensor Interface
Input Left Sensor Input (+Data structure if possible) , Tick
OtOutpu t LftLeft Obs tacl e (Dt(+Datastt)tructure)
“Left Sensor Input” process reads a analog value of the left sensor Process Description periodically, converts it into a digital value such as True/False, and assigns it into output variable “Left Obstacle.”
Konkuk University 32 Data Dictionary
• DfiDefines data e lements to avo iddiffid different interpretat ions. • Not used widely in recent years.
• Example [Yourdon 1989] A: What’s a name? B: Well, you know, it’s just a name. It’s what we call each other. A: Does that mean you can call them something different when you are angry or happy? B: No, o f course no t. A name is the same a ll the time. A: Now I understand. My name is 3.141592653. B: Oh your name is PI…But that’s a number, not a name. But what about your first and last name. Or, is your first name 3 and your last name 141592653?
Konkuk University 33 Data Dictionary
• NiNotation – = : is composed of – + : and – ( ) : optional element – { } : iteration – [ ] : selects one of the elements list – | : separation of elements choice – ** : comments – @ : identifier for a store (unique ID)
Konkuk University 34 Data Dictionary
• ElExample – Element Name = Card Number – Definition = *Uniquely identifies a card* – Alias = None – Format = LD+LD+LD+LD+SP+LD+LD+LD+LD+SP+ LD+LD+LD+LD+SP+LD+LD+LD+LD – SP = “ ” *Space* – LD = {0-9} *Legal Digits* – Range = 5191 0000 0000 0000 ~ 5191 9999 9999 9999
Konkuk University 35 Entity Relationship Diagram (ERD)
• AhilA graphical representat ifhdlion of the data layout o f a system at a high level of abstraction • Defines data elements and their inter-relationshippys in the system. • Similar with the class diagram in UML.
• Notation (Original)
Associated Object
Data Element Cardinality – Exactly one
Cardinality – Zero or one
Relationship Cardinality – Mandatory Many
Cardinality – Optional Many
Konkuk University 36 Entity Relationship Diagram - Example
Konkuk University 37 State Transition Diagram
• Shows th e ti me ord eri ng b etween processes. • More primitive than the Statechart diagram in UML. • Different from the State transition diagram used in DFD . • Not widely used.
• Notation
Objects Transitions
Konkuk University 38 State Transition Diagram - Example
Konkuk University 39 Practice
• ClhRVCliiComplete the RVC analysis in more d diletails. – Consider the “Dust”. – You may have several controller.
Konkuk University 40 Structure Charts
• SdDi(SD)Structured Design (SD)
• Functional decomposition (Divide and Conquer) – Information hiding – Modularity – Low coupling – High internal cohesion
• Needs a transform analysis.
Konkuk University 41 Structured Charts – Transform Analysis
Afferent Flow Central Transformation Efferent Flow (Input) (Control) (Output)
Konkuk University 42 Structured Charts – Transform Analysis
Input Process Output (Afferent Flow) (Cent ral T ransf ormati on) (Efferent Flow)
Control
Input Process Output
Konkuk University 43 Structured Charts – Notation
Basic Notation [Yourdon 1989] Variations Modules
Data module
Library modules Asynchronous module call
Module call Iteration
Data Flow Decision
Control Flow
Konkuk University 44 Structured Charts - Example
Zhou Qun, Kendra Hamilton, and Ibrahim Jadalowen (2002)
Konkuk University 45 Structured Charts – RVC Example (Basic)
Main
Controller
Obstacle Location Dust Existence
Enable Trigger Trigger Disable Determine Determine Obstacle Location Dust Existence
Front Sensor Left Sensor Right Sensor Dust Sensor Move Forward Turn Left Turn Right Interface Interface Interface Interface
Konkuk University 46 Structured Charts – RVC Example (Advanced)
Main
Controller
Obstacle Location
Dust Existence
Trigger Determine Determine Enable Obstacle Location Dust Existence Disable
Trigger
Front Sensor Left Sensor Right Sensor Dust Sensor Move Forward Turn Left Turn Right Interface Interface Interface Interface
Konkuk University 47 Pros of SASD
• Has di sti nct mil estones, a llow ing eas ier pro ject management tracking. • Very visual – easier for users/prog rammers to understand • Makes good use of graphical tools • Well known in industry • A mature technique • Process-oriented way is a natural way of thinking • Flexible • Provides a means of requirements validation • Relativelyyp simple and easy to read
Konkuk University 48 Pros of SASD
• SCSystem Context Di agram – Provides a black box overview of the system and the environment
• Event List – Provides a guidance for functionality – Provides a list of system inputs and outputs – A means of requirements summarization – Can be used to define test cases (as we will see soon.)
• Data Flow Diagram (DFD) – Ability to represent data flows – FtildFunctional decompositi iti(diiddon (divide and conquer)
Konkuk University 49 Pros of SASD
• DDiiData Dictionary – Simplifies data requirements – Used at high or low level analysis
• Entity Relationship Diagram (ERD) – Commonly used and well understood – A graphical tool, so easy to read by analysts – Data objects and relationships are portrayed independently from the process – Can be used to design database architecture – Effective tool to communicate with DBAs
• Process Specification – Expresses the process specifications in a form that can be verified
Konkuk University 50 Pros of SASD
• STiiDiState Transition Diagrams – Models real-time behavior of the processes in the DFD
• Structure Charts – Modularity improves the system maintainability – Provides a means for transition from analysis to design – Provides a synchronous hierarchy of modules
Konkuk University 51 Cons of SASD
• IIgnores non-filfunctional requ irements. • Minimal management involvement • Non-iterative – waterfall approach • Not enough use-analysts interaction • Does not provide a communication process with users. • Hard to decide when to stop decomposing. • Does not address stakeholders’ needs. • DkllihObjDoes not work well with Object-OiOriente d programm ing languages.
Konkuk University 52 Cons of SASD
• SCSystem Context Di agram – Does not provide a specific means to determine the scope of the system.
• Event List – Does not define all functionalities. – Does not define specific mechanism for event interactions.
• Data Flow Diagram (DFD) – WkdilWeak display of fit/t input/output tdtil details – Confused for users to understand. – Does not represent time. – NiNo imp lidlied sequenc ing – Assigns data stores in the early analysis phase without much deliberation.
Konkuk University 53 Cons of SASD
• DDiiData Dictionary – No functional details – Formal language is confusing to users.
• Entity Relationship Diagram (ERD) – May be confused for users due to its formal notation. – Become complex in large systems.
• Structure Chart – Does not work well for asynchronous processes such as networks. – Could be too large to be effectively understood with larger programs.
Konkuk University 54 Cons of SASD
• PSifiiProcess Specification – They may be too technical for users to understand. – Difficult to stay away from the current “How to implement.”
• State Transition Diagram – Explains what action causes a state change, but not when or how often.
Konkuk University 55 When to use SASD?
• WllWell-kbldiknown problem domains • Contract projects where SRS should be specified in details • Real-time systems • Transaction processing systems • Not appropriate when time to market is short.
• In recent years, SASD is widely used in developing real-time embedded systems.
Konkuk University 56 SASD vs . OOAD
• Sim ilar it ies – The both have started off from programming techniques. – The both use graphical design and tools to analyze and model requirements. – The both provide a systematic step-by-step process for developers. – The both focus on the documentation of requirements.
• Differences – SASD is process-oriented. – OOAD is data(object)-oriented. – OOAD encapsulates as much of the system’s data and processes into objects, – While SASD separates them as possible as it can.
Konkuk University 57 Class Questions
• What i s your opi ni on on ? – Does it reduce maintainability costs? – Is it useful? – Is it efficient? – Is it appropriate for E-commerce(business) development?
• What is SASD’s target domain?
Konkuk University 58 Summary
• SASD is a process-didriven so ftware ana llys is tec hn ique. • SASD has a long history in the industry and it is very mature. • It provides a good documentation for requirements . • In recent years, it is widely used for developing real-time embedded system’s software.
SASD
Konkuk University 59 Final Presentation (OOAD vs. SASD)
• ElihEnglish presentati on
• Compare OOAD with SASD using your elevator controller team project. – Pros and Cons of SASD and OOAD for developing elevator controllers respectively – Your opinion and suggestion!!!
Konkuk University 60