i051002
TROST
InfoNote
What Computers Know
But What's the Use?
|
|
i051002
TROST
InfoNote |
Bill Anderson and I have a running conversation on the difference between what computers are and the use we make of them. We've explored that question for a long time, almost the full 30 years we've known each other. In recent buddy calls between Seattle and Rye, New York, it seems to us that much is starting to crystallize in our thinking. We want to expand this conversation onto our blogs and engage with others, out loud and on the record. My kick-off contribution is to draw together some of the themes about the nature of computation that solidified as I researched the TROST project. Here's the first piece.
- Latest version: The latest version of this InfoNote is available on the Internet at
<http://TROSTing.org/info/2005/10/i051002b.htm>.- This version: 0.80 <http://TROSTing.org/info/2005/10/i051002f.htm> is one of the first complete versions. Consult this page for the latest status and current electronic copies of this version.
- Previous version: 0.50 <http://TROSTing.org/info/2005/10/i051002e.htm> was the last rough draft.
- See also: Orcmid's Lair 2006-02-03: What Computers Know, an abridged version of this article
The purpose of this article is to expose how pitifully impaired the computer is in regard to matters of the world and the physical reality in which human beings operate. I suspect that most people will say they already know that. The reason for my dragging out this demonstration is I don't see that reflected in how people speak about software and how they behave as software developers and adopters.
I believe that a profound appreciation of what little a computer could be aware of, were awareness even required, is necessary before we can respect how computers are so marvelous and what there is that has computers be such useful instruments.
I contend that as valuable as digital computers are, the demonstrable chasm between the computer and the world of human experience and action is not to be bridged. It is important to appreciate this as we work diligently to provide computer software that is dependably useful.
1. Computers and Embodied Knowledge
1.1 The Knowing Computer
1.2 Dumb Enough to Follow Instructions
2. Acting Like a Computer
2.1 A Digital-Human Program
2.2 Computer and Non-Computer Rôles
2.3 Instructing the Digital Human
3. What It Is ≠ What It's For
3.1 Catching Our Breath
3.2 A Computation Isn't What It Is For
4. Answers Good and Not-So-Good: Calculation vs. Reality
4.1 Not All Errors Are Detected
4.2 Theory Is Not Reality
5. Thinking It Over
5.1 The Isolation of Programs from Reality
5.2 The Gap That Cannot Be Closed
5.3 Take-Aways
6. Looking Ahead
6.1 The Working of Computation
6.2 What Programmers Know
6.3 Enterprise-Situated Computing
6.4 Trustworthy Accomplishment
7. Resources and References
The first step is to consider what it means for a computer to know something. We mean know in the sense of ability to faithfully carry out the programs that are encoded in the form accepted by the computer's processor.
1.1.1 I want to inquire into what it is that a computer can be said to know.
1.1.2 I'm not considering that a computer has any form of sentience. I am using "knowing" in the sense of embodied knowledge, in the way that one speaks of embodied action (Denning 2002; Gladwell 2005). It's akin to our talking about what your wristwatch says the time is, as if the watch knows how to tell time, as if it knows the time.
1.1.3 I am using "knowing" in the sense that our male cat, Teh Amor, knows how to spring five feet in the air from a motionless crouch on the floor and straddle my shoulders, landing perfectly lightly with no harm to either of us (Devlin 2005). It is in the sense that we can imagine the cat knowing (in the sense of embodying) ballistics and calculus that I mean when I speak of a computer knowing something.
1.1.4 In particular, if the computer has some innate knowledge, in the way that Teh knows how to leap onto a high perch, what would it be?
1.2.1 Computers are commonly spoken of as dumb (that is, stupid) and only able to do what they are told. We could say that its conduct is mindless. This reassuring platitude, not heard so much lately, is both accurate and also quite marvelous. I want to take a different angle that doesn't overlook the marvelous part.
1.2.2 I want to look at the kind of thing a computer is doing when it is doing its thing. I will set aside how it does it, certainly not why it does it, but simply what it is doing.
1.2.3 This may give us a greater appreciation for just what it is that a computer is told that it carries out in its mindless, unerring way.
There are circumstances under which we perform much like a computer does. Let's call that performing as a digital human. In looking at how we can play-act as a computer, I have an everyday example for those in the United States who have personal checking accounts. My example of a digital-human programs is the instructions banks provide for reconciling bank statements with your own check register. There are some amazing features to notice about this kind of activity as performed by a human being versus by a computer.
2.1.1 Every month my bank sends me a digital-human program along with some data. Let's take a look at that program to develop our sense of what it's like to "merely follow instructions," and exactly what kind of instructions those are (Fig. 1).
Figure 1. Some Digital-Human Software 2.1.2 Years ago, when I maintained my checkbook by hand, I would follow a procedure similar to the one shown here. I would follow the drill and arrive at a number. Sometimes I would achieve agreement with the balance in my check register. Other times there would be a discrepancy. When electronic calculators became commonplace my error rate decreased and the overall process went more quickly. Now I let Microsoft Money figure it out from downloaded bank statements. (Now when there are occasional discrepancies, it is much more difficult to figure out what happened.)
2.1.3 When performing manual reconciliations, I developed alternative ways of repeating the procedure when it didn't balance the first time: adding the list from bottom to top instead of top to bottom; adding up blocks of numbers, then adding all of the block totals; changing the order in which I reviewed my check book; and other variations such that if I had made an arithmetic error, I would be less likely to make it the same way again. I also verified all of the numbers once again, both on the bank statement and in my checkbook. Sometimes I had read the checkbook entry incorrectly. Also, the amount of the discrepancy often provided a clue for what to look for, such as an outstanding check that I failed to list.
2.1.4 It was rare to find a genuine discrepancy and it could be maddening when one did occur. I've never forgotten the occasion, over 35 years ago, when I failed to notice that the starting balance of the current month was different than the ending balance on the previous month's statement. A deposit had been credited to my account, but it wasn't accounted for by a line-item, and I couldn't figure out why I had too much money in the bank when I carried out the reconciliation procedure. I finally noticed the statement discrepancy. I was extra-watchful in the next few months to see if it happened again or if the deposit was finally acknowledged. There were no more hiccups and the silently-included deposit never did appear on any statement.
2.2.1 Look at the reconciliation worksheet and notice its miniscule rôle in the drama narrated in the preceding section.
2.2.2 Much is left unsaid. It is important to understand that the digital-human part, the part specified in the worksheet instructions, is only a small part of what I as the user of the procedure am engaged in. In particular, the worksheet instructions say nothing whatsoever about what to do if the calculated ending balance disagrees with my check register balance.
2.2.3 The digital-human part is rote and mechanical (although designed to expose mechanical errors because the procedure is indeed being performed by a human being). It depends on the correct entry and manipulation of numbers and that is all. It does not depend on facts other than that. There is some appeal to actions in the world and to use of objects not in evidence: the check register, the bank statement, and different kinds of transactions, and their amounts, that must be obtained. The statement is, in fact, intended for a human being and there is reliance on knowledge someone who is prepared to follow the procedure would already have. (See sections 2.3.1 and 3.1, below.)
2.2.4 When there is a discrepancy, the procedure cannot provide advice because there are no facts in evidence on which to base any recommendation.
2.2.5 As the human observer of my digital-human activity, I can verify the data and the calculation. If discrepancy persists and is consistent, I must look elsewhere for the source of error. It is fruitless for the author of the procedure to presume where that might be. This does not deter software producers from taking liberties in this regard and elevating their speculations to designed-in facts, but that's another story. The reproducible nature of the procedure is also very important for dealing with discrepancies. If the calculation were not testable and verifiable, the entire effort to reconcile a bank statement would be useless, and that is an extremely important factor. Another is that the real accounts and the rules followed for currency transactions are consistent with the theory reflected in the statements and check registers and the reconciliation procedure. Without that much, we wouldn't have computation as an useful practice.
2.2.6 Because a person is playing computer and is also the one having a purpose for carrying out the procedure, it may be difficult to separate out the rote procedural part and recognize how purposeless it is when taken by itself. This is important to appreciate, because it is part of the marvel and mystery of computation.
2.3.1 To understand better what little a computer might know, we are going to remove everything a computer cannot know and see what's left. It is as if the digital human is a prisoner in a locked room who has never seen anything of the outside world. In this case, there are no longer objects like check registers, bank statements, and bank-account transactions. All of that is elsewhere. What comes to the attention of this digital human is recorded data without any sense of its origin.
Figure 2. Setup for Playing Imprisoned Digital Human2.3.2 Playing the Digital-Human Game. There is a simple procedure that is followed every time the digital human acts (Table 1):
Table 1. Digital-Human Play Action (simplified)
1. Suddenly, the Green light is flashing and a bell is ringing.
2. In front of you is a list of instructions written as elements in a fixed code, like a restricted, private language.
3. You progress through the instructions and carry out the actions specified in the code. You know exactly what to do. You've always known.
4. The only actions that the instructions can specify are for manipulating elements just like those of the coded instructions:a. move an element from the in-slot to a scratch-pad
b. move an element from a scratch-pad to the out-slot
c. transform an element according to a known rule and put the result on a scratch-pad
d. take the element on a given scratch-pad as the next instruction of the program, continuing from theree. inspect an element and skip the next instruction if a particular condition is satisfied
5. Suddenly, the red light is flashing and a bell is ringing. Everything stops. Nothingness.
6. Suddenly, the green light is flashing and a bell is ringing ...2.3.3 Computer programmers and scientists will notice that the description is a bit oversimplified, omitting some important housekeeping (such as keeping track of and re-using the scratch-pad sheets). There is enough to make the key point. This mind-numbing experience is no problem for the digital human. As a computer, it is all there is. There is nothing else to be concerned about. That there could even be anything else is beyond its ken.
2.3.4 The challenge of instruction. As the instructor of the computer, all you can do is signal start and provide coded elements at the input slot and record the elements that appear at the output slot. You can stop the computer. These are the only actions available to you. Your interaction with the computer is extremely limited (Table 2):
Table 2. Restrictive Interaction with the Computer
1. You can't tell it what you want.
2. You can only tell it what to do.
3. You can only use what it is already able to do.
4. You must communicate in a fixed code of elements that area. all it can accept as input,
b. all it can act upon and employ in its operations,
c. all it can report as output results
5. There's nothing that it can do in its world that has any bearing on your world except by coincidence.
6. Why you're having it do what it does is unknowable to it.2.3.5 This is the fundamental relationship between computers and those who instruct them or employ them as instruments in something else (such as reconciliation of a bank statement).
2.3.6 This is enough, along with astounding progress in electronics and computer software, to accomplish everything that we have achieved since the commercial introduction of the modern digital computer barely 55 years ago (Winegrad & Akera 1996). Nothing we know to do has altered the basic approach sketched here.
When we look at the mechanical nature of the computer's instruction, it should be apparent that the computer program is devoid of any connection to an external reality beyond the internal process of the computer and its program. The bank's instructions are almost as barren. They refer to objects that we are expected to be able to lay hands on, but that's about the only difference. In particular, nothing about the instructions from the bank tells us why we are to follow that procedure and what we are to make of either achieving the specified agreement of amount or of failing to do so. In telling the computer only what to do, we leave behind anything about what it is for. Not only is there no connection to any earthly purpose, it is not possible to create one in the domain in which the digital computer carries out its programs.
3.1.1 At this point, I encourage review of the situation portrayed in section 2.1, A Digital-Human Program. Notice how little is actually explained in the "Account Balance Determination Worksheet" (Figure 1).
3.1.2 There are alternative ways the procedure might be expressed without altering the purpose and intended outcome. This is illustrated by another form I receive every month (Figure 3):
Figure 3. Alternative Statement Reconciliation Procedure 3.1.3 The procedures are expressed using tacitly-understood terms that apply in the banking industry and that might not make much sense to someone with no accounting training or experience (e.g., the use of "reconcilement" and "prove" in Figure 3). You or I might be frustrated by that language, but it is also likely that we are able to proceed even with only vague understanding of accounting jargon.
3.1.4 The two descriptions carry different assertions about the purpose of the procedure: "to prove the ending balance as shown on your statement" in Figure 3 versus "calculate your overall balance" in Figure 1. I think the second confuses formality with reality in much the same way that computer programs are sometimes mistakenly called solutions to problems of ours. Fundamentally though, the procedure given in each description is adequate guidance for getting the job done.
3.2.1 The fact that there are different ways to achieve the same result suggests that there's something else we need to know. It might be a matter of algebraic equivalence: two arithmetic procedures that always lead to the same result when performed correctly. My different ways of carrying out the parts of the procedure to find a discrepancy is an example of that kind of equivalence (section 2.1.3).
3.2.2 It might be that the differences are simply incidental in the context of how the computation is being used. Perhaps there is something invariant in what the computation is used for; anything that is merely incidental to accomplishing that essential purpose is irrelevant.
3.2.3 Here's what the procedure means to me. I think of the checks (the bank drafts) that I write as promises to pay an agreed amount to someone else. The promise includes that the recipient can receive the funds by presenting the check to my bank (probably through their bank). So the other part of my promise is that the funds will be available on deposit when the check is presented for payment. The balance procedure is a way for me to be sure that my funds were sufficient to cover the checks that have already been honored by my bank and remain sufficient to cover those checks I've written and that were not cashed by the time the bank statement was produced.
3.2.4 It is all about honoring the promises of payment that I have made. This is not reflected in the procedure. The procedure itself isn't about that. The procedure is useful in my ensuring that funds are available for fulfilling my promise of payment on submission of the check. The procedure is useful for that. It is not what the procedure is.
3.2.5 If I'm extremely risk-averse (or distrustful of my ability to reconcile my account with any accuracy) I can also arrange overdraft-protection loans, automatic transfers from savings, and other safeguards. The procedure doesn't have to address that. In fact, the procedure works with the addition of those measures, so long as they are reported on my statement and I make note of them during the reconciliation.
3.2.6 Detection of fraud and bank error might also be of concern. In these days of electronic payments, debit cards, and identity theft the purpose of carrying out the reconciliation might also be to detect erroneous charges and disbursements of funds. In this case, there will be transactions not reflected in the check register or any record of mine, and matching against the bank statement will reveal that. This also catches legitimate transactions that I failed to record.
3.2.7 What it's for, and to whom, is not to be found in the computation. None of these human purposes and concerns are evident in the barren act of computation itself. The digital human will be oblivious to such considerations.
3.2.8 It's theory in practice. Consider that what we have, whether we pay attention to it or not, is a theory of monetary promises and payments that involves two different snapshots of the world. The first snapshot is of the promises that I have made and their amounts, up to this time. The second snapshot is the bank statement reflecting the starting balance, funds received and dispersed, and the associated transactions, up to the date at which the statement was produced. The theory involves arithmetic with the transaction amounts. This theory predicts that in the absence of error in either snapshot there is a confirmable arithmetic relationship between the data of the two snapshots. If computation does not arrive at the theoretically-assured result, that is indication of error in the computation or one or the other snapshot (or both).
3.2.9 The theory is not found in the procedure. The theory, based entirely on an external situation involving quantities on which arithmetic can be applied, justifies the procedure. But it is not present in the procedure and carrying out the computation does not require us to know or understand the theory. We might follow the procedure simply because we trust that it works. The digital human follows the procedure because that's what the digital human does.
When the procedure is being applied in reconciling a bank statement with a checkbook, accounting for a discrepancy in the calculated result is important. When there is no discrepancy, does that mean all is right with the world? Not necessarily. Knowing the theory and recognizing its relationship to reality is never enough to have contained reality in the theory. The application of theory to reality is always contingent and incomplete.
4.1.1 First, with regard to the procedure itself, there is the possibility of compensating errors that have the calculated ending balance agree with the checkbook.
4.1.2 I have had erroneous checkbook entries that balanced each other out. I only noticed because I was looking for a penny and I found a bigger discrepancy. The compensating error was not dangerous, because ultimately the status of funds in the bank was not impacted.
4.1.3 Why do we trust the result? For me, when the procedure confirms my (adjusted) checkbook balance, I am willing to risk the slight chance that I missed something. The danger of there being an unexpected overdraft is remote and maintaining a reasonable balance is probably protection enough. If the discrepancy is material to future balancing of the account, it will show up. Otherwise, it will have never mattered with regard to assuring available funds against promised payments. But mostly we trust the result because we believe that balancing means our accounts are in order and reconciled.
4.2.1 Does successful reconciliation mean that everything is in order and there will be no problems? Not necessarily.
4.2.2 Cash Flow Is Ignored. Although the procedure predicts the ending-status of the account when all outstanding transactions are completed, it does not indicate whether an overdraft condition may occur -- may have already occurred -- depending on the order in which deposits and checks are cleared through the bank. The procedure does not provide any assurance in the matter. It does not deal with cash flow in any way.
4.2.3 There are other real-life factors that the procedure does not address. Any outstanding deposits consisting of payments by check may be returned from the payer's bank because of insufficient funds or any other reason. Suddenly, not only is the presumed state of the account incorrect, there will be unexpected charges if the bank imposes a fee for failed deposits, not just for your own overdrafts. And that means I may be bouncing one or more checks and I will be assessed even-larger overdraft fees. The spiral continues until I get wind of the situation and find a way to prevent further overdrafts. Banks in the United States offer special protection against this situation, but having gone decades between overdrafts, I never think to arrange it. (I shouldn't have written this. I just had a costly overdraft. The bank covered me, so my promise was kept, but it was an expensive experience.)
4.2.4 It's all hypothetical. The reconciliation procedure provides only a hypothetical prediction of the account's status, even when there are no errors of calculation and the reconciliation is successful. What the computer "knows" is how to carry out the calculation it is instructed to perform. There is no guarantee that the theoretically-justified result will have anything to do with the actual course of events, despite the fact that the result is dependable most of the time.
Turing conjectured that, initially, at least, computers might be suited to purely symbolic tasks, those presupposing no "contact with the outside world," like mathematics, cryptanalysis, and chess-playing (for which he himself worked out the first programs on paper). But he imagined a day when a machine could simulate human mental abilities so well as to raise the question of whether it was actually capable of thought.
— Jim Holt, Code-Breaker: The Life and Death of Alan Turing,
The Critics, Book section, The New Yorker, February 6, 2006
5.1.1 In a very real sense, computer programs have never had contact with the outside world. Even with input-output, as presented in the digital-human example, there is no real contact. It is all done with encodings that the computer manipulates without any concern for their origins, destinations, or usage by actors in the computer-external world. In terms of the immediate behavior of the computer in following its program, there is no sense in which the the software injects any awareness of a connected world. Nor can it. This is a fundamental limitation of computers as we know to build them and as Alan Turing characterized them 15 years before the first commercially-offered digital computer was put into operation.
5.1.2 Computers are often embedded in systems that interact in the world, as robot-operated vehicles and Martian explorers demonstrate. Yet in the internal workings of the digital computer, the software programs are as isolated as in our example. The choreography of coincidence between sensors, internal manipulations and external responses is known and understood by the developers of the overall system. In the domain where the computer is following its program, the action is isolated and mysterious. The program directs the computer's dealing with the in- and out-boxes in an oblivious and unerring way.
5.1.3 If we want to see some way that computers are autonomously engaged in the world, perhaps in a tiny step towards some modicum of intelligent behavior, we need to look at the system in which the computer is embedded as an instrument, just as an accurate clock is an instrument of navigation only when employed for that purpose in an encompassing system. We do not expect the clock to reveal any awareness of its instrumental use. It is apparently no more necessary of a computer, slavishly carrying out the computational procedure encoded in its programs.
5.2.1 It would be foolish to predict that computers will always be isolated from reality in the way that we saw for the digital human and the domain in which the digital human acted to produce computations. That's a different question and, as a practical matter, it is not necessary to address it.
5.2.2 The billions of computers operating at this moment, and all of those that have been built so far, operate in this isolation. The separation of programs and computations from reality is a fact for today's world. That's unlikely to change very quickly for all of those computer-embedded systems that we continue to develop, deploy, operate, and sustain.
5.2.3 Despite the gap, the computer is a powerful instrument. It might even be because of the gap that computers are so useful. Whatever the case, it strikes me that the nature of the gap and how we recognize it in the development of software can be of critical importance in understanding what falls to us in making computer systems increasingly useful in our world.
There are nine key ideas that I have attempted to illustrate and dramatize here:
5.3.1 Computation is accomplished by manipulations that have no fixed connection with the world in which the computation is useful and can be applied. It appears that what makes computation rigorous, repeatable, automatic and reliable is that it is stripped away from the world in this way.
5.3.2 The fundamental way that computers are directed is by specifying what they are to do. This involves operations on coded data elements by following coded instructions.
5.3.3 Any resemblance of the computation to what it is being used for is at best an unlikely coincidence.
5.3.4 Computations are choreographed such that they might coincide with our activities and purposes. To understand how that is accomplished, we need to look beyond the computational procedure to what the computation is for and how that connection is achieved and sustained. That is not to be found in the computation itself.
5.3.5 Computational procedures are generally imperfect and over-simplified when taken as embodiments of theories about the world. We are the ones who must decide what is close enough and, when that is insufficient, what the simplest improvement is.
5.3.6 One of the most difficult problems in computing is accommodating failures, discrepancies and other breakdowns which the programmer cannot possibly have anticipated with an adequate and automatic contingency procedure. As we see in the simple case of managing a checking account, it is generally the case that there are always facts not in evidence and without which a proper course of action cannot be automatically chosen.
5.3.7 Human beings are terrible at formulating and then following rigorous procedures.
5.3.8 Computers have no innate capacity to experiment, respond to the unforeseen, adapt to changing circumstances, and to resolve dilemmas by trial-and-error behavior. These are definitely not anything that computers know.
5.3.9 Whatever computes know, it is nothing about the external world.
What computers know is insufficient to account for how valuable and useful computers are. We need to look beyond to understand how what the computer is instructed to do is bridged to useful human purposes. Then we can appreciate how that arrangement is arrived at and who are engaged in its trustworthy accomplishment. The following sections provide a brief sketch of further topics to be explored.
6.1.1 The next topic to address is the working of computation. We don't intend any detailed examination of how computers and computation work. The focus is on what works about computation as an instrument of real-world activity. That will be technical enough.
6.1.2 Models capture the working of computational procedures. Diagrammatic models will help us envision the levels of abstraction in which computation subsists and the distinct levels of abstraction in which our use of computation is situated. The models help us recognize the bridge between computations and the external-world setting in which the computations are instrumental. This is an unfamiliar activity and we'll take our time building up the model brick by brick.
6.1.3 Programs as Text, Programs as Procedure. An important feature of digital computer programs is how programs are both digital artifacts and expressions of procedures that are followed by the computer. The relationship of description and behavior is an essential feature of the models.
6.2.1 How do programmers know what to program? The model will reveal that there is a region, not under control of the computation, in which magic must happen. The programmer is responsible for achieving what the program is for while relying on computation procedures and a machine that have no connection with that purpose.
6.2.2 Programmers invent programs. When we have revealing models for the working of computation, it will be evident how much programming and the activity of software design and engineering is a process of invention.
6.2.3 Tricking the computer into being useful. The challenge to the programmer is to contrive a representation of data and a procedure for its manipulation that is accomplished entirely by computational processes that have no inherent relationship to what the computation is for. The description of that relationship is accomplished in the world. It is not sensible to the computer. It can be carried in the computer system, but it is not known to the computer.
6.2.4 The challenge is preserving what's essential. The computer software and the representation of data to be processed is developed to match the capabilities of the computer system. There are many ways to do this, and there are incidental details that have to be introduced to have it work. No matter what choices are made as part of inventing a computation that works, the essential conditions of the purpose for the program must be preserved. That is the programmer's responsibility.
6.2.5 The programmer is not the expert. It is rare for the computer programmer and other members of a software-development team to be the experts in the subject matter that their software will serve. In addition, because of their intimate relationship with computers, programmers are usually not able to place themselves in the shoes of those who are involved with the subject matter and who need to interact with the software from the perspective of their expertise without having to ever know what the programmers and information technology personnel know.
6.3.1 Meshing Software to Requirements. To have the developed software satisfy the essential requirements for use in the conduct of some enterprise, the developers, including the programmers, must engage with others to establish precisely what essential qualities and function must be achieved and sustained. These domain experts and subject-matter participants will have to negotiate an agreement on the essential and the relevant concepts that is understandable to information technologists and to those who operate in the area to be served.
6.3.2 Meshing Business and Software-System Lifecycles. The development and delivery cycles for software will intercept ongoing organization activities. The organizational activities will be changing over time, dictated by circumstances unrelated to changes of the supporting computer systems and their software. The synchronization of software changes, equipment and computing infrastructure changes, and the ever-changing activities of the enterprise must be orchestrated in a complex meshing of requirements, practices, and computer-system enhancements. Adjustment to system outages, business interruptions, and revealed defects must be accomplished with alacrity.
6.3.3 There's No Simple Matter of Programming. Looked at from this perspective, there is nothing simple about introducing software and computer-aided procedures into the activities of an on-going enterprise. There are approaches that we use to segregate and simplify the continuing development of software elements. An important feature of successful approaches is how the essential is preserved and conceptual integrity and operational reliability of the computer-aided systems is maintained. The programmer may not be directly engaged at this level, but is this level where the validity of requirements and their completeness is determined.
6.4.1 The delivery of trustworthy components into open systems, the kind that support enterprise-situated computing, is the focus of TROSTing. Although the experimental developments being offered address small, targeted situations, an understanding of the levels from what computers know to where open-system components are integrated and used is important.
6.4.2 Trustworthiness in the relationship among producers and adopters of open-system components happens in how the components blend successfully into the purposes and activities of enterprise.
6.4.3 To understand where and how trustworthy-confirming care is reflected in the delivery and support of software, we must comprehend its lifecycle in development and in use. We reconstruct the layers of computation from the foundation of what computers know so that we can identify all of the essential places where demonstration and maintenance of trustworthiness is required.
6.4.4 We also seek separations of concerns that allows the essentials of trustworthiness to be localized and addressed at appropriate levels in this portrayal.
- Denning, Peter J. (2002)
- Career Redux. The Profession of IT, column, Comm. ACM 45, 9 (September), 21-26. Available at <http://doi.acm.org/10.1145/567498.567516>. Also at <http://cs.gmu.edu/cne/pjd/PUBS/CACMcols/>.
- Devlin, Keith (2005).
- The Math Instinct: Why You're a Mathematical Genius (along with Lobsters, Birds, Cats, and Dogs). Thunder's Mouth Press, New York. ISBN 1-56025-672-9.
- Gladwell, Malcolm (2005).
- Blink: The Power of Thinking Without Thinking. Little, Brown and Company, New York. ISBN 0-316-17232-4.
- Winegrad, Dilys., Akera, Atsushi (1996).
- A Short History of the Second American Revolution. Almanac 42, 18 (Tuesday, January 30, 1996), University of Pennsylvania, Philadelphia. Updated version available at <http://www.upenn.edu/almanac/v42/n18/eniac.html> accessed 2005-11-10.
The first commercially-shipped modern digital computer is reported to be the ERA 1103, delivered in 1951. A Univac 1103A model and an IBM 701 were still in operation at the Boeing Company, Seattle, when I was having my first experience with computers there in Spring, 1958. I never worked on the 1103A, but I was involved in a 1961 project to provide high-speed printing of the magnetic-tape output of its programs using a newer Univac computer model that came with a 600 line-per-minute printer.
- Hamilton, Dennis E. (2006)
- What Computers Know: But What's The Use. Web page version 0.80, Information Note i051002, TROSTing.org, 2006 September 4. Available at <http://TROSTing.org/info/2005/10/i051002f.htm>.
|
created 2005-10-12-05:24 -0700 (pdt) by
orcmid |
You are navigating