.. _SysAndModels:
.. raw:: html
.. |--| unicode:: U+2013 .. en dash
.. |---| unicode:: U+2014 .. em dash, trimming surrounding whitespace
:trim:
.. This file is part of the OpenCSF eTextbook project. It was
.. auto-generated by scripts from the OpenDSA eTextbook project.
.. See https://OpenCSF.org for more details. OpenCSF is distributed
.. under a Creative Commons Attribution-NonCommercial 4.0 International
.. License (see http://creativecommons.org/licenses/by-nc/4.0/),
.. Copyright (c) 2019-2021 by Michael S. Kirkpatrick. OpenDSA is
.. distributed under an MIT open source license, Copyright (c) 2012-2021
.. by the OpenDSA Project Contributors.
.. avmetadata::
:author: Michael S. Kirkpatrick
:requires:
:satisfies: Systems and Models
:topic: Systems and Models
Systems and Models
==================
Throughout this book, we are considering the idea of computer systems from a perspective that
strives to apply insights from :term:`systems theory`. From this view, a :term:`system` is an
integrated collection of entities and their interactions. The computer itself is a system. Computers
are assembled from disparate hardware components that include a central processing unit (CPU),
storage devices, input and output devices, random access memory (RAM) cards, and a printed circuit
board (PCB) that links them all together. A software OS executes on top of these components, thus
integrating their independent functionality into a more complex entity. To fully understand the
nature of the computer as a whole, it's important to understand the components' independent
functionality as well as how they work together.
.. _SysInteractFig:
.. figure:: Images/CSF-Images.1.1.png
:align: right
:width: 90%
:figwidth: 45%
:alt: A computer is a system of interacting hardware and software entities
A computer is a system of interacting hardware and software entities
The system is made more complex by adding application software to the mix. Each application is
constructed from code modules, variables, and other run-time memory structures that are compiled and
integrated to provide a single higher-level function. But software does not run itself; the software
must be executed within the greater context of computing, as a sequence of steps performed by a
physical computer with the help of an OS. Some applications run in isolation from one another, but
they still require the OS and hardware. Others communicate with services that provide information or
perform complimentary tasks, allowing the developer to build more powerful software without having
to start from scratch. :num:`Figure #SysInteractFig` summarizes this view of the computer as
a system of interacting components.
In short, all of computing is a system. As computer scientists continue to explore the power of
computing, we can take this claim even further to suggest that computing is made up of a system of
systems. In order to stream a movie over the Internet, the application software must integrate
network connectivity and local file storage, probably with the help of a graphics processing unit
(GPU) that improves the visual quality of the experience. Each of these hardware and software
components are systems, and the application is coordinating their interaction to serve the user. As
another example, consider large-scale scientific projects that model changes in the climate or
advanced quantum mechanics phenomena. This type of work involves linking thousands of parallel
computing nodes that coordinate their calculations and exchange data as needed, creating truly
complicated systems and interactions. Our goal is to understand the common principles and strategies
that make these systems work.
Models as Representations
-------------------------
A first step toward understanding a system is constructing a :term:`model` – a simplified
representation – of the system. :num:`Figure #SysInteractFig` above is a model of a computer as a system. As a
simplification, models necessarily omit details that are present in the system itself. Some models
have visual representations, facilitating human interpretation of the system. That is,
:term:`visual models ` are very good tools for people to make sense of the entities
and their interactions. System designers, developers, and users can use visual models to avoid
mistakes. Other models are :term:`formal `, written in a mathematical specification
language. One way to characterize the differences between models is to describe their
:term:`level of abstraction`. Visual models may have a relatively low level of abstraction,
including details that are aesthetically pleasing but not important. Formal models have a relatively
high level of abstraction, omitting everything except the bare minimum.
Consider the models shown in :num:`Figure #SysPhysModel`. The model on the left has the lowest level of
abstraction, as it includes details that show a yellow box on a grey ramp. This scenario is then
converted into a free-body diagram in the middle. Free-body diagrams are used in physics to
illustrate the forces acting on an object, while removing unneeded details such as the drawing of
the box and the ramp. The equation on the right is the formal model that captures this information.
The net force F is the sum of the forces created by gravity (mg), the normal force N, and the force
of friction :math:`F_f`. All three models convey the same information, but they provide different
levels of abstraction.
.. _SysPhysModel:
.. figure:: Images/CSF-Images.1.2.png
:width: 70%
:align: center
:alt: Three models for the same physical phenomenon
Three models for the same physical phenomenon
A :term:`static (or structural) model ` describes the fixed, unchanging features of a
system, while omitting explanations of how the system or entities change. Readers with a background
in object-oriented programming may be familiar with class diagrams created using
:term:`unified modeling language (UML) `. These models describe features
like class inheritance and sub-typing, while omitting characteristics like the values of an object's
variables or the messages it uses to communicate with other objects. Throughout this text, we will
focus repeatedly on one particular type of static model, the system architecture.
In contrast, a :term:`dynamic (or behavioral) model ` focuses on changes to the
system. These models are particularly important to understanding systems, because many of their key
features are :term:`emergent properties `. An emergent property is one that
results from the dynamic features of the system and is not intuitive from static models alone. We
will be using two dynamic UML models throughout this book. A :term:`state model` describes the
system's possible states – defined by meaningful combinations of system parameters – and the possible
transitions between them. For instance, a streaming video service may characterize different states
to represent "requesting the video," "buffering received data," "pausing the video," and "playing
the video." A :term:`sequence model` illustrates the order of messages and key events that a system
experiences over time. One use of a sequence model is to describe a specific order in which state
transitions occur. These models provide a clear illustration of network communication protocols and
messages to coordinate parallel and distributed computation.
From Models to Implementations
------------------------------
Models are useful tools for analyzing and illustrating the behavior of a system. Well-constructed
models of the natural world can help scientists develop insight into and explain real-world
phenomena, such as the chemical reactions that release energy stored in food, the wave-like behavior
of electrons in an atom, or the fractal designs in crystals. User manuals for appliances, vehicles,
children's toys, etc., use illustrations as models to convey information to consumers who are not
necessarily experts in the field.
In contrast to many other fields, the field of computer systems places a strong emphasis on turning
models into implementations. That is, our goal is not simply to build and interpret models, but to
turn these models into working artifacts. This implementation process can be quite challenging and
creates many opportunities for errors; mistakes that cause the system to behave differently from the
model can render the model useless or, even worse, increase confusion. As such, much of our focus
throughout this book is on successfully turning models into concrete, executable implementations.
.. avembed:: Exercises/IntroConcSys/SysAndModelsSumm.html ka
:module: SysAndModels
:points: 1.0
:required: True
:exer_opts: JXOP-debug=true&JOP-lang=en&JXOP-code=java
:long_name: Systems and models questions
:threshold: 5