Process-Oriented Design
The goal of design is to map the requirements of the application to a hardware and software environment. The result of process-oriented analysis – data flow diagrams, data dictionary entities, and so on – is translated into detailed specifications for hardware and software. The main output of process-oriented design includes structure charts, physical databases, and program specifications.
In this chapter, you will learn about the concepts and terminologies for process-oriented design and the steps of process-oriented design, including transaction analysis, transform analysis, and structure charts, as well as physical database design, program packages, and program design. You will also learn about the strengths
and weaknesses of process-oriented design.
6. Strengths and Weaknesses of Process Analysis and Design Methodologies
The objectives of structured analysis and design are reasonably clear; the manner of obtaining the objectives is much less clear. Structured methods rely on the individual SE's expertise to design the technical details of the application. For implementation specific details, that makes sense, but the heuristics for evaluation cannot be applied in every situation. Consequently, the SE must know what situations apply and don't apply. More than the other methods discussed in this book, you must know when to adhere to, bend, and break the rules of structured methods.
The methodology's ability to result in minimal coupling and maximal cohesion is low because of its reliance on the SE's ability. If coupling and cohesion are not optimal, maintenance will cost more than it should, and the application will be difficult to test. In 1972, D. Parnas wrote about maximal cohesion and minimal coupling as desirable characteristics of programs. In 1968, Dijkstra wrote about the problems with 'go to' statements in programs and proposed goto-Iess programming. In 1966, Bohm and Jacopini proposed structured programming's minimalist contents as sequence, iteration (e.g., if ... then ... else) and selection (e.g., do while and do until). By the time structured analysis and design were documented in books, the notions of coupling and cohesion were understood fairly well; but how to obtain them was not.
| Product | Company | Technique |
|---|---|---|
| PacBase ProKitVVorkbench ProMod SVV Thru Pictures System Architect Teamwork Visible Analyst Telon, and other products vs Designer |
CGI Systems, Inc. Pearl River, NY McDonnell Douglas St. Louis, MO Promod, Inc. Lake Forest, CA Interactive Dev. Env. San Francisco, CA Popkin Software and Systems, Inc. NY, NY Cadre Technologies, Inc. Providence, RI Visible Systems Corp. Newton, MA Intersolv, Cambridge, MA Visual Software, Inc. Santa Clara, CA |
Process Decomposition Structure Chart Flowchart Structure Chart Module Networks Function Networks Structure Chart Flowchart Structure Chart Control Flow Decision Table Structure Chart Structure Chart Code Generation for Cobol-SQL, C, and others Structure Chart Warnier-Orr |
General statements about keeping the pieces small and related to one part of the problem domain rely on the analyst to know what to do and when to start and stop doing it. Unfortunately, only experience can guide such vague suggestions. While novices can learn to rely on the methodology to guide their actions, they have no basis for evaluating the correctness or incorrectness of their work. Thus, the apprenticeship approach, with a junior person working with a more senior one to learn how to evaluate designs, is required. The more complex the application, the more important having experienced senior analysts becomes.
Another problem is that structured design does not encompass enough of the activities to make it a complete methodology. We must have screen designs in order to develop a program specification. We must know the details of interfaces to other applications
and messages to/from them to be able to develop program specifications. Structured methods do not pay any attention to either of these issues. To develop an application, the SE needs to analyze requirements and design for control, input, output, security,
and recoverability. None of these are encompassed in the process-oriented methods. To summarize, process methods are useful in analyzing and designing applications that are procedural in nature; but the methods omit a great many required analysis
and design activities.