What are the important data items?
What abstract informal concepts do they relate to?
What are their relations to the modules just identified?
For example, in the multitasking window example (you may refer to the previous article for details), the analyst might find a process table containing entries that describe the processes currently running under the multitasker. The more experience the analyst has with multitasking systems, the richer the set of expectations that he or she will have about such a system.
What are the software engineering artifacts? The understanding process recreates the software engineering oriented design artifacts and expresses them wherever possible in terms of the module and data abstractions recovered earlier. The specific artifacts captured are determined to some extents by the process model adopted by the programming organization. For example, some companies will use a program description language, dataflow, module refinement, and a simple data dictionary. Others will depend on different design artifacts.
What are the other informal design abstractions? For the set of abstractions to be really effective, we need other information structures, many of which are not as well defined and formal as the software engineering-oriented design artifacts. For example, design rationale might be useful, perhaps stated in terms of issue-based information systems (IBIS) nets. Further, natural language prose is unavoidable if we want a really effective model of the design. Similarly, informal diagrams describing abstract views of the target systems are often quite useful. Thus we must expect to recover a wide variety of design artifacts that contain a mixture of formal and informal information.
What is the relation of the design abstractions to the code? After recovering the artifacts, we must preserve the relationships among them. That is, once we determine that a context switch is being performed within some dataflow diagram, we would like to know which chunk of code performs it. Code analysis of a concrete example is often required to answer questions that depend on low-level details abstracted out of the dataflow diagram. Once an engineer establishes this abstraction-to-code link, he or she will have an organized, "in head" framework (the abstraction) in which to put the code oriented details and, perhaps more importantly, a set of organized structures to help interpret those details. Thus, the engineer can understand the code in terms of the abstractions in the framework.
Go To Page: 1 2
