The handout describes the process of problem solving with computers. This requires an ability to analyze a problem, outline the problem requirements, and design step-by-step algorithms that can be solved in a finite amount of time. It also requires an appreciation of the complementary strengths of man and machine, and an ability to formulate models that lend themselves to implementation on computers.

Key points are illustrated through the development of five progressively complicated applications:

• Solution of a quadratic equation.
• Behavior of a tennis ball projectile.
• Organization of music files in iTunes.
• Behavior modeling for two-phase traffic flow at an intersection.
• Computer modeling for building architectures and building services.

The last problem is interesting in the sense that it outlines ideas for an emerging problem area where solutions to problems/software have yet to be found.

History indicates that large-scale engineering systems can be created without computers (e.g., Great Wall of China; Pyramids of Giza in Egypt).

They aren't.

As we will soon see below, what computers and computer software bring to the table is an ability to design and efficiently implement systems that have

To participate in these cutting-edge developments, you'll need to be a skilled problem solver, and have a good knowledge of computers and computer technologies.

This process is facilitated by the complementary strengths and weaknesses of man and machine:

Man	Machine
Good at formulating solutions to problems (algorithms). Can work with incomplete data/information. Creative. Reasons logically, but very slow... Performance is static.	Electo-mechanical machine that can manipulate Os and 1s. Very specific abilities. Requires precise decriptions of problem solving procedures. Dumb, but very fast. Performance doubles every 18 months.

Table 1. Summary of Strengths and Weaknesses -- Man versus Machine

Therefore, a good "problem solving strategy" is to let engineers + computers do what they are best at. This:

• Accelerates the solution procedure.
• Enables the analysis of problems having size and complexity beyond manual examination.

For this strategy to work, need to describe to the computer solution procedures in a manner that is completely unambiguous (i.e., we will need to look at data, organization and manipulation of data, and formal languages).

Users versus Developers

Engineers tend to have two types of relationships with with computers:

• Computer User ...
  The computer user is someone who relies on system-supplied software to help them in their day-to-day needs, e.g.,

  • Productivity Tools
    Microsoft Word, Excel, Photoshop.. etc.
  • Communication
    E-mail, Web...
  • Search
    Yahoo, Google, Wikipedia...
  • Storage/Retrieval of Data
    Databases, Microsoft Access, Web Servers.. etc.
  • Engineering Analysis
    Matlab, ANSYS, LabView .. etc.

  Perhaps you will simply supply the problem data, push a button, and get the result? This approach suffices for the solution of main-stream, mature, engineering problems.

• Software Developer ...
  A software developer is someone who actually designs and implements new software.

  If present-day software does not do what you want, or perhaps you are working in a problem domain that is new and innovative, then knowledge of software design will allow you to fill that gap.

For the most part, we are all computer users.
Far fewer engineers are also competent software developers.

Changing Role and Economics of Software Development

Expectations of Computing

During the past fifty years, our expectations of computing have incrementally expanded.

It takes about one decade of a major change in computing to occur. Today, we expect computers to support all activities, from numerical computations to social networking.

Economics

In the early 1970s,

• Software consumed approximately 25% of total costs, and
• Hardware consumed 75% of total costs for development of data intensive systems.

Nowadays, development and maintenance of software typically consumes more than 80% of the total project costs.

Figure 1. Economics of Systems Development and Integration

This change in economics is the combined result of falling hardware costs, and increased software development budgets.

• Whereas one or two programmers might have written a complete program twenty years ago, teams of programmers are now needed to write todays programs.

Human-Computer Interfaces

The mechanisms with which humans interact with computer are becoming progressively sophisticated, i.e.,

Example. Two applications of touch technology.

Figure 2. Touch interfaces. Left: Microsoft Playtable, Right: Apple iPhone.

Hitachi has just released a giant multi-touch interface.
See the demo on youtube .

Prevalent Languages

Because computer languages need to be precise statements for what needs to be computed, languages tend to have a small syntax, and are generally designed to facilitate the solution of a well-defined class of problems. As a result, one general-purpose language does not exist. Instead, new languages are developed to serve the needs of new expectations from computing.

• FORTRAN (1950s -- today)
  Stands for formula translation.
• C (early 1970s -- today)
  Originally designed to support development of new operating systems.
• C++ (early 1970s -- today)
  Basically just an object-oriented version of C.
  Designed to facilitate development of very large software programs.
• MATLAB (mid 1980s -- today)
  Stands for matrix laboratory.
• HTML (1990s -- today)
  Hypertext markup language is used for layout of web-page content.
• Java (1994 -- today)
  An object-oriented language designed for network-based computing.
• XML (late 1990s -- today)
  The eXtended Markup Language (XML) allows for the description of data on the Web.
• RDF (2000 -- today)
  Stands for the Research Description Framework. This language describes graphs of resources on the Web.
• OWL (2003 -- today )
  Stands for Web Ontology Language. An ontology is a conceptual description of a problem domain (e.g., cooking, making wine).

Summary and Conclusion

This gradual change in development strategies has bought with it, new challenges in the software development process:

• Expectations of computing today are much more ambitious than in the past. This translates to software developments that are steadily becoming larger and more complex.
• When all of the details of a software/systems project cannot be understood within a group small enough to freely communicate, the cost of communications becomes high. Errors are easy to make and hard to find.

Move from Industrial- to Information-Age Systems

A good engineering design balances the need for functionality and performance against limitations on cost.

• Models of functionality need to describe what the system will do, and in what order, under both normal and abnormal operating conditions.
• Performance requirements describe how well a system should perform these functions.
• Economic requirements place constraints on the resources that will be made available to develop and operate the system.

The systematic consideration of these concerns in engineering systems design is becoming increasingly complex because of demands to expand system functionality and improve performance while keeping costs in check.

An analysis of industrial-age applications reveals that in many cases, constraints on system functionality and performance can be attributed to limitations in our ability to:

• Sense the surrounding environment in which the system is operating,
• Control system behavior, and
• Look ahead and anticipate events.

Many present-day (so-called industrial-age) systems rely on human involvement as a means for sensing and controlling behavior, e.g.,

• Driving a car,
• Traffic controllers at an airport,
• Manual focus of a camera.

But as already noted, humans are slow. They also easily tire. Information-age systems are developed under the premise that advances in computer, sensing, and wireless networking technologies allow for relaxation (or even removal) of the aforementioned constraints. The result is new types of systems where human involvement is replaced by automation, e.g.,

• Autofocus camera,
• Cruise control in an automobile,
• Electronic systems in automobiles and planes,
• Baggage handling systems at airports.

This change in strategy increases the role of sensing, computing and control in engineering, and the need to handle and work with large quantities of data.

Summary of Industrial- and Information-Age Systems

From Data to Information and Knowledge

The pathway from data to information to knowledge can be visualized as follows:

Figure 3. Pathway from Data to Information to Knowledge.

Points to note:

• Sensors and computers play the role of gathering and processing data, possibly from a variety of sources. The data will be processed into information, which in turn, will be applied to decision making.
• Data is raw content that can exist in any form -- perhaps it is measured by an ensemble of sensors distributed throughout a system.
• Information is obtained from data by identifying and understanding meaningful relationships among various types of data content.
• Over time, collections of relationships will form repetitive patterns. We move from information to knowledge when patterns can be associated with useful design intent.
• The generated information enables better decision making, which in turn, allows for extended functionality and improved performance.

Dealing with this trend requires attention to:

• Economic concerns
  Software failures are often very costly.
• Safety concerns
  In safety-critical systems, software failures may be dangerous. The ability to produce reliable and error free software may be essential to a projects' success.

In many cases the software isn't even visible to the outside users (i.e., increased use of so-called ubiquitous computing).

Remark. In a classical sense, information is a noun that means "knowledge communicated" or received concerning a particular fact or circumstances. In other words,

Information is valuable because it resolves uncertainty -- and the less predicable a message is, the more information it conveys! Conversely, if somebody sends you a message that does not further your knowledge with respect to an event or circumstance, then from your perspective, the message does not contain information.

Physical Systems versus Computational Systems

Many modern civil engineering systems are a combination of physical and computational systems.

• Physical Systems
  

  • Behavior is constrained by conservation laws (e.g., conservation of mass, conservation of momentum, conservation of energy, etc..).
  • Behavior often described by families of differential equations.
  • Solution to differential equations can be simplified through the use of matrices and linear algebra. This is the main topic of ENCE 201.
  • Behavior tends to be continuous -- thus if a system is going to fail, usually there will be some warning.
  • Behavior may not be deterministic -- this aspect of physical systems leads to the need for safety and reliability requirements, which are qualitatively different from those in general-purpose computing.
  • For design purposes, uncertainties in behavior are often handled through the use of safety factors.

• Computational Systems
  

  • Computational systems are discrete and inherently logical. Notions of energy conservation ...etc... and differential equations do not apply.
  • Does not make sense to apply a "safety factor"...
  • A small logical error can result in a system-wide failure.

Embedded computers and networks monitor and control physical processes in feedback loops where physical processes affect computations, and computations affect physical processes. Since the early 1970s and as illustrated in Figure 1, computers have been increasingly embedded in stand-alone, self-contained products. During the past decade these embedded computers have become networked, which has opened the door to a whole new array of services.

Applications associated with Civil Engineering include:

• Traffic control and safety,
• Advanced automotive systems,
• Critical infrastructure control (electric power, Water resources, and communications systems),
• Networked building control systems (such as HVAC and lighting) could significantly improve energy efficiency and demand variability,
• Health monitoring of building and bridge structures.

Example 1
In a modern automobile, the electronics and communication systems now account for 30% of the overall cost (W. Reitzle, BMW, 2000).

Figure 4. Electronics and Communications in a Modern Car.
(Source: A.S. Sangiovanni-Vincentelli, EE 249, UC Berkeley, Fall 2002.)

These electronics and communications systems provide drivers with functionality that would not be possible without an ability to gather and work with data/information. For example, GPS systems coupled with real-time traffic management systems can provide drivers with directions that will avoid congestion, traffic accidents, ... and so forth.

Example 2.
Here is an example of computing moving from the desktop to the automobile ...

2005-2006	2007-2008

Figure 5. Access to Computing becomes more Mobile

Sensor Networks in Civil Infrastructure

Within Civil Engineering, the trend from industrial- to information-age systems is gaining traction in the use of sensors to improve the functionality and performance of large-scale infrastructure systems.

Example 1. Panama Canal Upgrade

Early Days of the Panama Canal

• The Panama Canal is an 80km passageway that joins the Atlantic and Pacific Oceans. It was constructed during 1904-1914.
• There are three locks on the Atlantic side and three locks on the Pacific side.
• Lock chambers are 33.5m wide, 304m long and 12m deep.
• Locomotives pull ships through the lock system.
• It takes a ship approximately 10 hours to transit the canal. The alternative is a two-week trip around South America.
• The original designers of the Panama canal could not have envisioned the magnitude of global trade between Asia and the US.

Present-Day Panama Canal

• With round-the-clock operations (90% of total capacity), thirteen thousand ships transport a total of 190 million tons of cargo through the canal annually, primarily between Asia and the Central and Eastern US. This is approximately 5% of all the world's cargo.
• So-called Post-Panamax ships -- ships too large to fit through the canal -- now constitute 27% of all container shipping. In ten years, this will easily rise to 50% of all container shipping.
• One consistent problem is with the old locks using a double-leaf door system that forces a channel to be put out of commission while the door is removed and dry docked for repairs. To avoid this,

Figure 6. Collage of ship activity in the Panama Canal.
(Left-hand graphic shows transiting ships crowding Miraflores Locks and Lake;
Right-hand graphic illustrates of limitations of present-day canal capacity).

Panama Canal Rennovations

• The new lock system will consist of three new locks on the Atlantic side and three new locks on the Pacific side.
• Each lock chamber will be 427m long, 55m wide and 18.3m deep. These dimensions will support so-called Post-Pamamax ships, 366m long, 49m wide and a maximum draft of 15m.
• Ships with 12,000 containers will be able to pass through. The present limit is of about 4,000 containers.
• Lake Gatun will be raised 1.5m.
• The double-leaf door system will be replaced by rolling gates.
• The new lock system will use tug boats to position vessels (instead of locomotives).

Figure 7. Cross Section of new Canal System

Role of Information-Age Technology

• Information Technology
  Operators now use a graphical interface to supervise new electronic workstations, which are automated in both operation and maintenance. The new interface facilitates quicker intake of information, and provides a complete view of all active systems.
• Sensors and Lasers
  The locks that raise and lower ships with cargo employ an extensive sensing system in order to ensure true fault tolerance. When a ship enters into the locks using the new system, lasers are used to determine the size and number of the ships within the locks. As water levels rise, the depth of the water is sensed by radar, and the gates are then opened when the water levels are equal.
• Predictive Modeling
  The most beneficial feature of the new system is the predictive modeling capabilities that allow transit operations to proceed during emergency maintenance, for the first time. Maintenance is predicted ahead of time using fiber optic signals, and modem alarms, all of which are stored in a database for maintenance analysis.

Example 2. Health Monitorting of Buildings/Bridges

Motivation

The I-35W Mississippi River bridge was steel truss arch bridge that spanned the Mississippi River in Minneapolis, Minnesota. It had eight-lanes and was 1,907 feet in length.

Figure 8. Collapsed I35 W. Mississippi Bridge
Source: http://en.wikipedia.org/wiki/I-35W_Mississippi_River_Bridge

The bridge collapsed at 6:05pm on August 1, 2007 during rush hour. Thirteen people died and 100 people injured as a result of the collapse.

Lessons learned from the post-failure evaluation include:

• The bridge was inspected by the Minnesota Department of Transportation every year since 1963 (excluding 2007). During that time, the government gave the bridge a rating of "structurally deficient." This rating was due to significant corrosion in its bearings.
• Other experts assert that the construction activity on the bridge helped lead to its collapse.
• In either case, a bridge collapses because either the load is too heavy or there is some problem in the bridge material and bearings. Therefore, if guidelines about the maximum load capacity had been readily available and were followed, the failure may have been prevented.
• Also, if the aging and wear of the materials and connection methods used to construct the bridge were better understood, perhaps the failure could have been predicted.

Jan 16, 2008 update.
The National Transportation Safety Board (NTSB) today announced that a serious design flaw was found in some of the gusset plates on the I-35W bridge. As a result, the NTSB issued a recommendation that the Federal Highway Administration (FHwA) require bridge owners to verify that the stress levels in all structural elements, including gusset plates, remain within applicable requirements whenever planned modifications or operational changes may significantly increase stresses. This would apply to all non-load-path-redundant steel truss bridges within the National Bridge Inventory.

Framework for Health Monitoring of Bridge Components

Figure 9. Composite Marine Pile Bridge Monitoring

Role of Technology in Health Monitoring of Bridges

• Embedded fiber sensors.
• Networked communications.
• Advanced software to detect imminent health problems.

Pressure to Develop Error-Free Software

Complex engineering systems are becoming increasing reliant on:

Satisfying this criterion is complicated by the fact that a small fault in the software implementation can trigger (or result in) system-level failures that are very costly and, sometimes, even catastrophic.

A few famous examples include (see http://infotech.fanshawec.on.ca/gsantor/Computing/FamousBugs.htm):

Example 1. Ariane 5, 1996 The Ariane 5 rocket exploded on its maiden flight in June 1996 because the navigation package was inherited from the Ariane 4 without proper testing. The new rocket flew faster, resulting in larger values of some variables in the navigation software. Shortly after launch, an attempt to convert a 64-bit floating-point number into a 16-bit integer generated an overflow. The error was caught, but the code that caught it elected to shut down the subsystem. The rocket veered off course and exploded.
Example 2. Power Shutdown of the USS Yorktown A crew member of the guided-missile cruiser USS Yorktown mistakenly entered a zero for a data value, which resulted in a division by zero. The error cascaded and eventually shut down the ship's propulsion system. The ship was dead in the water for several hours because a program didn't check for valid input (Reported in Scientific American, November 1998).
Example 3. Denver Airport Baggage Handling System 1995 The Denver airport baggage handling system was so complex (involving 26 miles of conveyors and 300 computers) that the development overrun prevented the airport from opening on time. Fixing the incredibly buggy system required an additional 50\% of the original budget - nearly $200m. 2005 Despite years of tweaking, it never ran reliably. Airport managers pull the plug, reverting to traditionally loaded baggage carts with human drivers (Jackson, Scientific American, June 2006).
Example 4. Mars Climate Orbiter, September 1999 The 125 million dollar Mars Climate Orbiter is assumed lost by officials at NASA. The failure responsible for loss of the orbiter is attributed to a failure of NASA's system engineer process. The process did not specify the system of measurement to be used on the project. As a result, one of the development teams used Imperial measurement while the other used the metric system of measurement. When parameters from one module were passed to another during orbit navigation correct, no conversion was performed, resulting in the loss of the craft.

Table 3. Famous System Failures caused by Buggy Software.

Later in this course we will see that many software errors can be avoided through the use of formal models of requirements and the engineering system, coupled with rigorous procedures for checking software systems for faults.

A Few Key Points ...

Advances in computer science and communications technology:

But when technologies are weaved together to achieve new levels of system functionality,...

To complicate matters,

Thus, in order for design of information-age systems to be correct, we need design methodologies that use formal approaches to modeling, strategic in their evaluation of system performance.

Practical Considerations

• Only a very small percentage of civil engineers will also become professional-level software developers. Why? Well for one, it's hard. There's a lot to learn and not all of the subject matter is easy to grasp.

• Even if you become some sort of a manager and think of yourself as primarily a computer user, eventually you will find yourself looking for software that doesn't seem to exist. Perhaps you will hire a computer professional to write the software. The project setup will go much more smoothly if you have at least a working knowledge of computers and how they work.

To complicate matters, of all the classes that you will take in Civil Engineering, none will have material with a shorter half-life than this one.

• Computer languages and software packages tend to evolve through one generation every decade, so it is likely that in 15-20 years from now, the way in which you interact and work with computers could be different from today (e.g., think iPhone touchscreen versus Mouse).

Hence, for the purposes of a class like ENCE 200 we should ...

• Focus on the "big picture stuff" and try not to get too buried in low-level details. Big picture stuff includes thing like: understanding what's in a computer, what is the role of computer languages, operating sytems, networks ... etc. What is the general procedure for solving a problem on a computer?
• When low-level details are needed to solve a problem, then I will give most of them to you.

Step-by-Step Procedure

A high-level procedure for solution of problems with computers can be visualized as follows:

Figure 10. High-level Procedure for Solution of Problems with Computers.

The four stages of development each require attention:

• Problem
  During the problem definition we identify:

  • Solution requirements.
    Does the problem have data?
    Will a user interact with the software through textual input/output or a graphical interface?
  • Elements of the problem that might be solved by computer.
  • Quantitative metrics against which the results (downstream) will be evaluated.

  This early stage of development is part science and part art.

• Algorithm
  Algorithm development involves translation of a real-world problem into a step-by-step procedure that can be solved on a computer in a finite amount of time.

  Often this translation involves the development of models that are focused on a specific system viewpoint (e.g., system behavior, system structure). The result might be families of objects making up the system, or it might be families of equations that describe system behavior. Algorithms are step-by-step procedures for understanding some aspect of the system under study (e.g., system behavior might be defined by the solution to a differential equation).

  To the extent possible, you should validate your algorithm on a small example (possibly a hand calculation) before getting getting into the details of actually implementing your solution procedure on a computer.

• Write and Run Software
  This step involves translation of the algorithm into computer source code, possibly compilation of the source code into executable code, and then execution of the computer program itself. Typical software development concerns include:

  • What computer language (or languages) should be used? Does it matter?
  • Will execution of the computer program require data? Where is the data located? How will the computer program read this data?
  • How will an engineer interact with the computer program? Should the interface be textual or graphical?
  • Which parts of the computer program will be written by the software devloper? And which parts of the computer program will correspond to code located in software libraries? What are the tradeoffs in such decisions?

  A development error will when the user-defined source code does not match the rules of the underlying computer language.

• Result
  For the solution of simple engineering problems, the result will correspond to the output generated by the software. If everything has been implemented as planned, then the result should match your expectations. Two types of error are common, however. First, an error might occur during the program's execution, perhaps because of a "divide by zero" or numerical overrun (i.e., the program tries to store a number that is too large for the space provided). The second type of error is one of validation -- does your program actually solve the problem that it is supposed to?

Ingredients of an Algorithm

The essential ingredients of an algorithm are as follows:

• It should have a well-defined start and a well-defined finish. The starting point may require inputs (e.g., data). The finishing point will usually involve some form of textual or graphical output.
• The algorithm itself will be a set of instructions that operate on some input (e.g., problem data).
• Each instruction must be well defined and have an outcome that is predictable.
• Algorithms are often defined by a flow of logic or sequencing. When an instruction is finished, the program flow of control will be passed to the next instruction.

When an algorithm is initiated with sensible data, then it should terminate/finish in a sensible way.

Flowchart and Pseudocode Representations

A flowchart is simply a graphical representation of the steps in an algorithm, e.g.,

Figure 11. Sequence of Steps in an Algorithm.

The textual/pseudocode counterpart to Figure 11 is:

    Starting Point
       Step 1.
       Step 2.
       Step 3.
       ......
       Step N.
    Finishing Point

The "starting point" of an algorithm may require that pre-conditions be satisfied (e.g., availablity of data). Often the "finishing point" of an algorithm will be defined by the generation of textual and/or graphical output.

Support for Decision Making

Figure 12. Flowchart for Basic Decision Making

Support for Repetitive Operations

Figure 13. Flowchart for Repetitive Operations

Flows of Data/Information in General Computer Programs

It is convenient to think of Figures 11 trough 13 as templates for problem solving.

• Figure 11 highlights problem solving as a sequence of steps.
• Figure 12 incorporates support for decision making.
• Figure 13 introduces efficiency of implementation through repetitive computation of similar operations.

General purpose programming languages allow the programmer to customize a problem solving procedure by mixing-and-matching these basic problem-solving templates.

Computer Program Source Code

When you write the source code for a computer program, in essence, all that you are doing is using text to fill-in the details of programming templates. While the basic problem solving strategy will be language-independent, the syntax details will vary from one language to another, e.g.,

    Branching Construct in Java                 Branching Construct in Matlab
    =========================================================================

    if ( i < 3 ) {                              if i < 3,
      .... do something ....                       .... do something ....
    } else {                                    else
      .... do something else ....                  .... do something else ....
    }                                           end;

    =========================================================================

In both cases, if the fragment of code "i < 3" evaluates to true, then we will "do something ...". Otherwise, we will "do something else...".

Figure 14 shows a framework for general-purpose modeling and creation of structure and behavior models for engineering applications.

Figure 14. Process for Simplified Development of Engineering Models

Key points:

• Useful engineering models are:

  • Abstract
    Good models emphasize important aspects of a problem and remove irrelevant ones.
  • Easy to Understand
    Good models express information in a form end-users can easily understand.
  • Accurate
    Good models faithfully represent the system that is being modeled.
  • Predictive
    Good models can be used to derive conclusions about the system.
  • Inexpensive
    Good models must are much cheaper to create than the real system itself.

• Generally speaking, models are created in two steps:

  • Abstraction

    Abstraction means that we concentrate on the essential features of one part/module of the engineering problem, and abstract from details of the engineering system that are not immediately relevant to the current module.

    For our purposes, abstraction replaces the real world system with a similar but simpler-to-understand model (e.g., visual/graphical description; analytical/mathematical description). This, in turn, can reduce the difficulty in working through the essential steps for completing a task.

  • Validation

    A fundamental consideration is validating (or ensuring) that the model represents the real system to a certain degree of accuracy.

  The closed loop of one-way arrows indicates that several iterations of abstraction and validation may be required. Without validation, results of the modeling may amount to little more than educated guesswork!

• Irrespective of the end purpose, the basic ingredients of a model are as follows (Binder, pg. 112):

  Modeling Ingredient	Comment
  Subject	A model must have a well-defined subject.
  Viewpoint	A model should be based on a point of view (i.e., frame of reference) that can guide identification of the relevant issues and information.
  Representation	A modeling technique must have a means to express a particular model. Examples include: Text and audio descriptions of the system. Scaled "physical model" in the laboratory. Equations of motion for a dynamical system. Line drawings in a CAD model.
  Technique	Model formulation is part science and part art. Technique matters. Sometimes the formulation of the model can be guided (and constrained) by relevant mathematical and physical theories.

  Table 4. Basic Ingredients in a Model

  A good representation allows the system model to be conveniently stored, accessed, and manipulated. It should allow for the easy communication of infomation among team members.

• Nearly all engineering systems operate in the context of a surrounding environment. To fully understand a system, you will need to create a model of the system, the environment within which it will operate, and the types of interaction between the system and environment.

  A model of the environment will help to define what functions the system may need to provide. It may also place constraints (e.g., physical constraints) on the system itself.

• Models of behavior help an engineer to understand what a system will do. Models of system structure capture the objects and relationships among objects in the system.

• Most Civil Engineering systems have behavior and structure that is highly constrained by the surrounding environment.

  For example, the dynamic behavior of a building shaking during an earthquake is constrained to follow conservation laws (e.g., balance of forces, conservation of energy). The flow of water through a canal needs to satisfy conservation of momentum. The application of these principles leads to "continuous system behavior" defined by ordinary or partial differential equations.

  Computers, on the other hand, are inherently discrete. Thus approxmations will be needed for number storage, and evolution of system behavior in both space and time.

  Numerical analysis is the study of algorithms that can find the efficient and accurate solution to numerical problems. We will come back to this topic in ENCE 201.

Transformational and Reactive Systems

Systems can be classified as being either transformational or event-hased. In the transformational definition, a system is a function that receives one or more system inputs I from an external environment, transforms them with process T , and then releases them as system outputs O to an external environment. This input-output (I/O) relationship can be expressed symbolically as

See Figure 15.

Figure 15. A Transformational System

subject to appropriate external mechanisms and controls. A transformational system generates an output and then terminates.

A reactive system is a system that, when turned on, is able to create desired effects in its environment by enabling, enforcing, or preventing events in the environment.

Figure 16. Elements of a Reactive System

Reactive systems typically exist to collaborate or interact with some entity or entities in the environment (e.g., traffic controllers; process control). They never have all of their inputs ready -- rather, the inputs arrive in endless and perhaps unexpected sequences.

Formal Models of Development

An engineering model for analysis or design is said to be formal if it has semantics that are precise and unambiguous. That is, each term in the model/design has a well defined meaning. Tranformations among model/design representations will also be well defined.

Such models will be assembled from the following components:

1. A set of explicit or implicit equations which involve input, output and possibly internal (state) variables;
2. A set of properties that the design must satisfy given as a set of equations over design variables (i.e., inputs, outputs and states);
3. A set of performance indicies which evaluagte the quality of the design in terms of cost, reliability, and so forth, given as a set of equations involving design variables.
4. A set of constraints on design variables and on performance indicies specified as a set of inequalities.

Separation of Concerns

Complex systems are characterized by many components, concurrent subsystem level behaviors, and complicated communications and interactions among subsystems and components.

To facilitate understanding of these design issues/concerns, we aim to pull a design apart and examine it from perspectives (or "facets" or viewpoints) that are almost orthogonal, thereby factoring out so-called cross-cutting concerns (see details below). Achieving (almost) orthogonality of concerns is important because it means we can explore options in one viewpoint (or dimension of design) without affecting other concerns.

Figure 17 shows, for example, a simple design consisting of two communicating subsystems.

Figure 17. Separation of Design Concerns: Structure, Behavior, Communication

The task of understanding and evaluating a design (i.e., what it does, how it works, how it can be changed to improve performance) is simplified through the separate consideration of concerns:

• System Structure
  Models of system structure help an engineer understand how a system achieves its purpose. Principal concerns include:

      Understanding system Structure
      ========================================================================
        -- Objects
        -- Collections of objects
        -- Relationships among objects (e.g., decomposition of the system into
           hierarchies, connectivity of components/objects).
        -- Assignment of geometric properties (e.g., size, placement).
      ========================================================================
  

• System Behavior
  Models of system behavior capture the functionality of a systems -- that is, they describe what the system will do. Key concerns include:

      Understanding system behavior
      ========================================================================
        -- Capture/identification of basic system functions.
        -- Ordering and decomposition of functions.
        -- Identification of control structures through system logic.
        -- Identification of states of behavior.
      ========================================================================
  

  It is the ordering of these functions coupled with the system logic that produces the system behavior.

• Communication
  Communication concerns cover identification of interfaces to encapsulate object behavior and the selection of appropriate protocols for communication.

• System Optimization
  Sets of "inequality constraints" plus metrics for required functionality and performance lead to design optimization problems; that is, a systematic exploration of the space of possible design solutions to identify sets of good designs (i.e., satisfy all constraints) and then, maximize performance.

• System Validation/Verification
  Sets of "equality constraints" lead to procedures for formal validation/verification.

It is not hard to think of design applications where other types of concerns make sense (e.g., external environment vs system; connectivity).

Suppose that you have been given a quadratic equation:

    q(x) = ax^2 + bx + c 

with nonzero coefficents (a, b and c) and that you have been asked to find values of x for which

    q(x) = 0

Types of Solutions

Plots of q(x) versus x illustrate the three types of solution that are possible:

Figure 18. Types of Solution to a Quadratic Equation.

Algorithm. Step-by-step Solution Procedure

We need to devise an algorithm that is amenable to step-by-step solution on a computer. So here goes ... we are given that

   q(x) = ax^2 + bx + c = 0,

Hence for nonzero "a",

   q(x) = 4a(ax^2 + bx + c) = 0.

Completing the square gives:

   q(x) = (2ax + b)*(2ax + b) - b*b + 4ac = 0.

The terms can be easily rearranged to give the two solutions that we all learned in high school, i.e.,

    Root: x_1 = (-b + sqrt(b*b - 4*a*c))/2a
    Root: x_2 = (-b - sqrt(b*b - 4*a*c))/2a

Flowchart for Solution Procedure

Figure 19 shows the essential steps in a flowchart for computing and printing the roots to a quadratic equation.

Figure 19. Flowchart for Step-by-Step Solution to a Quadratic Equation.

A few key point:

• For the purposes of simplicity, we assume that coefficient "a" will be non-zero. This assumption eliminates the possibility of a straight-line.
• The flowchart contains both a branching construct (decision) and loop (repetitive operation).

Performance Assessment

From a theoretical standpoint, these formulae are all that you need to compute roots x_1 and x_2.

From a practical standpoint, however, a computer implementation will allocate a finite amount of space (usually 4 or 8 bytes) for the storage of each coefficient (a, b and c). This is usually sufficient for the accurate evaluation of the root values.

However, when two numbers of almost equal value are subtracted we can generally expect a significant loss of accuracy in the numerical result.

Subtractive cancellation occurs in the computation of x_1 when b*b >> 4*a*c. To overcome this problem, multiply the numerator and denomiator by:

    (-b - sqrt(b*b - 4*a*c)

Most Important Points ...

• Computers are generally incapable of finding solutions to equations (e.g., roots of polynomial equations, solutions to differential equations) by themselves. Instead, computers require a step-by-step solution procedure for evaluating the solution.

  This problem is simple enough that a formula can be derived for roots to the quadratic equation. However, most engineering problems do not lend themselves to analytic solutions and we need to rely on numerical approximations to the real solutions.

• A quadratic equation solver is effectively a transformational process, with input/output as follows:

       Input: Coefficients a, b and c.
      Output: Roots x_1 and x_2.
  

• Numerical algorithms need to take into account the computational limitations of computers.

Figure 20 shows a scenario where a tennis ball is hit with velocity V and angle "theta" to the horizontal plane. The ball is launched at a distance "d" from a net of height "h".

Figure 20. A Tennis Ball Projectile that only just Clears the Net.

System Structure and Behavior

• The system structure corresponds to the tennis court and the ball.
• System behavior is defined by the physics of ball movement and the initial conditions (Velocity and angle of launch).

Performance Requirements

1. Given the geometry of the tennis court (d) and height of the net (h), what is the minimum velocity that will allow the ball to clear the net?
2. For velocities greater than the minimum value, what angle should the ball be launched at so that it only just clears the net?

We also need to make sure that the ball doesn't go outside the court:

1. What constraints on velocity and angle exist to make sure that range of the tennis ball projectile is less than 2d, the total length of the court?

Outline of Solution

This problem can be solved in a number of ways, including trial and error. However, the best approach is to derive the equations of motion for the projectile behavior (it's pretty simple) and then constrain the projectile profile to match the boundary conditions (i.e., launch position and top of net).

Assumption: Ignore air resistance.

Horizontal behavior is defined by the equation:

    d^2 x(t)/d^2 t = 0.0. 

Integrating twice with respect to time t and inserting the boundary conditions gives:

    x(t) = [ V cos (theta) ] t

Similarly, vertical behavior is defined by

    d^2 y(t)/d^2 t = -g,

where g is acceleration due to gravity. Integrating twice with respect to time t and inserting the boundary condition for initial velocity gives:

    y(t) = [ V sin (theta) ] t - [ g/2 ]*t*t

Now we apply the boundary condition "the ball just clears the net".
In mathematical terms, this means that a some undetermined time t',

    x(t') = [ V cos (theta) ] t' = d
    y(t') = [ V sin (theta) ] t' - [ g/2 ]*t'*t' = h

Plugging the first equation into the second and rearranging terms leads to a quadratic equation in tan (theta), i.e.,

    A tan(theta)^2 + B tan (theta) + C = 0

where A, B, and C are symbolic expressions involving the problem parameters (h,d,g,V). Solutions to questions 1 and 2 are obtained through analysis of the quadratic equation roots.

Performance Assessment

Performance of the tennis ball trajectory is directly related to roots of the quadratic equation. Three cases exist:

• No real roots (i.e., B*B - 4*A*C < 0)
  For the given tennis court geometry and lauch velocity, the ball will not clear the net, nomatter what angle it is hit.
• Two real roots (i.e., B*B - 4*A*C > 0)
  Two trajectories exist: (1) shallow with high horizontal velocity; (2) very high with low horizontal velocity.
• One double root (i.e., B*B - 4*A*C = 0)
  This case corresponds to the minimum velocity where the ball with clear the net, and then, this is only at the most advantageoes angle (probably 45 degrees).

Most Important Points ...

• Engineering systems have dynamic behavior that is defined by conservation laws (e.g., conservation of energy, conservation of momentum) plus initial boundary conditions.
• Mathematical representations of dynamic behavior most often result in an equation (or family of equations). The solution to these equations -- analytical or numerical -- will provide insight to the underlying behavior (e.g., identify when two angles of launch are possible).
• Computer implementation:

       Input: g, h, d, and V.
      Output: angles theta1 and theta2.
  

  A computer implementation might also validate behavior by plotting the trajectory coordinates (x(t),y(t)).

iTunes (Windows and Mac OS X) is an easy-to-use software application for organization and execution of music files, videos, podcasts, and so forth. iTunes content can be synched with external devices such as the iPod, Apple TV, and iPhone.

Figure 21 is an annotated schematic for the iTunes graphical user interface.

Figure 21. iTunes Graphical User Interface

iTunes Object Model

iTunes stores its content (e.g., music files, video files) as a library of object. Each object is described by a set of attributes (e.g., name of the song, artist, genre, duration, date).

Figure 22. Schematic of a Music File Object

Music objects can be sorted by attribute. For this to work, iTunes needs a ways to systematically compare various types of attribute (e.g., names are ordered alphabetically, dates and durations require models of time and calendar).

Collections of Objects

What makes iTunes really neat is the ease with which: (1) Groups of objects can be organized into collections, and (2) Objects within a group can be ordered according to attribute values. according the

Figure 23. Library and Collections of Music File Objects

The data storage model is really quite simple:

• All music files are stored in the library.
• Music files can be accessed through a tree-hierarchy of folders and playlists. Folders can contain (other) folders or references to a playlist.
• A playlist is simply a collection of references to music objects in the library. Notice that multiple playlists can refer to a single music file.
• The iTunes graphical user interface is designed for ease of playlist assembly and organization of music objects according to object attribute values.

This framework is very general and, in fact, is employed by a host of Apple applications (e.g., iPhoto, Safari Web Browser, Final-Cut Pro for Video Editing).

Most Important Points ...

• Many engineering systems can be modeled as collections of objects (possibly thousands or millions of objects).
• Objects are described by their attributes.
• To simplify interpretation and access to objects, objects can be organized into groups.
• Similar groups of objects can be put into folders.
• In turn, folders and be organized into trees of folders.

Now let's consider behavior modeling for two-phase traffic flow at an intersection. Statechart diagrams can be used to describe the behavior of a single traffic light and a group of traffic lights at an intersection. Generally, groups of traffic lights will be controlled by a single traffic control box, as shown in Figure 24.

Figure 24. Schematic of a Two-Phase Traffic Intersection

Each traffic signal will have lights pointing in two directions -- for example, traffic signal 1 has lights pointing towards the South (S) and East (E).

Our goal for this question is to formulate a statechart diagram for the "traffic control box" operations when each light follows a green-yellow-red cycle and there is two-phase traffic control.

Symmetries and Constraints

Two-phase traffic flow

Figure 25. Details of Two-Phase Traffic Flow

implies:

• The lights facing North/South will be the same color at the same time. The same can be said for the lights facing E/W.
  That is,

      Signal 1 S = Signal 4 N
      Signal 2 S = Signal 3 N
      Signal 1 E = Signal 2 W
      Signal 4 E = Signal 3 E
  

• When one set of lights is either green or yellow, the other set of lights must be red.

• The N/S and E/W sets of lights must follow a regular, systematic pattern of switching colors.

The systematic pattern of switching colors could be affected by the time of day, cycle of the lights and time to cycle.

State Table

For "Phase A" (N/S) traffic flow, the light settings are:

    Signal/Direction     North           South     East     West
    ============================================================
    Signal 1 :             ---   Green, Yellow      Red      ---
    Signal 2 :             ---   Green, Yellow      ---      Red
    Signal 3 :   Green, Yellow             ---      ---      Red
    Signal 4 :   Green, Yellow             ---      Red      ---
    ============================================================

For "Phase B" (E/W) traffic flow, the light settings are:

    Signal/Direction  North  South           East           West
    ============================================================
    Signal 1 :          ---    Red  Green, Yellow            ---
    Signal 2 :          ---    Red            ---  Green, Yellow
    Signal 3 :          Red    ---            ---  Green, Yellow
    Signal 4 :          Red    ---  Green, Yellow            --- 
    ============================================================

Sequences of States

Taking into account symmetries and phase behavior, the sequence of states in the traffic light settings is as follows:

Figure 26. Sequences of States for Traffic Light Behavior

States 1 and 2 correspond to Phase A. Phase B corresponds to States 3 and 4.

StateChart Diagram

Now lets expand the behavior model by accounting for an error state -- all lights flashing red!!! -- and organizing the description of behavior into a hierarchy.

Figure 27. Statechart Description of Traffic Light Behavior

Clearly, classes for Phase A and Phase B could be expanded to include the detailed light settings described in the "state tables" and Figure 27.

Most Important Points ...

• Behavior of the traffic intersection control system is defined by a finite number of distinct states.
• Symmetries in behavior allow for the simplification of the behavior model.
• The distinct states of behavior can be easily shown with graphical modeling techniques (in this case Statecharts).
• A computer implementation should follow the structure of this graphical representation.

Motivating observation:

From an engineering perspective, the key challenge ahead is:

We are particularly interested in:

• Formal bases for describing and reasoning about high-level system architectural connection.
• Procedures for the vertical integration of topological and geometric information in design.
• Representations for superimposed information, where supplementary information can be used to highlight, annotate, elaborate and interconnect underlying information (Bowers)

Designers need to model and view artifacts at the highest level of abstraction (and minimal dimensionality) that is unambiguous with respect to the decision making at hand (Kalay, 1989).

Smart Buildings/Smart Spaces

Task/ambient conditioning systems allow thermal conditioning in small, localized zones to be individually controlled by building occupants, creating "micro-climates" with a building. Other functions include: security, identification and personalization, object tagging, and seismic monitoring.

Home Networking

Application (subnet) clusters.

• Appliance based -- ovens, toasters, refrigerators, clocks, sprinklers.
• Entertainment based -- VCR, video games, TV, stereo, DVD, digital camera.
• Security based -- video surveillance, smoke detection, lighting control, window and door sensors.
• PC/Data based -- laptop, printer, Internet connectivity.
• Telecom based -- video phone, intercom, PDA, video phone.

Figure 28. Smart Building

Established Approaches to Floorplan Design

A floorplan is

The plan shows placement of walls, doors and windows, fixtures for plumbing and electrical services, detail symbols and dimensions. At the meta-model level, we need support for:

• Objects
  Are the generalization of any semantically treated thing (or item) within the design model,

• Relationships
  Are the generalization of relationships among things (or items),

• Properties
  Are the generalization of characteristics (e.g., types) that may be assigned to objects.

The second level of object specification expands to seven entity types: products (physical objects), processes (timed actions taking place within a project), controls (constraints on objects), resources (use of an object mainly within a process) and actors.

Architectural floor planning processes are concerned with the hierarchical decomposition of spaces within blocks. During the early phases of design, shapes are transformed into "architectural regions" (e.g., rooms, groups of rooms) through the preliminary evaluation of properties (e.g., size, shape, orientation, adjacency) coupled with the assignment of properties to regions.

Requirements for architectural floor planning emanate from multiple sources, including national standards and user requirements. Often, the original user requirements will include a comprehensive list of specific rooms with planned area. Each stage of development deals with a subset of the design requirements. Decisions made at a high level of development will flow down to lower levels of development as constraints.

Multi-Level Specification of Floorplans and Services

We want to create a "design tool" for the interactive system-level development of building architectures augmented by services (e.g., plumbing and lighting systems; internet services; security services). Researchers at Berkeley have created a multi-level abstraction of building designs that can be read by computers and support partial run-time evaluation of design rules.

Figure 29. Framework for Multi-level Specification of Building Function and Form

Floor plans are organized into levels of progressive detail: organizational (i.e., clustering of spaces), symbolic (i.e., room contours; connected wall segments), simple geometry (i.e., thick walls; fleshed out columns; openings for doorways and windows).

1. Programmatic Level Level.
   High-level systems stuff (functional requirements; proximity matrices)
2. Organizational Level.
   Hierarchical bubble diagrams; clustered connection diagrams.
3. Symbolic Layout Level.
   Room contours; connected symbolic wall segments.
4. Simple Geometry.
   Thick walls, fleshed-out columns, cut-out doors and windows.
5. Detailed 3D Geometry.
   Add wall details.
6. Construction and Project Management.
   Identify and organize construction/project management tasks.

Since different tools require different representations in order to perform their tasks, the key contribution of this work is an interchange language. Tools for floorplan layout and extrusion to 3D geometries have been written.

To keep the the complexity of computation for geometric reasoning among an arbitrary number of components in check, the building geometry will need to be organized into a hierarchy of localized coordinate systems (e.g., a room; a space; small groups of rooms and spaces having a related function) that depend on the objects concerned.

Floorplan Design for an Apartment

Development of a small apartment building can be viewed as a goal driven process, subject to constraints:

• Topological (i.e., orientation, traffic/pathway, and location/adjacency concerns),
• Dimensional (i.e., size and space concerns) and
• Functional (e.g., aesthetic concerns).

The step-by-step development procedure might be as follows:

Part 1. Clustering and Organization of Spaces/Rooms

At this point we are interested in identifying objects, relationships among objects, and properties that may need to exist to support evaluation of requirements.

Figure 30. From Requirements to Organizational Hierarchies/Clusters

Figure 30 shows the pathway from high-level requirements to a decomposition hierarchy (clusters of objects and their relationships), proximity relationships, and structure connectivity diagram.

Constraints/Proximity Concerns

An example of an orientation constraint is:

• Bedrooms should face open air....

High-level topological constraints include factors like,

• "The kitchen should be close to the living room" and,
• "You should be able to go from the bedroom to the bathroom without having to pass through the kitchen" and,
• "The bedrooms should not be immediately adjacent to the entrance."

In order to avoid ambiguity of the allowed operations in an interactive design phase and also to make the implementation efficient and tractable, certain restrictions on allowable geometrical configurations have to be imposed. One such restriction might be a strictly nested hierarchy of polygon contours.

Multiple Concerns in AEC

Architecture, Engineering and Construction (AEC) environments are inherently multi-disciplinary. Participating disciplines include architects, structural and mechanical engineers, and construction personnel.

Viewpoints and Representations

A summary of viewpoints and representations for disciplines involved in AEC is as follows:

Representation of Architectural Domain Concepts

Architects are concerned with the spatial layout of a system, and a systems functionality and performance.

Figure 31. Decomposition, Layout, and Connectivity of Spaces in a Building

Within the "space decomposition" concern, Figure 31 says:

• Spaces are a generalization of regions and boundaries.
• Regions are a generalization of outside and rooms.
• Boundaries are a composition of nodes and dividers.
• Nodes can be connected to multiple dividers. Conversely, dividers can be connected to multiple nodes.
• Dividers are a generalization of walls, floors, and ceilings (not shown).
• Portals are a generalization of windows, doors, and openings.
• Dividers border (and help to define) rooms.
• Dividers contain portals.
• Portals connect regions (e.g., a doorway from a room to the outside).
• Rooms can be classified as offices, hallways, kitchens ... etc (details not shown).
• The classes Room and Outside are disjoint (that is, if a region is Room then it cannot be Outside, and vice versa).

Figure 31 abstracts spaces to the "block/object level" -- at this point we have not said anything about the geometry of spaces, nor how relationships among collections of spaces would be evaluated.

Architectural spaces can be assigned to Groups.

Figure 32. Organization of Architectural Spaces into Groups

Here, we extend Figure 32 to include two types of groups, Bays and Floors (could also include concepts like Wings, ...etc).

Specific Example: Small Holiday Home

Figure 33 shows an end elevation and simplified plan view of a small holiday home -- think of a kitchen on the first floor, a small living area, and a bedroom in a loft. The living room spans two floor levels and may be viewed from the loft.

Figure 33. Schematic/data structure for symbolic representation of floorplans.

From an architectural standpoint, we note:

• The "living room, kitchen and loft" are specific instances of spaces, which also happen to be rooms.
• The rooms are surrounded by walls -- most of the walls contain portal openings, doorways and windows.
• Access to the loft is provided via a stairway.

Although not explicitly stated, there are lots of architectural constraints implied by these views, e.g.,

• Windows and doorways need to be part of walls -- you are not allowed to put a doorway in the middle of a room!!!
• Access to/from the outside has to occur at ground level -- in this particular example, you are not allowed to put a door to the outside on the second floor level.
• Portals (e.g., openings, doorways and windows) need to be spaced apart.
• etc, etc, ... etc.

We hope that UML's "association class" diagrams will be a good way of graphically showing the required constraints.

Representation of Structural Engineering Concepts

Structural engineers are concerned with estimation of loads on a structure and the design and proportioning of a structural system that can safely transfer these loads from the structure to the ground.

Figure 34. High-level class diagram for structural design
(Adapted from Biedermann and Grierson, 1995)

Figure 34 diagram says:

• A structure corresponds to components and nodes.
• Component is a generalization of beam, column and rafter classes (see example below).
• Each node has a unique geometry (position).
• Each component will be connected to multiple nodes (e.g., beam and column elements are connected to two nodes).
• Conversely, nodes may be connected to multiple elements.
• The structure may also be described via groups of components.
• Group is a generalized concept for Bay, Storey, Floor and Roof.
• Components can belong to zero or more groups.

Figure 34 only includes those aspects of the problem that will interact with the architecture domain. Not included are classes for the "loads" that a structure will support, nor the "materials" from which the structural components would be built.

Specific Example: Small Holiday Home

The high-level classes can be decomposed into class hierarchies, e.g.,

Figure 35. Object Diagram and Concepts for a Simple Building

The structural system in Figure 35 has 10 nodes and 12 components. An example of a group assignment is as follows:

    Group: Bay 1 
    =========================================
    Column elements  1, 2, 4, 5, and 7,
    Beam   element   8,
    Rafter elements  9 and 11.

    These elements are connected to:

    Nodes            1, 2, 4, 5, 7, 8 and 10.
    =========================================

At the system-level, structural engineers are primarily concerned with the connectivity of structural elements and the pathway of loads from point of application to the ground. From an external viewpoint, the structure doesn't do much -- it just sits there!!! Engineers view behavior in terms of how the structural system responds to different types and magnitudes of external loads. If a small load leads to a very large deflection, then even if the structure is not even close to material failure, people will not go inside the structure.

Most Important Points ...

• Like the iTunes example, the design of buildings is dominated by objects.
• However, the relationship among concepts and objects for buildings/building services is much more complicated.
• Why? Buildings contain a range of object types, not just one type. An object may serve multiple purposes -- for example, a structural engineer will say "...this wall transfers gravity loads to the foundation." An architect will look at the same wall element and say "...this wall element defines the boundary to this space/room."
• The best solution to this class of problems has yet to be found.

The current offerings of ENCE 200 and ENCE 201 focus on software development in Java and Matlab.

In past semesters, we have attempted to cover a bit of each language in each course; we have learned that this strategy sometimes overloads students and leads to confusion.

Hence, to avoid those problems, Matlab is now covered in ENCE 201, and we will stick to Java in ENCE 200.

Software Development with MATLAB (ENCE 201)

The Matlab programming language has been around since the mid 1980s. It stands for Matrix Laboratory.

Figure 36. Flowchart for Software Development in MATLAB

Strengths of Matlab

• Matlab is a great language for the solution of engineering problems that can be expressed in a matrix format and solved using principles from linear algebra. For example:

  • Solution of equations that describe the behavior of an engineering system (e.g., the distribution of forces in a bridge structure).
  • Analysis of data collected from experiments.

• The Matlab language has all of the control structures (e.g., loops, branching) that you expect in a good language, plus m-files, a mechanism for organizing solution procedures into hierarchies of function calls.
• Matlab graphics is easy to use.
• Matlab code is interpreted and pretty high-level. Sometimes with just a few lines of Matlab you can accomplish a task that requires 50-100 lines of code in Java/C.
• Matlab now has an incredibly wide range of toolboxes (e.g., for optimization, control, signal processing, symbolic computations).
• Matlab can communicate with software programs written in Java and C.

Weaknesses of Matlab

• In places, the language syntax is a bit rough .. you can do things in Matlab (cut corners) that no other language can do .. this is not necessarily good.
• Compared to Java, Matlab's support for objects is weak.

Software Development with Java (ENCE 200)

The Java programming langage was invented in the early 1990s (..a lot more on this later in the class). The original goal was to create a language for the development of software that would bring dynamic content to web pages (e.g., embedding a spreadsheet inside a web page).

Figure 37. Flowchart for Software Development in Java

Strengths of Java

• Java is both a compiled and interpreted language. Java source code is compiled into a bytecode format. The bytecode instructions are then read and interpreted by the Java Virtual Machine.
• Bytecodes are the lowest possible instruction format that remain architecture neutral. As a result, the bytecode can travel across the Internet and execute on any computer that has a Java Virtual Machine.
• Java is an object-oriented language. Engineering systems are modeled as collections of objects. Implementation details are made efficient by exploiting the relationship among objects.
• Java is now used by millions of people and in an incredibly wide range of products (e.g., scientific data processing, computer games, databases, cell phones, navigation systems in automobiles, data processing support for online shopping).

Weaknesses of Java

• There's a lot to learn, especially if you want to become really good at developing software in Java.

Our goals for this class will be to simply cover the basics.

At the end of the class you should be able to design, write, compile and run a java program that solves a simple engineering problem.

Modified in January 2008 by Mark Austin
Copyright © 2007-2008, Mark Austin, University of Maryland.