Fishwick P.A. (editor) Handbook of Dynamic System Modeling
Подождите немного. Документ загружается.
4-4 Handbook of Dynamic System Modeling
The key words in this definition are formulation, analysis, and interpretation. In fact, all of systems
engineering can be thought of as consisting of formulation, analysis, and interpretation efforts, together
with the systems management and technical direction efforts necessary to bring this about. We may
exercise these in a formal sense, or in an as if or experientially based intuitive sense. These are the stepwise
or microlevel components that comprise a part of the structural framework for systems engineering.
Finally, we can think of a functional definition of systems engineering. Systems engineering is the art and
science of producing a product, based on phased efforts, that satisfies user needs. The system is functional,
reliable, of high quality, and trustworthy; and has been developed within cost and time constraints through
the use of an appropriate set of methods and tools.
In our first definition of systems engineering, we indicated that systems engineers are concerned with
the appropriate definition, development, and deployment of systems. These comprise a set of phases
for a systems engineering life cycle, as actually illustrated within the systems acquisition, production, or
procurement life cycle of Figure 4.2. There are many ways to describe the life-cycle phases of the systems
engineering process, and we have described a number of them in Sage (1992a, 1992b). Each of these basic
life-cycle models, and those which are outgrowths of them, comprises these three phases. For pragmatic
reasons, a typical life cycle will almost always contain more than three phases. Generally, it takes on the
“waterfall” pattern illustrated in many works, although there are a number of modifications of the basic
waterfall, or grand-design life cycle, to allow for incremental and evolutionary development of systems, as
discussed in Sage (1992a, 1992b) and many other sources.
4.3 The Importance of Technical Direction and
Systems Management
Systematic measurements are essential for appropriate practice of systems management. The use of the
terms reactive measurements, interactive measurements, and proactive measurements may seem unusual.
We may, however, approach measurement, and systems engineering and management in general, from at
least four perspectives:
1. Inactive: This denotes an organization that does not use metrics, or that does not measure at all
except perhaps in an intuitive and qualitative manner.
2. Reactive: This denotes an organization that will perform an outcome assessment and after it has
detected a problem, or failure, will diagnose the cause of the problem and, often, will get rid of the
symptoms that produce the problem.
3. Interactive: This denotes an organization that will measure an evolving product as it moves through
various phases of the life-cycle process to detect problems as soon as they occur, diagnose their
causes, and correct the difficulty through recycling, feedback, and retrofit to and through that
portion of the life-cycle process in which the problem occurred.
4. Proactive: Proactive measurements are those designed to predict the potential for errors and syn-
thesis of an appropriate life-cycle process that is sufficiently mature such that error potential is
minimized.
We can also refer to the systems management style of an organization as inactive, reactive, interactive, or
proactive. All of these perspectives on measurement purpose, and on systems management, are needed.
Inactive and reactive measurements are associated with organizations that have a low level of process
maturity. As one moves to further higher levels of process maturity, the lower level forms of measurements
become less used. In part, this is so because a high level of process maturity results in such appropriate
metrics for systems management that final product errors, which can be detected through a reactive
measurement approach, tend to occur very infrequently. While reactive measurement approaches are
used, they are not at all the dominant focus of measurement. In a very highly mature organization, they
might be only needed on the rarest of occasions. In many situations, models and associated simulations of
Systems Engineering 4-5
systems are needed to obtain measurements from these, especially when we are in the preliminary design
and architecting phases of a systems engineering effort and the actual system has yet to be engineered,
even in a preliminary manner.
Management of the systems engineering processes, which we call systems management, is very essential
for success. There are many evidences of systems engineering failures at the level of systems management.
Often, one result of these failures is that the purpose, function, and structure of a new system are not
identified sufficiently before the system is defined, developed, and deployed. These failures, generally, are
the result of costly mistakes that could truly have been avoided. A major objective of systems engineering,
at the strategic level of systems management, is to take proactive measures to avoid these difficulties.
Concerns associated with the definition, development, and deployment of tools such that they can be
used efficiently and effectively have always been addressed, but often this has been on an implicit and“trial-
and-error” basis. When tool designers were also tool users, which was more often than not the case for the
simple tools, machines, and products of the past, the resulting designs were often good initially, or soon
evolved into good designs through this trial-and-error effort. When physical tools, machines, and systems
become so complex that it is no longer possible to design them by a single individual who might even also
be the intended user of the tool, and a design team is necessary, then a host of new problems emerge. This is
very much the condition today and it is especially the case with respect to system models and simulations.
To cope with this, a number of methodologies associated with systems engineering have evolved. Through
these, it has been possible to decompose large design issues into smaller component subsystem design
issues, design the subsystems, and then build the complete system as a collection of these subsystems.
These phased efforts of definition, development, and deployment represent the macro structure of a
systems engineering framework. Each of them need to be employed for each of the three life cycles of
formulation, analysis, and interpretation. Thus, we see that our relatively simple description of systems
engineering is becoming more and more complex.
Figure 4.3 illustrates how these three steps, three phases, and three life cycles comprise a more complete
methodological, structural, or process-oriented view of systems engineering. Even in this relatively simple
Phases
Deployment
Development
Definition
Formulation
Analysis
Interpretation
Steps
Phases
Deployment
Development
Definition
Formulation
Analysis
Interpretation
Steps
Phases
Deployment
Development
Definition
Formulation
Analysis
Interpretation
Steps
Planning and marketing
life cycle
RDT&E life cycle Acquisition or
production life cycle
FIGURE 4.3 Three iterative systems engineering life cycles and phases and steps within each life cycle. (From Sage,
A.P., Systems Management for Information Technology & Software Engineering, Wiley, Hoboken, NJ, 1995.)
4-6 Handbook of Dynamic System Modeling
methodological framework, which is simultaneously incomplete but relatively complex, we have a total of
27 cells of activity. In a much more realistic view of the steps and phases, as would need to be the case
in actual systems development, we might well have seven phases and seven steps of effort. This yields a
total of 147 cells of activity. Each of the three levels—systems engineering methods, systems engineering
processes, and systems management—are necessarily associated with applicable environments to assure
an appropriate systems engineering process, including the very necessary client interaction during system
definition, development, and deployment. The use of appropriate systems methods and tools as well
as systems methodology (Sage, 1977; Sage and Armstrong, 2000) and systems management constructs
enables system design for more efficient and effective human interaction (Sage, 1987b).
System management and associated architecting and integration issues are of major importance in
achieving effectiveness, efficiency, and overall functionality of systems engineering efforts. To achieve a
high measure of functionality, it must be possible for a system design to be efficiently and effectively
produced, used, maintained, retrofitted, and modified throughout all phases of a life cycle. This life cycle
begins with need conceptualization and identification, through specification of system requirements and
architectures, to ultimate system installation, operational implementation or deployment, evaluation, and
maintenance throughout a productive lifetime.
In reality, there are many difficulties associated with the production of functional, reliable, and trust-
worthy systems of large scale and scope. These potential difficulties, when they are allowed to develop, can
create many problems that are difficult to resolve. Among these are inconsistent, incomplete, and other-
wise imperfect system requirement specifications; system requirements that do not provide for change as
user needs evolve over time; and poorly defined management structures for product design and delivery.
These lead to delivered products that are difficult to use, that do not solve the intended problem, that
operate in an unreliable fashion, that are unmaintainable, and that—as a result—are not used. Sometimes
these failures are so great that operational products and systems are never even fully developed, much less
operationally deployed, before plans for the product or system are abruptly canceled.
These same studies generally show that the major problems associated with the engineering of trustwor-
thy systems, or systems engineering, have a great deal more to do with the organization and management of
complexity than with direct technological concerns that affect individual subsystems and specific physical
science areas. Often the major concern should be more associated with the definition, development, and
use of an appropriate process, or product line, for production of a product than it is with over attention to
the internal design aspects of the actual product itself, in the sense that exclusive attention to the product
or service without appropriate attention to the process leads to the fielding of a low-quality and expensive
product or service. Models of both are needed, of course.
In our previous section, we provided structural, functional, and purposeful definitions of systems
engineering. There are, of course, other definitions. Two closely related and appropriate definitions are
provided by MIL-STD-499A (1974) and MIL-STD-499B (1991), which, although no longer current, have
been the benchmark for many subsequent standards. According to MIL-STD-499B, systems engineering
is “an interdisciplinary approach to evolve and verify an integrated and life-cycle balanced set of system
product and process solutions that satisfy the customers needs. Systems engineering: encompasses the
scientific and engineering efforts related to the development, manufacturing, verification, deployment,
operations, support, and disposal of system products and processes; develops needed user training equip-
ment, procedures, and data; establishes and maintains configuration management of the system; and
develops work breakdown structures and statements of work, and provides information for management
decision making.” This definition attempts to illustrate and combine structural, functional, and purposeful
views of systems engineering. There are many subsequent and reasonably comparable definitions.
We have illustrated three hierarchical levels for systems engineering in Figure 4.1. We now expand on
this to indicate some of the ingredients at each of these levels. The functional definition, or lowest level,
of systems engineering says that we will be concerned with the various tools and techniques and methods
that enable us to design systems. Often, these will be systems science and operations research tools that
enable the formal analysis of systems, including modeling. They can also include specific system design
tools and components. With respect to information technology and software engineering applications,
Systems Engineering 4-7
these would certainly include a variety of computer science and programming tools or methods. It should
be, strictly speaking, more appropriate to refer to these as product-level methods. Then we could also refer
to process methods and systems management methods. When the term “method(s)” is used alone and
without a modifier, what is generally being referred to are product-level methods. The specific nature of
the most useful methods and tools will naturally depend, greatly, on the particular life cycle and life-cycle
phase that is being considered and the particular product, service, or system, that is ultimately to be
acquired.
The functional definition of systems engineering also mentions that we will be concerned with a com-
bination of these tools. In systems engineering, we obtain this combination as the result of using systems
methodology. For our purpose, a methodology is an open set of procedures for problem solving. This
brings about such important notions as appropriate development life cycles, operational quality assurance
issues, and configuration management procedures, which are very important and are discussed in much
more detail in Sage (1992b). Each of these reflects a structural, or methodological, perspective on systems
engineering. How to best bring about these will vary from product to product and across each of the three
life cycles leading to that product or system, or service.
The structural definition of systems engineering tells us that we are concerned with a framework for
problem resolution that, from a formal perspective at least, consists of three fundamental steps: issue
formulation, issue analysis and assessment, and issue interpretation. These are each conducted at each
of the life-cycle phases that have been chosen for definition, development, and deployment. Regardless of
the way in which the systems engineering life-cycle process is characterized, and regardless of the type of
product or system, or service that is being designed, all characterizations of systems engineering life cycles
will necessarily involve (Sage, 1992a, 1992b; Sage, 1982):
1. formulation of the issue—in which the needs and objectives of a client group are identified, and
potentially acceptable alternatives, or options, are identified or generated;
2. analysis and assessment of the alternatives—in which the impacts of the identified options are
identified and evaluated; and
3. interpretation and selection—in which the options, or alternative courses of action, are compared
by means of an evaluation of the impacts of the alternatives and how these are valued by the client
group. The needs and objectives of the client group are necessarily used as a basis for evaluation.
The most acceptable alternative is selected for implementation or further study in a subsequent
phase of systems engineering.
We note these three steps again, because of their great importance in systems engineering. Our model of
the steps of the fine structure of the systems engineering process, is based upon this conceptualization.
These three steps can be disaggregated into a number of others. Each of these steps of systems engineering
is accomplished for each of the life-cycle phases. There are generally three different systems engineering
life cycles. Thus we may imagine a three-dimensional model of systems engineering that comprises steps
associated with each phase of a life cycle, the phases in the life cycle, and the life cycles that comprise the
coarse structure of systems engineering. This is one of the many possible morphological frameworks for
systems engineering (Sage, 1992a).
Without question, we have presented a formal rational model of the way in which these three systems
engineering functions of formulation, analysis, and interpretation are accomplished. Even within this
formal framework, there is the need for much iteration from one step back to an earlier step when it is
discovered that improvements in the results of an earlier step are needed to obtain a quality result at a later
step, or phase, of the systems engineering effort. Also, this description does not emphasize the key role of
information and information requirement determination.
Even when these realities are associated with the morphological, or form-based, framework, it still
representsan incompleteview of the way in which people do, could, or should accomplish planning, design,
development, or other problem-solving activities. The most that can be argued is that this framework is
correct in an “as if” manner. This introduces the notion that humans use a variety of approaches to assist
them in acquisition, representation, and use of information. Although many have contributed to this
4-8 Handbook of Dynamic System Modeling
area (Sage, 1990), the fundamental work of Rasmussen and his colleagues (1994) is especially significant.
Three types of human information-processing activities are described: skill-, rule-, or formal-knowledge-
based reasoning. The choice of which form of reasoning to employ is based primarily on the experiential
familiarity of an individual with the situation at hand, the task that is in need of being performed, and
the environment into which the task and situation are embedded. Additional details of this model of
information processing are provided in the works of Rasmussen and his colleagues (1994) and this and
other models are also discussed in Sage (1992a, 1992b). Recent application of organizational and human
models are discussed in a valuable work (Sage, 1990) for those concerned with organizational models and
simulations.
Systems engineering efforts are very concerned with technical direction and management of systems
definition, development, and deployment, or systems management. By adopting and applying the man-
agement technology of systems engineering, we attempt to be sure that correct systems are designed, and
not just that system products are correct according to some potentially ill-conceived notions of what the
system should do. Appropriate metrics to enable efficient and effective error prevention and detection at
the level of systems management, and at the process and product level will enhance the production of
systems engineering products that are “correct” in the broadest possible meaning of this term. To ensure
that correct systems are produced requires that considerable emphasis be placed on the front end of each
of the systems engineering life cycles.
In particular, there needs to be considerable emphasis on the accurate definition of a system, what it
should do, and how people should interact with it before one is produced and implemented. In turn,
this requires emphasis upon conformance to system requirement specifications, and the development of
standards to insure compatibility and integratibility of system products. Areas such as documentation
and communication are important in all of this. Thus, we see the need for the technical direction and
management technology efforts that comprise systems engineering, and the strong role for process and
systems management-related concerns in this.
4.4 Other Parts of the Story
There are many ingredients associated with the development of trustworthy systems. From a top-down
perspective, the following ingredients are surely present:
1. Systems engineering processes, including process development life cycle and process configuration
management;
2. process risk, operational-level quality assurance and evaluation, and product risk and development
standards;
3. metrics for quality assurance, and process and product evaluation;
4. metrics for cost estimation, and product cost and operational effectiveness evaluation;
5. strategic quality assurance and management, or total quality management;
6. organizational cultures, leadership, and process maturity;
7. reengineering at the levels of systems management, organizational processes and product lines, and
product.
and related issues that concern enterprisemanagement and systems integration, economic systems analysis,
cognitive ergonomics, and system assessment and evaluation.
These are the principal issues addressed in Sage (1992a, 1992b) and we could only begin to suggest their
importance here. A handbook of systems engineering and management (Sage and Rouse, 1999) provides
many perspectives in these needs.
These ingredients interact with one another. One of the first efforts in systems management is to identify
an appropriate process life cycle for the production of a trustworthy system. As we have already discussed,
this life cycle involves a sequence of phases. These phases include identification of client requirements,
translation of these requirements into (hardware and) software requirement specifications, development
Systems Engineering 4-9
of system architectures, detailed design through coding, operational implementation and evaluation, and
maintenance of the delivered product. The precise life cycle that is followed will depend upon the client
needs. It will also depend upon environmental factors such as the presence of existing system components,
or subsystems, into which a new system must be integrated, and the presence of existing software modules
that may be retrofitted and reused as a part of the new system. This need for system integration brings about
a host of systems management and, in many cases, legal issues (Beutel, 1991) that are much larger in scale
and scope than those associated with program development only. In a similar manner, the development
of appropriate system-level architectures is very important in that efficiency and effectiveness in systems
architecting is very influential of the ease with which systems can be integrated and maintained and,
therefore, of the extent to which an operational system is viewed as trustworthy and of high quality.
Following the identification of an appropriate systemic process-development life cycle, configuration
management plans are identified. This involves using the life cycle and defining a specific development
process for the set of life cycle tasks at hand. Metrics are needed to enable this to be done effectively.
These metrics are the metrics of cost analysis, or cost estimation for systems engineering. They also
include effectiveness analysis or estimation of system productivity indices using various metrics. This
couples the notion of development of a product into notions concerning the process needs associated
with developing this product. It is becoming widely recognized that these metrics must form a part of a
process-management approach for process, and ultimately product.
We have set forth some of the very large number of issues associated with systems engineering as
a catalyst for innovation and quality in this chapter. There are four principal messages developed that
provide benchmarks for continuing efforts:
1. Much contemporary thought concerning innovation, productivity, and quality can be easily cast
into a systems engineering framework.
2. This framework can be valuably applied to systems engineering in general and information
technology and software engineering in particular.
3. The information technology revolution provides the necessary tool base that, together with systems
engineering and systems management, provides the wherewithal to allow the needed process-level
improvements for the development of systems of all types.
4. Development of appropriate system models is an essential ingredient in essentially all of this.
Further, the relatively large number of ingredients necessary to accomplish the needed change fit well within
a systems engineering framework. Our discussions also illustrate that systems engineering constructs are
useful not just for managing big systems engineering projects according to government and industry
requirements, but for creative management of the organization itself.
4.5 Summary
The top-level objectives for systems engineering might be stated as the reduction of cost, and improvement
of quality in the technical direction and management of definition, development, and deployment of
modern products, systems, and services through the use of systems engineering processes. Together with
the ingredients to be dealt with in a systems engineering study—humans, organizations, and technologies,
and the environments that surround these—we see that systems engineering is a mixture of a management
discipline and a technology discipline, and that is why we haveillustrated and described systems engineering
as a management technology. Finally, we indicate perhaps the major objective of systems engineering, and
that is to bring together people, organizations, and technology, and all within a suitable environmental
context, for creative issue resolution and innovation. This is clearly a transdisciplinary endeavor and one
to which models and associated simulations can be of major use, as especially illustrated in Rouse and Boff
(2005) and Sage and Rouse (1999), which are efforts discussing the substantial role of systems engineering,
and modeling, in simulation-based acquisition (Sage and Olson, 2001; Olson and Sage, 2003).
4-10 Handbook of Dynamic System Modeling
References
Beutel, R. A., Contracting for Computer Systems Integration, Michie Co., Charlottesville, VA, 1991.
MIL-STD-499A, Engineering Management Standards, May 1974.
MIL-STD-499B, Engineering Management Standards, May 1991.
Olson, S. R. and Sage, A. P., Simulation based acquisition, in H. Booher (Ed.), Handbook of Human Systems
Integration, Wiley, New York, 2003, Chap. 9, pp. 265–293.
Rasmussen, J., Pejtersen, A. and Goodstein, L. P. Cognitive Systems Engineering, Wiley, Hoboken, NJ, 1994.
Rouse, W. B. and Boff, K. R. (Eds.), Organizational Simulation, Wiley, Hoboken, NJ, 2005.
Sage, A. P., Methodology for Large Scale Systems, McGraw-Hill, New York, 1977.
Sage, A. P., Methodological considerations in the design of large scale systems engineering processes,
in Y. Y. Haimes (Ed.), Large Scale Systems, North-Holland, Amsterdam, 1982, pp. 99–141.
Sage, A. P., Knowledge transfer: An innovative role for information engineering education, IEEE
Transactions on Systems, Man and Cybernetics, Vol. 17, No. 5, 1987, pp. 725–728.
Sage, A. P. (Ed.), System Design for Human Interaction, IEEE Press, New York, 1987.
Sage, A. P. (Ed.), Concise Encyclopedia of Information Processing in Systems and Organizations, Pergamon
Press, Oxford, UK, 1990.
Sage, A. P., Systems Engineering, Wiley, Hoboken, NJ, 1992.
Sage, A. P., Systems Management for Information Technology and Software Engineering, Wiley, Hoboken,
NJ, 1992.
Sage, A. P. and Armstrong, J. E., An Introduction to Systems Engineering, Wiley Hoboken, NJ, 2000.
Sage, A. P. and Rouse, W. B., Handbook of Systems Engineering and Management,Wiley, Hoboken, NJ,1999.
Sage, A. P. and Olson, S., Modeling and simulation in systems engineering: Whither simulation based
acquisition?” Modeling and Simulation, Part I, May 2001, Part 2, June 2001.
5
Basic Elements of
Mathematical Modeling
CliveL.Dym
Harvey Mudd College
5.1 Principles of Mathematical Modeling ............................ 5-2
5.2 Dimensional Consistency and Dimensional Analysis ... 5-3
Dimensions and Units
•
Dimensional Homogeneity
•
The Basic Method of Dimensional Analysis
•
The Buckingham Pi Theorem of Dimensional Analysis
5.3 Abstraction and Scale ...................................................... 5-9
Abstraction, Scaling, and Lumped Elements
•
Geometric
Scaling
•
Scale in Equations: Size and Limits
•
Consequences of Choosing a Scale
•
Scaling and
Perceptions of Data Presentations
5.4 Conservation and Balance Principles ............................. 5-17
5.5 The Role of Linearity ...................................................... 5-19
Linearity and Geometric Scaling
5.6 Conclusions ..................................................................... 5-20
A dictionary definition states that a model is “a miniature representation of something; a pattern of
something to be made; an example for imitation or emulation; a description or analogy used to help
visualize something (e.g., an atom) that cannot be directly observed; a system of postulates, data, and
inferences presented as a mathematical description of an entity or state of affairs.” This definition suggests
that modeling is an activity, a cognitive activity in which one thinks about and makes models to describe
how devices or objects of interest behave. Since there are many ways in which devices and behaviors
can be described—words, drawings or sketches, physical models, computer programs, or mathematical
formulas—it is worth refining the dictionary definition for the present purposes to define a mathematical
modelasarepresentation in mathematical terms of the behavior of real devices and objects.
Scientists use mathematical models to describe observed behavior or results; explain why that behavior
and results occurred as they did; and to predict future behaviors or results that are as yet unseen or
unmeasured. Engineers use mathematical models to describe and analyze objects and devices to predict
their behavior because they are interested in designing devices and processes and systems. Design is a
consequential activity for engineers because every new airplane or building, for example, represents a
model-based prediction that the plane will fly and the building will stand without dire, unanticipated
consequences. Thus, especially in engineering, it is important to ask: How are such mathematical models
or representations created? How are they validated? How are they used? And, is their use limited, and how?
To answer these and related questions, this chapter first sets out some basic principles of mathematical
modeling and then goes on to briefly describe:
•
dimensional consistency and dimensional analysis;
•
abstraction and scaling;
•
conservation and balance laws; and
•
the role of linearity.
5-1
5-2 Handbook of Dynamic System Modeling
5.1 Principles of Mathematical Modeling
Mathematical modeling is a principled activity that has both principles behind it and methods that can be
successfully applied. The principles are overarching or metaprinciples are almost philosophical in nature,
and can be both visually portrayed (see Figure 5.1) and phrased as questions (and answers) about the
intentions and purposes of mathematical modeling:
•
Why? What are we looking for? Identify the need for the model.
•
Find? What do we want to know? List the data we are seeking.
•
Given? What do we know? Identify the available relevant data.
•
Assume? What can we assume? Identify the circumstances that apply.
•
How? How should we look at this model? Identify the governing physical principles.
•
Predict? What will our model predict? Identify the equations that will be used, the calculations that
will be made, and the answers that will result.
•
Valid? Are the predictions valid? Identify tests that can be made to validate the model, i.e., is it
consistent with its principles and assumptions?
•
Verified? Are the predictions good? Identify tests that can be made to verify the model, i.e., is it
useful in terms of the initial reason it was done?
Why? What are we looking for?
Find? What do we want to know?
How? How should we look at this model?
Given? What do we know?
Assume? What can we assume?
Predict? What will
our model predict?
Valid? Are the predictions valid?
Improve? Can we improve the model?
Use? How will we exercise the model?
Object/System
Model
Variables; Parameters
Model predictions Test
Valid, accepted predictions
Verified? Are the predictions good?
FIGURE 5.1 A first-order view of mathematical modeling that shows how the questions asked in a principledapproach
to building a model relate to the development of that model. (Inspired by Carson, E. and Cobelli, C. (Eds.), Modelling
Methodology for Physiology and Medicine, Academic Press, San Diego, 2001.)
Basic Elements of Mathematical Modeling 5-3
•
Improve? Can we improve the model? Identify parameter values that are not adequately known,
variables that should have been included, and/or assumptions/restrictions that could be lifted.
Implement the iterative loop that we can call “model-validate-verify-improve-predict.”
•
Use? How will we exercise the model? What will we do with the model?
It is worth noting that the “final” principle, Use?, is often considered early in the modeling process, along
with Why? and Find?, because the way a model is to be used is often intimately connected with the reason
it is created.
Note also that this list of questions and instructions is not an algorithm for building a good mathematical
model. However, the underlying ideas are key to mathematical modeling, as they are key to problem
formulation generally. Thus, the individual questions will recur often during the modeling process, and
the list should be regarded as a general approach to ways of thinking about mathematical modeling. In a
similar vein, it is also worth remembering the associated modeling “methods” that are presented below
(e.g., dimensional analysis, and abstraction and scaling) support rather than lead the modeling process;
these modeling methods are neither algorithms themselves or susceptible to being encapsulated into some
overarching “modeling algorithm.”
Having a clear picture of why the model is wanted or needed is of prime importance to the model-
building enterprise. For example, a first estimate of the available power generated by a dam on a large
river, say The Three Gorges Dam on theYangtze River in Hubei Province in the People’s Republic of China,
would not require a model of the dam’s thickness or the strength of its foundation. However, its height
would be essential, as would some model and estimates of river flow quantities. By contrast, a design of the
actual dam would need a model that incorporates all of the dam’s physical characteristics (e.g., dimensions,
materials, and foundations) and relates them to the dam site and the river flow conditions. Thus, defining
the task is the first essential step in model formulation.
The next step would be to list what is known, for example, river flow quantities and desired power
levels, as a basis for listing variables or parameters that are not yet known. One should also list any relevant
assumptions. For example, levels of desired power may be linked to demographic or economic data, so
any assumptions made about population and economic growth should be spelled out. Assumptions about
the consistency of river flows and the statistics of flooding should also be spelled out.
Which physical principles apply to this model? The mass of the river’s water must be conserved, as
must its momentum, as the river flows and energy is both dissipated and redirected as water is allowed to
flow through turbines in the dam (and hopefully not spill over the top!). Mass must be conserved, within
some undefined system boundary, because dams do accumulate water mass from flowing rivers. There
are well-known equations that correspond to these physical principles. They could be used to develop an
estimate of dam height as a function of power desired. The model can be validated by ensuring that all
equations and calculated results have the proper dimensions, and the model can be exercised against data
from existing hydroelectric dams to get empirical data and validation.
If the model is inadequate or that it fails in some way, an iterative loop is then entered in which one cycles
back to an earlier stage of the model building to reexamine any assumptions, known parameter values,
the principles chosen, the equations used, the means of calculation, and so on. This iterative process is
essential because it is the only way that models can be improved, corrected, and validated.
5.2 Dimensional Consistency and Dimensional Analysis
There is a very powerful idea that is central to mathematical modeling: Every equation used must be
dimensionally homogeneous or dimensionally consistent, that is, every term in a balance of mass should have
the dimension of mass, and when forces are summed to ensure equilibrium, every term in that summation
must have the physical dimension of force. Equations that are dimensionally consistent are also called
rational equations. Ensuring the (dimensional) rationality of equations is very useful for validating newly
developed mathematical models or for confirming formulas and equations before doing calculations with