Download
1 / 43
430 likes | 618 Views
System Analysis & Design. Lesson 06 Traditional Design Techniques. In this lesson we will Describe the steps involved in the Traditional Approach to designing the Application Architecture Develop a System Flowchart
E N D
System Analysis & Design Lesson 06 Traditional Design Techniques
In this lesson we will • Describe the steps involved in the Traditional Approach to designing the Application Architecture • Develop a System Flowchart • Develop a Structure Chart using transaction analysis and transform analysis • Write Pseudocode for structured modules
Structured Approach to Design How to approach the Design of the Application …
The Structured Approach to Application Architecture design is very straightforward • Any Application programs which have been identified (or will be identified) as being part of the solution • Are designed in conjunction with their database and UI components • Are broken down into a hierarchy of (supporting) modules • As modules are identified, their internal logic is documented and designed • One common way of tackling this structured approach is known as the top-down approach
In the Analysis Phase of the Traditional Approach you should have developed DFD Diagrams • These diagrams show all external agents who act upon or require the system • As well in developing the DFD diagrams it may (or should have) become obvious what sub-systems exist within the overall system • By analyzing the diagrams it might be possible to see which application program(s) need to be created for each sub-system • And how these program(s) need to interact with each other to perform the task of the sub-system • This analysis will also show how the various sub-systems interact with each other in order to perform the overall system task • One simple technique to show this information within the DFDs is to overlay markers on the DFDs to indicate the Automation System Boundaries • These boundaries are nothing more that the grouping of processes into sub-systems, and grouping of processes within a sub-system into individual applications / programs • Once the automation boundaries have been identified, we can begin to create the Design models for the system
Automation System Boundary Finding and Defining it …
As mentioned, the Automation System Boundary indicates many things to us as architects / designers • Partitions DFD processes into manual processes and automated systems • Processes can be inside or outside of the boundary • Data flows (the DFD interactions) can be inside and outside of boundary • Data flows that cross the system boundary represent inputs and outputs of system (or subsystem depending on which boundary you are looking at) • Data flows that cross boundaries between programs represent program-to-program communication
Structured Design Models The System Flowchart …
The System Flowchart is a tried and true model used in Systems Design for many, many years • Representation of various computer programs, files, databases, and associated manual processes that make up complete system • Although technically it is a Design Model, the system flowchart is frequently constructed during analysis activities • The flowchart graphically describes the organization of subsystems into automated and manual components • The flowchart can show the type of transaction processing within the system • Batch or Real-Time (Online) • Typically System Flowcharts are used in the design of larger systems – comprised of multiple sub-systems and multiple programs
The System Flowchart provides us (as architects and designers) with an important first step … • Having arrived at the flowchart by revisiting our Analysis DFDs and modifying them to show the System Automation and Program Automation Boundaries • We have now arranged our Analysis phase DFD processes into different programs and arranged them within the sub-systems • The flowchart is out first glance at the architecture of the system we are about to design • It shows us the programs within the system, the input and output of the system, how the programs work together and where the data is flowing, being stored and being manipulated within the system
Structured Design Models The Structure Chart …
The Structure Chart offers a different view of the system that may not be apparent in the flowchart • It is a model which allows us to breakdown the identified operations, processes and programs within the system and sub-systems into their supporting functions • Operations, Processes, Programs and their functions are all called modules in the Structure Chart • Structure Charts show relationships between the various modules of a computer program • The Structure Chart also shows information flowing between the various modules • It can show where data is created, modified and used • They also capture key trigger points and trigger data within the module and program (called control flags)
The Structure Chart has a simple and direct organization • Each module performs a specific function • Each layer the chart performs specific activities • The chart is tree-like with a root module and branches • The modules at the lowest level of the hierarchy are called the leaves • The charts are drawn and interpreted in a top-to-bottom, left-to-right fashion • Meaning that execution begins in the top layer of the chart • And if 2 modules exist at the same level of a structure chart, the one to the left is invoked / executed first …
The Structure Chart How do we develop them?
In order to develop a Structure Chart, we require a set of DFD diagrams as well as the System Flowchart. • Using these models the structure chart results from two types of analysis : Transaction Analysis and Transform Analysis Transaction Analysis • Uses the System Flow Chart and Event Table as inputs • This analysis helps identify the upper-level modules of the Structure Chart • This analysis identifies each transaction supported by a module Transform Analysis • Uses DFD Fragment Diagrams for inputs • This analysis shows how each of the upper-level modules transform inputs into outputs and fulfills its part of the transaction • The resulting Structure Charts have input, calculate, and output sub-trees
Let’s say we wanted to start the design of our Purchasing System by examining the Ordering Sub-System … what do we have to help us ? • We have our Event Table and CRUD Analysis for the Purchasing System from the Analysis Phase • And if we were smart, we developed those tables clearly identifying the different sub-systems • We have the Diagram 0 DFD for the Ordering sub-system also from the Analysis Phase • We have the System Flowchart for the Purchasing System that we’ve just created in this Design Phase • If we have analyzed our Ordering Sub-System properly (in the Analysis Phase) then the Diagram 0 shows us all of the high-level modules that will appear in our structure chart • The high-level modules will appear in the first row of the resulting structure chart • So all that is left to do is to determine what the transaction is … hmmmm …
A transaction is an exchange of information between 2 parties • It is important to realize that (like systems and programs) we can view a transaction as a hierarchy of sub-transactions • In our case : • The 2 parties are the customer and the system • The highest level transaction is the order • There may be different ordering styles (online order, phone order) with different end results (home delivery, store delivery, delivery to multiple destinations, etc.) • And a single order can be made up of multiple orders over time … • And these orders are made up of potentially multiple items • What we are trying to do in the transaction analysis is to use the information from our requirements and their analysis (Event Table, CRUS Analysis, DFDs, System Flow Chart) to properly understand and identify the different types of transactions that our system needs to address • When we take our Analysis and Design Phase Model inputs and perform this transaction analysis on them, we arrive at this …
OUTPUT : High-level Structure Chart after Transaction Analysis
What we do in the transform analysis is to diagram how we transform inputs to outputs – for each of the high-level modules in the Structure Chart • Given that each of the high-level modules is represented by a single process in a 1st Level DFD (from the Analysis Phase) we start there • We need to examine this 1st Level DFD to determine primary information flow to determine the input, the transform and the final output • Then we turn our attention to the corresponding 2nd Level DFD and redraw it in a left to right fashion – where the input process is on the left, the final output process is on the right and the central transform processes are in the middle • This restructured 2nd Level DFD maps directly onto the resulting Structure Chart • The following example will highlight this process • The first diagram is a 1st Level DFD Fragment of a Create New Order event • The second diagram is a 2nd Level DFD Fragment of the same event • The third diagram is the rearranged DFD Fragment • The fourth diagram is the first draft of a Structure Chart
Now that we have the 1st draft of the Structure Chart • We can begin to do this for other high-level modules. Modules to • Get input data via UI screens • Read from and write to data storage • Write output data or reports • Add logic from structured English or decision tables (Lesson 3) • Module after module, we create the Structure Charts to describe the process. • Each new part of the Structure Chart is added to the 1st draft • Once all modules have been added, you can make final refinements • Based on quality control concepts : Coupling and Cohesion (from SEF last term) • Goal : Loose Coupling (a module doesn’t depend too much on other modules) and High Cohesion (one module should concentrate on only one task) • The final Structure Chart comes by combining the transaction analysis chart with the transform analysis chart for all modules and sub-systems
Create New Order Program – final Transform Analysis Structure Chart
Algorithm Design Developing Pseudo-code …
Some view the process of developing and documenting pseudo-code a waste of time. This is not necessarily the case … pseudo-code is : • Used to describe internal logic of software modules • A variation of Structured English (from Lesson 03) that is closer to programming code • In pseudo-code, the syntax can and should mirror development language of choice • Used to show at least three types of control statements (also found in structured programming) • Sequence– sequence of executable statements • Decision– if-then-else logic • Iteration– do-until or do-while • There are no standards to indicate how complete or defined your pseudo-code needs to be • Only you know how much detail is enough to describe an algorithm
As mentioned, the classic approach to Traditional Design is the top-down approach • What we have covered in this lesson allows architects and designers to take a system and • Break it down into functional sub-systems • This may have already been done in the Analysis Phase • But it is reinforced through the creation of the System Flow Chart where the various modules of the system are identified • Remember a module may be a manual operation, a program or a process • Break each sub-system down into its functional modules • This is accomplished by performing Transaction and Transform Analysis to produce the Structure Chart • Describe each of these functional modules using pseudo-code
