SALDOS Y OPERACIONES CON OTRAS PARTES RELACIONADAS

First Last Age Amount State Party

William Shell 61 1,300 WI D Lisa Dough 19 125 WY T Helen Lobby 35 1,200 CA R Reggie Green 33 800 NY R Harvey Levirage 41 500 NY I Robin Round 32 200 NY D Jennifer Dichali 38 650 WI D

most real-world databases requires sophisticated software to extract and analyze data of interest.

Fortunately, databases are designed to efficiently locate records in response to well-formed queries. Although somewhat similar to a web search, a database query requires more precise structure and is generally written in a language known as SQL, which is short for Structured Query Language. Records in a database are located by issuing a select statement. The general form of a select statement is given as

SELECT field1, field2, …, fieldN FROM table WHERE criteria

where the italicized elements represents the details that control what data is retrieved. Consider writing an SQL query to select the names of donors who have contributed at least $500. Since we are only interested in the names of the individuals, we would select only the First and Last fields. We are selecting data from the Donor table and the criteria that determines which elements to select is expressed as Amount >= 500. The proper SQL query is given as

SELECT First, Last FROM Donor WHERE Amount >= 500

The criterion of this select statement is a simple logical predicate that locates and retrieves only those records of interest to the lobbyist. The result of the select statement is a list of five donors: William Shell, Helen Lobby, Reggie Green, Harvey Levirage, and Jennifer Dichali. Consider, however, a scenario where the lobbyist wants to specifically target only those donors who are under 40 years of age and have contributed at least $500 in the past. This requires a more sophisticated criterion; a criterion that is expressed as a compound logical predicate and produces a list of the three donors: Helen Lobby, Reggie Green, and Jennifer Dichali.

SELECT First, Last FROM Donor WHERE Amount >= 500 AND Age < 40

Perhaps the lobbyist wants to specifically target only those donors who live in either the coastal states of New York or California regardless of their age or their past donations. The appropriate SQL query is expressed as

Note that the terms NY and CA must be enclosed in quotations to dis- tinguish those elements as merely textual elements. This query produces a list of four donors: Helen Lobby, Reggie Green, Harvey Levirage, and Robin Round.

For our final example, consider an SQL query to locate every donor that is under 40 years of age, has donated at least $500 in the past, and lives in either New York or California. The table contains only two such donors: Helen Lobby and Reggie Green. The SQL query to generate this list is given as

SELECT First, Last FROM Donor WHERE Age < 40 AND Amount >= 500 AND (State = ‘NY’ OR State = ‘CA’)

The ability to precisely express database queries as logical predicates is a vital skill for anyone who works with large amounts of structured data. 3.3.5 Software Requirements

When a software engineer is hired by a client to write software, the first and often the most difficult aspect of the job is to define as precisely as possible what the software should do. The process of defining what a piece of soft- ware should do is known as requirements engineering. Typically, the soft- ware engineer will schedule a series of meetings with the client and spend hours talking to everyone interested in the software that is being created. The software engineer will make sure that every detail of everything that is discussed in these meetings is written down and precisely defined so that there is one common understanding of every aspect of the system.

The end result of requirements engineering is a document known as the software requirements document. This document is a very precise defi- nition of what the software should do once it has actually been written. The software requirements document often serves as a formal contract between the client and the software engineer, and hence both the client and the software engineer must both agree that the software requirements document is a precise definition of what the software should do. This necessitates that the document should also written in such a way that both the client (often a nontechnical person or company) and the engineer are able to fully understand.

Logical propositions are often used to define important functions of a large software project. Consider, for example, a corporate client that has hired a software engineer to write software to control an elevator system

for a small four-floor office building. The elevator has two doors that are known as the front and the rear door. The front doors are usable only on the first two floors, and the rear doors are usable only on the top two floors. An interview session between Germaine, the software engineer, and Aditi, the main corporate contact, might go something like the fol- lowing dialogue.

Germaine: What should happen when the “open door” button is pressed? Aditi: The door should open.

Germaine: The front door or the rear door or both?

Aditi: The front door should open if the elevator is on either floor 1 or 2, oth- erwise the rear door should open.

Germaine: What if the “open door” and “close door” buttons are pressed at the same time?

Aditi: Hmmm. I hadn’t thought about that. I guess nothing should happen. Germaine: What if the elevator is moving between two floors and the

“open door” button is pressed? Aditi: Nothing should happen.

Germaine: What if emergency personnel have inserted a key to manually override the software control system. In that case, what should happen when the “open door” button is pressed?

Aditi: Hmmmm. That’s a good question. I guess that both the front and rear doors should open regardless of which floor the elevator is on or even if the elevator is moving between floors.

After several discussions, Germaine will then include a specification for the “open door” function of the elevator. This function will likely involve a number of logical predicates that very precisely define what should hap- pen when the “open door” button is pressed. The functionality might be described in the following manner.

Description: The elevator contains both an “open door” button and a key slot that is intended for the use of emergency personnel. The following specification defines what the control software should do when the “open door” button is pushed.

• (FLOOR=1 OR FLOOR=2) AND (NOT MOVING) AND BUTTON_PUSHED IMPLIES FRONT_DOOR_OPENS

• (FLOOR=3 OR FLOOR=4) AND (NOT MOVING) AND BUTTON_PUSHED IMPLIES REAR_DOOR_OPENS

• (EMERGENCY_KEY_INSERTED AND BUTTON_ PUSHED) IMPLIES (FRONT_DOOR_OPENS AND REAR_DOOR_OPENS)

• In all other cases, the system must do nothing

Software systems that might cause significant harm if they operate improperly are known as safety-critical systems and are specified using very precise mathematics. Software that controls an artificial heart, an insulin pump, a medical CT scanner, a national air-traffic control sys- tem, the automatic pilot software on a large commercial jetliner, or the control software of a nuclear power plant are all known as safety-critical systems. Formal methods are a set of mathematically rigorous techniques for the specification and development of safety-critical software systems. Although most software systems are specified using a mixture of math- ematical formalisms and nonmathematical descriptions, the more critical the system, the more formal the specification must be.

TERMINOLOGY