Lecture: Structured Analysis and Design
Published Sunday, March 26, 2006 by Mathieu | E-mail this post
Structured Analysis and Design
First texts were in 1977.
1989 SA reaches it's peak. Yourdon publishes Modern Structured Analysis. He moved to Object-Oriented analysis in 91 though.
Context Diagrams
Shows the people, orgs and sys which comm with our sys. Ugh what an ugly sentence!
What does the black box do?
User Documentation tells you what the system does, not how it does it.
Defines boundaries between it and the rest of the world.
There are some other ones. But you get the picture. you have to draw different icons.
-The system
-Terminators
-Data flows
-Data Stores.
For large systems with large flows of information between entities, there is a limited amount that you can show in one diagram.
Rather than have heaps of arrows, have a student performing a range of tasks and use more than one terminator.
Event lists - things that occur in the outside world which affect the system.
Flow of Data
Temporal Event
Control
Examine each terminator to look at what effects they can have on the system.
Take care to distinguish between separate events coincidentally "packaged" together in the req. spec.
Need to allow for failure conditions of the terminators, but not that of the system.
Data Flow Diagrams extend the CD by defining processes which make up a system.
Indicates packets of information in and out of entities.
We can have diverging data flows as well.
Figure 0 DFDs tell us know what's happening inside the black box. So by definition, this is actually design. We're not just thinking about how it interacts with the world anymore, we're thinking about what is happening inside.
Then the next thing we do is an analysis of a subsystem component.
All this is why people have difficulty separating analysis and design.
When constructing DFDs
Choose meaningful names
Yordon's book (online) talks about all this stuff.
Number the processes to indicate some sequence.
Use aesthetics. Redraw it if needed.
Fir on one A4 page. Approx. 6-7 processes and related data stories and terminators.
Is this pretty much what I have been doing?
Make sure the DFD is internally consistent with any other associated DFDs.
Control Flows and Processes
Need a means to model control (signals / interrupts).
Shown with dashed lines and circles.
Most systems are far too complex to depict on one DFD.
So we divide and conquer, like good CS people.
This is design. How do we break it up? We make the best decision that we can. Breaking it up into sub processes.
Assignment 1.
Assumptions page
Rationale
(say you have text boxes... explain why you chose text boxes over other designs).
First texts were in 1977.
1989 SA reaches it's peak. Yourdon publishes Modern Structured Analysis. He moved to Object-Oriented analysis in 91 though.
Context Diagrams
Shows the people, orgs and sys which comm with our sys. Ugh what an ugly sentence!
What does the black box do?
User Documentation tells you what the system does, not how it does it.
Defines boundaries between it and the rest of the world.
There are some other ones. But you get the picture. you have to draw different icons.
-The system
-Terminators
-Data flows
-Data Stores.
For large systems with large flows of information between entities, there is a limited amount that you can show in one diagram.
Rather than have heaps of arrows, have a student performing a range of tasks and use more than one terminator.
Event lists - things that occur in the outside world which affect the system.
Flow of Data
Temporal Event
Control
Examine each terminator to look at what effects they can have on the system.
Take care to distinguish between separate events coincidentally "packaged" together in the req. spec.
Need to allow for failure conditions of the terminators, but not that of the system.
Data Flow Diagrams extend the CD by defining processes which make up a system.
Indicates packets of information in and out of entities.
We can have diverging data flows as well.
Figure 0 DFDs tell us know what's happening inside the black box. So by definition, this is actually design. We're not just thinking about how it interacts with the world anymore, we're thinking about what is happening inside.
Then the next thing we do is an analysis of a subsystem component.
All this is why people have difficulty separating analysis and design.
When constructing DFDs
Choose meaningful names
Yordon's book (online) talks about all this stuff.
Number the processes to indicate some sequence.
Use aesthetics. Redraw it if needed.
Fir on one A4 page. Approx. 6-7 processes and related data stories and terminators.
Is this pretty much what I have been doing?
Make sure the DFD is internally consistent with any other associated DFDs.
Control Flows and Processes
Need a means to model control (signals / interrupts).
Shown with dashed lines and circles.
Most systems are far too complex to depict on one DFD.
So we divide and conquer, like good CS people.
This is design. How do we break it up? We make the best decision that we can. Breaking it up into sub processes.
Assignment 1.
Assumptions page
Rationale
(say you have text boxes... explain why you chose text boxes over other designs).
0 Responses to “Lecture: Structured Analysis and Design”
Leave a Reply