- The Seven Basic Principles
- Scope of Subject Matter That Can Be Handled by IDEF0
- Benefits Resulting from the Use of IDEF0
- Features of IDEF0 Analysis
- Comparison to Data Flow Diagramming
- Understanding a Top-Level IDEF0 Diagram of an Enterprise
- Levels of Abstraction in IDEF0 Models
- The Role of Data Analysis Compared to IDEF0 Function Analysis
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Role of Data Analysis Compared to IDEF0 Function Analysis
Detail needed regarding the processes requires not only IDEF0 process models, but also precise information about the arrow content. This requires a careful analysis of data.
An analyst may be confronted with a tidal wave of raw data when he first gathers information about an enterprise. He typically starts by finding out the precise meaning of the terms that are key to the system’s operation; then he documents these definitions. Once he has done that, he has a solid basis for initiating discussion with the staff about the detailed operation of the system. But even before analyzing the system in detail, he must consider the system functions and their interactions to understand the need, the purpose, and the objective of the relevant data.
Not all analysts take this view. In fact, some prominent leaders in the database community have stated that there is no need to look at the functions and activities at all. One database proponent wrote that the development of a function model actually gets in the way of the programmer and should be avoided if possible, further proclaiming his First Rule of CASE: “Only one diagramming method is needed—the data model—and code can be generated automatically from a data model.”1
This statement is true if the automated system to be built performs simple, well-known processes such as basic banking transactions (for example, put money in checking account, withdraw money from checking account, transfer money to savings account, and so on). These activities are so familiar that an IDEF0 model would not be helpful, and design of the data structure of the system can be started almost immediately. The statement is not true, however, if the software to be built has a complex processing aspect, such as that for an avionics system or a computer’s operating system.
The field of automated programming would also lead one to believe that analysis, design, and programming are outmoded—as if the system will do all this for you and produce a running computer program. However, the type of system that is implied here is one that simply queries a database and displays answers on a screen. Automatic programming has a long way to go before it can build an avionics system, a computer operating system, or a compiler. And haven’t we slipped into the solution domain? Automated programming tools are of no help if you are trying to reengineer a business operation and have not yet understood what the system will look like.
Regardless of the system to be analyzed and the comparative importance of the data versus the activity analysis, at some point the data must be analyzed. To perform this portion of the analysis, the analyst must understand several important characteristics of the data.
Although there are many data characteristics that could be analyzed, two are critical: data dynamics and data structure. Data dynamics can be depicted by SADT data models, using a portion of SADT that was not adopted by the Air Force for IDEF0. Data structure may be modeled using IDEF1X, where the term “structure” signifies all non-dynamic data information, such as its attributes and its relationship to other data elements.
A type of function model, the SADT data model shows the breakdown of the kinds of data in the system, with arrows indicating which activities produce which data elements and which activities use the data for what purpose. This gives a dynamic picture of the data being created, used, and merged with other data to form new data entities. The SADT data model is a natural companion for an IDEF0 or SADT activity model, and it is useful for analyzing how the system manipulates data and what is affected when changes are implemented. It also provides a validation of the activity model. In fact, most data models developed using SADT result in corrections to the activity model!
The IDEF1X model provides all of the structural information about the data. Ultimately, relating the need for and the usage of specific attributes of data by the activity boxes of an IDEF0 model is the key to integrating the two models.