1990_能量转换效率达10.2%的非晶硅单结太阳能电池

合集下载

1. Mobile Application Platform

ARM Processor
Family Architecture Version Core ARM7TDMI ARM926EJ-S Feature 3-stage pipeline, Thumb Thumb, Jazelle DBX, Enhanced DSP instructions Application GBA, NDS, iPod, LEGO NXT Wii Graphics Chip, Sony Ericson Mobile phones ARM7TDMI ARMv4T ARM9E ARMv5TEJ
Tech Spec : GPS NEMA 0183 Sample String:
$GPGGA,092204.999,4250.5589,S,14718.5084,E,1,04,24.4,19.7,M ,,,,0000*1F Stands for:
UTC Time: 09:22:04 Latitude: 4250.5589 S Longitude: 14718.5084 E
Cortex
ARMv7-A
Cortex-A8
Hardware Platform--Cellular
Famous Manufacturer
Infineon Qualcomm
Famous Terms
Flash Radio Unlock (not Jailbreak)
Hayes AT Command
Radio Interface Layer
AT Command (cont.)
Different manufacturer’s implementation may vary
Development Tips:

Probabilistic model checking of an anonymity system

Probabilistic Model Checking ofan Anonymity SystemVitaly ShmatikovSRI International333Ravenswood AvenueMenlo Park,CA94025U.S.A.shmat@AbstractWe use the probabilistic model checker PRISM to analyze the Crowds system for anonymous Web browsing.This case study demonstrates howprobabilistic model checking techniques can be used to formally analyze se-curity properties of a peer-to-peer group communication system based onrandom message routing among members.The behavior of group mem-bers and the adversary is modeled as a discrete-time Markov chain,and thedesired security properties are expressed as PCTL formulas.The PRISMmodel checker is used to perform automated analysis of the system and ver-ify anonymity guarantees it provides.Our main result is a demonstration ofhow certain forms of probabilistic anonymity degrade when group size in-creases or random routing paths are rebuilt,assuming that the corrupt groupmembers are able to identify and/or correlate multiple routing paths originat-ing from the same sender.1IntroductionFormal analysis of security protocols is a well-establishedﬁeld.Model checking and theorem proving techniques[Low96,MMS97,Pau98,CJM00]have been ex-tensively used to analyze secrecy,authentication and other security properties ofprotocols and systems that employ cryptographic primitives such as public-key en-cryption,digital signatures,etc.Typically,the protocol is modeled at a highly ab-stract level and the underlying cryptographic primitives are treated as secure“black boxes”to simplify the model.This approach discovers attacks that would succeed even if all cryptographic functions were perfectly secure.Conventional formal analysis of security is mainly concerned with security against the so called Dolev-Yao attacks,following[DY83].A Dolev-Yao attacker is a non-deterministic process that has complete control over the communication net-work and can perform any combination of a given set of attacker operations,such as intercepting any message,splitting messages into parts,decrypting if it knows the correct decryption key,assembling fragments of messages into new messages and replaying them out of context,etc.Many proposed systems for anonymous communication aim to provide strong, non-probabilistic anonymity guarantees.This includes proxy-based approaches to anonymity such as the Anonymizer[Ano],which hide the sender’s identity for each message by forwarding all communication through a special server,and MIX-based anonymity systems[Cha81]that blend communication between dif-ferent senders and recipients,thus preventing a global eavesdropper from linking sender-recipient pairs.Non-probabilistic anonymity systems are amenable to for-mal analysis in the same non-deterministic Dolev-Yao model as used for veriﬁca-tion of secrecy and authentication protocols.Existing techniques for the formal analysis of anonymity in the non-deterministic model include traditional process formalisms such as CSP[SS96]and a special-purpose logic of knowledge[SS99].In this paper,we use probabilistic model checking to analyze anonymity prop-erties of a gossip-based system.Such systems fundamentally rely on probabilistic message routing to guarantee anonymity.The main representative of this class of anonymity systems is Crowds[RR98].Instead of protecting the user’s identity against a global eavesdropper,Crowds provides protection against collaborating local eavesdroppers.All communication is routed randomly through a group of peers,so that even if some of the group members collaborate and share collected lo-cal information with the adversary,the latter is not likely to distinguish true senders of the observed messages from randomly selected forwarders.Conventional formal analysis techniques that assume a non-deterministic at-tacker in full control of the communication channels are not applicable in this case. Security properties of gossip-based systems depend solely on the probabilistic be-havior of protocol participants,and can be formally expressed only in terms of relative probabilities of certain observations by the adversary.The system must be modeled as a probabilistic process in order to capture its properties faithfully.Using the analysis technique developed in this paper—namely,formalization of the system as a discrete-time Markov chain and probabilistic model checking of2this chain with PRISM—we uncovered two subtle properties of Crowds that causedegradation of the level of anonymity provided by the system to the users.First,if corrupt group members are able to detect that messages along different routingpaths originate from the same(unknown)sender,the probability of identifyingthat sender increases as the number of observed paths grows(the number of pathsmust grow with time since paths are rebuilt when crowd membership changes).Second,the conﬁdence of the corrupt members that they detected the correct senderincreases with the size of the group.Theﬁrstﬂaw was reported independently byMalkhi[Mal01]and Wright et al.[W ALS02],while the second,to the best ofour knowledge,was reported for theﬁrst time in the conference version of thispaper[Shm02].In contrast to the analysis by Wright et al.that relies on manualprobability calculations,we discovered both potential vulnerabilities of Crowds byautomated probabilistic model checking.Previous research on probabilistic formal models for security focused on(i)probabilistic characterization of non-interference[Gra92,SG95,VS98],and(ii)process formalisms that aim to faithfully model probabilistic properties of crypto-graphic primitives[LMMS99,Can00].This paper attempts to directly model andanalyze security properties based on discrete probabilities,as opposed to asymp-totic probabilities in the conventional cryptographic sense.Our analysis methodis applicable to other probabilistic anonymity systems such as Freenet[CSWH01]and onion routing[SGR97].Note that the potential vulnerabilities we discovered inthe formal model of Crowds may not manifest themselves in the implementationsof Crowds or other,similar systems that take measures to prevent corrupt routersfrom correlating multiple paths originating from the same sender.2Markov Chain Model CheckingWe model the probabilistic behavior of a peer-to-peer communication system as adiscrete-time Markov chain(DTMC),which is a standard approach in probabilisticveriﬁcation[LS82,HS84,Var85,HJ94].Formally,a Markov chain can be deﬁnedas consisting in aﬁnite set of states,the initial state,the transition relation such that,and a labeling functionfrom states to aﬁnite set of propositions.In our model,the states of the Markov chain will represent different stages ofrouting path construction.As usual,a state is deﬁned by the values of all systemvariables.For each state,the corresponding row of the transition matrix de-ﬁnes the probability distributions which govern the behavior of group members once the system reaches that state.32.1Overview of PCTLWe use the temporal probabilistic logic PCTL[HJ94]to formally specify properties of the system to be checked.PCTL can express properties of the form“under any scheduling of processes,the probability that event occurs is at least.”First,deﬁne state formulas inductively as follows:where atomic propositions are predicates over state variables.State formulas of the form are explained below.Deﬁne path formulas as follows:Unlike state formulas,which are simplyﬁrst-order propositions over a single state,path formulas represent properties of a chain of states(here path refers to a sequence of state space transitions rather than a routing path in the Crowds speci-ﬁcation).In particular,is true iff is true for every state in the chain;is true iff is true for all states in the chain until becomes true,and is true for all subsequent states;is true iff and there are no more than states before becomes true.For any state and path formula,is a state formula which is true iff state space paths starting from satisfy path formula with probability greater than.For the purposes of this paper,we will be interested in formulas of the form ,evaluated in the initial state.Here speciﬁes a system con-ﬁguration of interest,typically representing a particular observation by the adver-sary that satisﬁes the deﬁnition of a successful attack on the protocol.Property is a liveness property:it holds in iff will eventually hold with greater than probability.For instance,if is a state variable represent-ing the number of times one of the corrupt members received a message from the honest member no.,then holds in iff the prob-ability of corrupt members eventually observing member no.twice or more is greater than.Expressing properties of the system in PCTL allows us to reason formally about the probability of corrupt group members collecting enough evidence to success-fully attack anonymity.We use model checking techniques developed for veriﬁca-tion of discrete-time Markov chains to compute this probability automatically.42.2PRISM model checkerThe automated analyses described in this paper were performed using PRISM,aprobabilistic model checker developed by Kwiatkowska et al.[KNP01].The toolsupports both discrete-and continuous-time Markov chains,and Markov decisionprocesses.As described in section4,we model probabilistic peer-to-peer com-munication systems such as Crowds simply as discrete-time Markov chains,andformalize their properties in PCTL.The behavior of the system processes is speciﬁed using a simple module-basedlanguage inspired by Reactive Modules[AH96].State variables are declared in thestandard way.For example,the following declarationdeliver:bool init false;declares a boolean state variable deliver,initialized to false,while the followingdeclarationconst TotalRuns=4;...observe1:[0..TotalRuns]init0;declares a constant TotalRuns equal to,and then an integer array of size,indexed from to TotalRuns,with all elements initialized to.State transition rules are speciﬁed using guarded commands of the form[]<guard>-><command>;where<guard>is a predicate over system variables,and<command>is the tran-sition executed by the system if the guard condition evaluates to mandoften has the form<expression>...<expression>, which means that in the next state(i.e.,that obtained after the transition has beenexecuted),state variable is assigned the result of evaluating arithmetic expres-sion<expression>If the transition must be chosen probabilistically,the discrete probability dis-tribution is speciﬁed as[]<guard>-><prob1>:<command1>+...+<probN>:<commandN>;Transition represented by command is executed with probability prob,and prob.Security properties to be checked are stated as PCTL formulas (see section2.1).5Given a formal system speciﬁcation,PRISM constructs the Markov chain and determines the set of reachable states,using MTBDDs and BDDs,respectively. Model checking a PCTL formula reduces to a combination of reachability-based computation and solving a system of linear equations to determine the probability of satisfying the formula in each reachable state.The model checking algorithms employed by PRISM include[BdA95,BK98,Bai98].More details about the im-plementation and operation of PRISM can be found at http://www.cs.bham. /˜dxp/prism/and in[KNP01].Since PRISM only supports model checking ofﬁnite DTMC,in our case study of Crowds we only analyze anonymity properties ofﬁnite instances of the system. By changing parameters of the model,we demonstrate how anonymity properties evolve with changes in the system conﬁguration.Wright et al.[W ALS02]investi-gated related properties of the Crowds system in the general case,but they do not rely on tool support and their analyses are manual rather than automated.3Crowds Anonymity SystemProviding an anonymous communication service on the Internet is a challenging task.While conventional security mechanisms such as encryption can be used to protect the content of messages and transactions,eavesdroppers can still observe the IP addresses of communicating computers,timing and frequency of communi-cation,etc.A Web server can trace the source of the incoming connection,further compromising anonymity.The Crowds system was developed by Reiter and Ru-bin[RR98]for protecting users’anonymity on the Web.The main idea behind gossip-based approaches to anonymity such as Crowds is to hide each user’s communications by routing them randomly within a crowd of similar users.Even if an eavesdropper observes a message being sent by a particular user,it can never be sure whether the user is the actual sender,or is simply routing another user’s message.3.1Path setup protocolA crowd is a collection of users,each of whom is running a special process called a jondo which acts as the user’s proxy.Some of the jondos may be corrupt and/or controlled by the adversary.Corrupt jondos may collaborate and share their obser-vations in an attempt to compromise the honest users’anonymity.Note,however, that all observations by corrupt group members are local.Each corrupt member may observe messages sent to it,but not messages transmitted on the links be-tween honest jondos.An honest crowd member has no way of determining whether6a particular jondo is honest or corrupt.The parameters of the system are the total number of members,the number of corrupt members,and the forwarding probability which is explained below.To participate in communication,all jondos must register with a special server which maintains membership information.Therefore,every member of the crowd knows identities of all other members.As part of the join procedure,the members establish pairwise encryption keys which are used to encrypt pairwise communi-cation,so the contents of the messages are secret from an external eavesdropper.Anonymity guarantees provided by Crowds are based on the path setup pro-tocol,which is described in the rest of this section.The path setup protocol is executed each time one of the crowd members wants to establish an anonymous connection to a Web server.Once a routing path through the crowd is established, all subsequent communication between the member and the Web server is routed along it.We will call one run of the path setup protocol a session.When crowd membership changes,the existing paths must be scrapped and a new protocol ses-sion must be executed in order to create a new random routing path through the crowd to the destination.Therefore,we’ll use terms path reformulation and proto-col session interchangeably.When a user wants to establish a connection with a Web server,its browser sends a request to the jondo running locally on her computer(we will call this jondo the initiator).Each request contains information about the intended desti-nation.Since the objective of Crowds is to protect the sender’s identity,it is not problematic that a corrupt router can learn the recipient’s identity.The initiator starts the process of creating a random path to the destination as follows: The initiator selects a crowd member at random(possibly itself),and for-wards the request to it,encrypted by the corresponding pairwise key.We’ll call the selected member the forwarder.The forwarderﬂips a biased coin.With probability,it delivers the request directly to the destination.With probability,it selects a crowd member at random(possibly itself)as the next forwarder in the path,and forwards the request to it,re-encrypted with the appropriate pairwise key.The next forwarder then repeats this step.Each forwarder maintains an identiﬁer for the created path.If the same jondo appears in different positions on the same path,identiﬁers are different to avoid inﬁnite loops.Each subsequent message from the initiator to the destination is routed along this path,i.e.,the paths are static—once established,they are not altered often.This is necessary to hinder corrupt members from linking multiple7paths originating from the same initiator,and using this information to compromise the initiator’s anonymity as described in section3.2.3.3.2Anonymity properties of CrowdsThe Crowds paper[RR98]describes several degrees of anonymity that may be provided by a communication system.Without using anonymizing techniques, none of the following properties are guaranteed on the Web since browser requests contain information about their source and destination in the clear.Beyond suspicion Even if the adversary can see evidence of a sent message,the real sender appears to be no more likely to have originated it than any other potential sender in the system.Probable innocence The real sender appears no more likely to be the originator of the message than to not be the originator,i.e.,the probability that the adversary observes the real sender as the source of the message is less thanupper bound on the probability of detection.If the sender is observed by the adversary,she can then plausibly argue that she has been routing someone else’s messages.The Crowds paper focuses on providing anonymity against local,possibly co-operating eavesdroppers,who can share their observations of communication in which they are involved as forwarders,but cannot observe communication involv-ing only honest members.We also limit our analysis to this case.3.2.1Anonymity for a single routeIt is proved in[RR98]that,for any given routing path,the path initiator in a crowd of members with forwarding probability has probable innocence against collaborating crowd members if the following inequality holds:(1)More formally,let be the event that at least one of the corrupt crowd members is selected for the path,and be the event that the path initiator appears in8the path immediately before a corrupt crowd member(i.e.,the adversary observes the real sender as the source of the messages routed along the path).Condition 1guarantees thatproving that,given multiple linked paths,the initiator appears more often as a sus-pect than a random crowd member.The automated analysis described in section6.1 conﬁrms and quantiﬁes this result.(The technical results of[Shm02]on which this paper is based had been developed independently of[Mal01]and[W ALS02],be-fore the latter was published).In general,[Mal01]and[W ALS02]conjecture that there can be no reliable anonymity method for peer-to-peer communication if in order to start a new communication session,the initiator must originate theﬁrst connection before any processing of the session commences.This implies that anonymity is impossible in a gossip-based system with corrupt routers in the ab-sence of decoy trafﬁc.In section6.3,we show that,for any given number of observed paths,the adversary’s conﬁdence in its observations increases with the size of the crowd.This result contradicts the intuitive notion that bigger crowds provide better anonymity guarantees.It was discovered by automated analysis.4Formal Model of CrowdsIn this section,we describe our probabilistic formal model of the Crowds system. Since there is no non-determinism in the protocol speciﬁcation(see section3.1), the model is a simple discrete-time Markov chain as opposed to a Markov deci-sion process.In addition to modeling the behavior of the honest crowd members, we also formalize the adversary.The protocol does not aim to provide anonymity against global eavesdroppers.Therefore,it is sufﬁcient to model the adversary as a coalition of corrupt crowd members who only have access to local communication channels,i.e.,they can only make observations about a path if one of them is se-lected as a forwarder.By the same token,it is not necessary to model cryptographic functions,since corrupt members know the keys used to encrypt peer-to-peer links in which they are one of the endpoints,and have no access to links that involve only honest members.The modeling technique presented in this section is applicable with minor mod-iﬁcations to any probabilistic routing system.In each state of routing path construc-tion,the discrete probability distribution given by the protocol speciﬁcation is used directly to deﬁne the probabilistic transition rule for choosing the next forwarder on the path,if any.If the protocol prescribes an upper bound on the length of the path(e.g.,Freenet[CSWH01]),the bound can be introduced as a system parameter as described in section4.2.3,with the corresponding increase in the size of the state space but no conceptual problems.Probabilistic model checking can then be used to check the validity of PCTL formulas representing properties of the system.In the general case,forwarder selection may be governed by non-deterministic10runCount goodbad lastSeen observelaunchnewstartrundeliver recordLast badObserve4.2Model of honest members4.2.1InitiationPath construction is initiated as follows(syntax of PRISM is described in section 2.2):[]launch->runCount’=TotalRuns&new’=true&launch’=false;[]new&(runCount>0)->(runCount’=runCount-1)&new’=false&start’=true;[]start->lastSeen’=0&deliver’=false&run’=true&start’=false;4.2.2Forwarder selectionThe initiator(i.e.,theﬁrst crowd member on the path,the one whose identity must be protected)randomly chooses theﬁrst forwarder from among all group mem-bers.We assume that all group members have an equal probability of being chosen, but the technique can support any discrete probability distribution for choosing for-warders.Forwarder selection is a single step of the protocol,but we model it as two probabilistic state transitions.Theﬁrst determines whether the selected forwarder is honest or corrupt,the second determines the forwarder’s identity.The randomly selected forwarder is corrupt with probability badCbe next on the path.Any of the honest crowd members can be selected as the forwarder with equal probability.To illustrate,for a crowd with10honest members,the following transition models the second step of forwarder selection: []recordLast&CrowdSize=10->0.1:lastSeen’=0&run’=true&recordLast’=false+0.1:lastSeen’=1&run’=true&recordLast’=false+...0.1:lastSeen’=9&run’=true&recordLast’=false;According to the protocol,each honest crowd member must decide whether to continue building the path byﬂipping a biased coin.With probability,the forwarder selection transition is enabled again and path construction continues, and with probability the path is terminated at the current forwarder,and all requests arriving from the initiator along the path will be delivered directly to the recipient.[](good&!deliver&run)->//Continue path constructionPF:good’=false+//Terminate path constructionnotPF:deliver’=true;The speciﬁcation of the Crowds system imposes no upper bound on the length of the path.Moreover,the forwarders are not permitted to know their relative position on the path.Note,however,that the amount of information about the initiator that can be extracted by the adversary from any path,or anyﬁnite number of paths,isﬁnite(see sections4.3and4.5).In systems such as Freenet[CSWH01],requests have a hops-to-live counter to prevent inﬁnite paths,except with very small probability.To model this counter,we may introduce an additional state variable pIndex that keeps track of the length of the path constructed so far.The path construction transition is then coded as follows://Example with Hops-To-Live//(NOT CROWDS)////Forward with prob.PF,else deliver13[](good&!deliver&run&pIndex<MaxPath)->PF:good’=false&pIndex’=pIndex+1+notPF:deliver’=true;//Terminate if reached MaxPath,//but sometimes not//(to confuse adversary)[](good&!deliver&run&pIndex=MaxPath)->smallP:good’=false+largeP:deliver’=true;Introduction of pIndex obviously results in exponential state space explosion, decreasing the maximum system size for which model checking is feasible.4.2.4Transition matrix for honest membersTo summarize the state space of the discrete-time Markov chain representing cor-rect behavior of protocol participants(i.e.,the state space induced by the abovetransitions),let be the state in which links of the th routing path from the initiator have already been constructed,and assume that are the honestforwarders selected for the path.Let be the state in which path constructionhas terminated with as theﬁnal path,and let be an auxiliary state. Then,given the set of honest crowd members s.t.,the transi-tion matrix is such that,,(see section4.2.2),i.e.,the probability of selecting the adversary is equal to the cumulative probability of selecting some corrupt member.14This abstraction does not limit the class of attacks that can be discovered using the approach proposed in this paper.Any attack found in the model where indi-vidual corrupt members are kept separate will be found in the model where their capabilities are combined in a single worst-case adversary.The reason for this is that every observation made by one of the corrupt members in the model with separate corrupt members will be made by the adversary in the model where their capabilities are combined.The amount of information available to the worst-case adversary and,consequently,the inferences that can be made from it are at least as large as those available to any individual corrupt member or a subset thereof.In the adversary model of[RR98],each corrupt member can only observe its local network.Therefore,it only learns the identity of the crowd member imme-diately preceding it on the path.We model this by having the corrupt member read the value of the lastSeen variable,and record its observations.This cor-responds to reading the source IP address of the messages arriving along the path. For example,for a crowd of size10,the transition is as follows:[]lastSeen=0&badObserve->observe0’=observe0+1&deliver’=true&run’=true&badObserve’=false;...[]lastSeen=9&badObserve->observe9’=observe9+1&deliver’=true&run’=true&badObserve’=false;The counters observe are persistent,i.e.,they are not reset for each session of the path setup protocol.This allows the adversary to accumulate observations over several path reformulations.We assume that the adversary can detect when two paths originate from the same member whose identity is unknown(see sec-tion3.2.2).The adversary is only interested in learning the identity of theﬁrst crowd mem-ber in the path.Continuing path construction after one of the corrupt members has been selected as a forwarder does not provide the adversary with any new infor-mation.This is a very important property since it helps keep the model of the adversaryﬁnite.Even though there is no bound on the length of the path,at most one observation per path is useful to the adversary.To simplify the model,we as-sume that the path terminates as soon as it reaches a corrupt member(modeled by deliver’=true in the transition above).This is done to shorten the average path length without decreasing the power of the adversary.15Each forwarder is supposed toﬂip a biased coin to decide whether to terminate the path,but the coinﬂips are local to the forwarder and cannot be observed by other members.Therefore,honest members cannot detect without cooperation that corrupt members always terminate paths.In any case,corrupt members can make their observable behavior indistinguishable from that of the honest members by continuing the path with probability as described in section4.2.3,even though this yields no additional information to the adversary.4.4Multiple pathsThe discrete-time Markov chain deﬁned in sections4.2and4.3models construc-tion of a single path through the crowd.As explained in section3.2.2,paths have to be reformulated periodically.The decision to rebuild the path is typically made according to a pre-determined schedule,e.g.,hourly,daily,or once enough new members have asked to join the crowd.For the purposes of our analysis,we sim-ply assume that paths are reformulated someﬁnite number of times(determined by the system parameter=TotalRuns).We analyze anonymity properties provided by Crowds after successive path reformulations by considering the state space produced by successive execu-tions of the path construction protocol described in section4.2.As explained in section4.3,the adversary is permitted to combine its observations of some or all of the paths that have been constructed(the adversary only observes the paths for which some corrupt member was selected as one of the forwarders).The adversary may then use this information to infer the path initiator’s identity.Because for-warder selection is probabilistic,the adversary’s ability to collect enough informa-tion to successfully identify the initiator can only be characterized probabilistically, as explained in section5.4.5Finiteness of the adversary’s state spaceThe state space of the honest members deﬁned by the transition matrix of sec-tion4.2.4is inﬁnite since there is no a priori upper bound on the length of each path.Corrupt members,however,even if they collaborate,can make at most one observation per path,as explained in section4.3.As long as the number of path reformulations is bounded(see section4.4),only aﬁnite number of paths will be constructed and the adversary will be able to make only aﬁnite number of observa-tions.Therefore,the adversary only needsﬁnite memory and the adversary’s state space isﬁnite.In general,anonymity is violated if the adversary has a high probability of making a certain observation(see section5).Toﬁnd out whether Crowds satisﬁes16。

chapter1-1 Introduction

2014-6-2 Computer Networks -1-Part 1 9
Differences between computer networks and distributed system
• Key distinction is that in a distributed system, the existence of multiple autonomous computers is transparent to users. It looks like a virtual machine with uniprocessor. • With a network, users must explicitly log on to one machine, explicitly submit jobs remotely, explicitly move files around and handle network personally.
• Early 1990’s: ARPAnet decommissioned • 1991: NSF lifts restrictions on commercial use of NSFnet (decommissioned, 1995) • early 1990s: Web – hypertext [Bush 1945, Nelson 1960’s] – HTML, HTTP: Berners-Lee – 1994: Mosaic, later Netscape – late 1990’s: commercialization of the Web
2014-6-2
Computer Networks -1-Part 1
12
1.1 Use of Computer Networks

公共政策终结理论研究综述

公共政策终结理论研究综述摘要：政策终结是政策过程的一个环节，是政策更新、政策发展、政策进步的新起点。

政策终结是20世纪70年代末西方公共政策研究领域的热点问题。

公共政策终结是公共政策过程的一个重要阶段，对政策终结的研究不仅有利于促进政策资源的合理配置，更有利于提高政府的政策绩效。

本文简要回顾了公共政策终结研究的缘起、内涵、类型、方式、影响因素、促成策略以及发展方向等内容，希望能够对公共政策终结理论有一个比较全面深入的了解。

关键词：公共政策，政策终结，理论研究行政有着古老的历史，但是，在一个相当长的历史时期中，行政所赖以治理社会的工具主要是行政行为。

即使是公共行政出现之后，在一个较长的时期内也还主要是借助于行政行为去开展社会治理，公共行政与传统行政的区别在于，找到了行政行为一致性的制度模式，确立了行政行为的（官僚制）组织基础。

到了公共行政的成熟阶段，公共政策作为社会治理的一个重要途径引起了人们的重视。

与传统社会中主要通过行政行为进行社会治理相比，公共政策在解决社会问题、降低社会成本、调节社会运行等方面都显示出了巨大的优势。

但是，如果一项政策已经失去了存在的价值而又继续被保留下来了，就可能会发挥极其消极的作用。

因此，及时、有效地终结一项或一系列错误的或没有价值的公共政策，有利于促进公共政策的更新与发展、推进公共政策的周期性循环、缓解和解决公共政策的矛盾和冲突，从而实现优化和调整公共政策系统的目标。

这就引发了学界对政策终结理论的思考和探索。

自政策科学在美国诞生以来，公共政策过程理论都是学术界所关注的热点。

1956年，拉斯韦尔在《决策过程》一书中提出了决策过程的七个阶段，即情报、建议、规定、行使、运用、评价和终止。

此种观点奠定了政策过程阶段论在公共政策研究中的主导地位。

一时间，对于政策过程各个阶段的研究成为政策学界的主要课题。

然而，相对于其他几个阶段的研究来说，政策终结的研究一直显得非常滞后。

这种情况直到20世纪70年代末80年代初，才有了明显的改善。

A File is Not a File

A File is Not a File:Understanding the I/O Behaviorof Apple Desktop ApplicationsTyler Harter,Chris Dragga,Michael Vaughn,Andrea C.Arpaci-Dusseau,Remzi H.Arpaci-DusseauDepartment of Computer SciencesUniversity of Wisconsin,Madison{harter,dragga,vaughn,dusseau,remzi}@ABSTRACTWe analyze the I/O behavior of iBench,a new collection of produc-tivity and multimedia application workloads.Our analysis reveals a number of differences between iBench and typicalﬁle-system workload studies,including the complex organization of modern ﬁles,the lack of pure sequential access,the inﬂuence of underlying frameworks on I/O patterns,the widespread use ofﬁle synchro-nization and atomic operations,and the prevalence of threads.Our results have strong ramiﬁcations for the design of next generation local and cloud-based storage systems.1.INTRODUCTIONThe design and implementation ofﬁle and storage systems has long been at the forefront of computer systems research.Inno-vations such as namespace-based locality[21],crash consistency via journaling[15,29]and copy-on-write[7,34],checksums and redundancy for reliability[5,7,26,30],scalable on-disk struc-tures[37],distributedﬁle systems[16,35],and scalable cluster-based storage systems[9,14,18]have greatly inﬂuenced how data is managed and stored within modern computer systems.Much of this work inﬁle systems over the past three decades has been shaped by measurement:the deep and detailed analysis of workloads[4,10,11,16,19,25,33,36,39].One excellent example is found in work on the Andrew File System[16];de-tailed analysis of an early AFS prototype led to the next-generation protocol,including the key innovation of callbacks.Measurement helps us understand the systems of today so we can build improved systems for tomorrow.Whereas most studies ofﬁle systems focus on the corporate or academic intranet,mostﬁle-system users work in the more mun-dane environment of the home,accessing data via desktop PCs, laptops,and compact devices such as tablet computers and mo-bile phones.Despite the large number of previous studies,little is known about home-user applications and their I/O patterns. Home-user applications are important today,and their impor-tance will increase as more users store data not only on local de-vices but also in the ers expect to run similar applications across desktops,laptops,and phones;therefore,the behavior of these applications will affect virtually every system with which a Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for proﬁt or commercial advantage and that copies bear this notice and the full citation on theﬁrst page.To copy otherwise,to republish,to post on servers or to redistribute to lists,requires prior speciﬁc permission and/or a fee.Copyright2011ACM978-1-59593-591-5/07/0010...$er interacts.I/O behavior is especially important to understand since it greatly impacts how users perceive overall system latency and application performance[12].While a study of how users typically exercise these applications would be interesting,theﬁrst step is to perform a detailed study of I/O behavior under typical but controlled workload tasks.This style of application study,common in theﬁeld of computer archi-tecture[40],is different from the workload study found in systems research,and can yield deeper insight into how the applications are constructed and howﬁle and storage systems need to be designed in response.Home-user applications are fundamentally large and complex, containing millions of lines of code[20].In contrast,traditional U NIX-based applications are designed to be simple,to perform one task well,and to be strung together to perform more complex tasks[32].This modular approach of U NIX applications has not prevailed[17]:modern applications are standalone monoliths,pro-viding a rich and continuously evolving set of features to demand-ing users.Thus,it is beneﬁcial to study each application individu-ally to ascertain its behavior.In this paper,we present theﬁrst in-depth analysis of the I/O behavior of modern home-user applications;we focus on produc-tivity applications(for word processing,spreadsheet manipulation, and presentation creation)and multimedia software(for digital mu-sic,movie editing,and photo management).Our analysis centers on two Apple software suites:iWork,consisting of Pages,Num-bers,and Keynote;and iLife,which contains iPhoto,iTunes,and iMovie.As Apple’s market share grows[38],these applications form the core of an increasingly popular set of workloads;as de-vice convergence continues,similar forms of these applications are likely to access userﬁles from both stationary machines and mov-ing cellular devices.We call our collection the iBench task suite. To investigate the I/O behavior of the iBench suite,we build an instrumentation framework on top of the powerful DTrace tracing system found inside Mac OS X[8].DTrace allows us not only to monitor system calls made by each traced application,but also to examine stack traces,in-kernel functions such as page-ins and page-outs,and other details required to ensure accuracy and com-pleteness.We also develop an application harness based on Apple-Script[3]to drive each application in the repeatable and automated fashion that is key to any study of GUI-based applications[12]. Our careful study of the tasks in the iBench suite has enabled us to make a number of interesting observations about how applica-tions access and manipulate stored data.In addition to conﬁrming standard pastﬁndings(e.g.,mostﬁles are small;most bytes ac-cessed are from largeﬁles[4]),weﬁnd the following new results. Aﬁle is not aﬁle.Modern applications manage large databases of information organized into complex directory trees.Even simple word-processing documents,which appear to users as a“ﬁle”,arein actuality smallﬁle systems containing many sub-ﬁles(e.g.,a Microsoft.docﬁle is actually a FATﬁle system containing pieces of the document).File systems should be cognizant of such hidden structure in order to lay out and access data in these complexﬁles more effectively.Sequential access is not sequential.Building on the trend no-ticed by V ogels for Windows NT[39],we observe that even for streaming media workloads,“pure”sequential access is increas-ingly rare.Sinceﬁle formats often include metadata in headers, applications often read and re-read theﬁrst portion of aﬁle before streaming through its contents.Prefetching and other optimizations might beneﬁt from a deeper knowledge of theseﬁle formats. Auxiliaryﬁles dominate.Applications help users create,mod-ify,and organize content,but userﬁles represent a small fraction of theﬁles touched by modern applications.Mostﬁles are helper ﬁles that applications use to provide a rich graphical experience, support multiple languages,and record history and other metadata. File-system placement strategies might reduce seeks by grouping the hundreds of helperﬁles used by an individual application. Writes are often forced.As the importance of home data in-creases(e.g.,family photos),applications are less willing to simply write data and hope it is eventuallyﬂushed to disk.Weﬁnd that most written data is explicitly forced to disk by the application;for example,iPhoto calls fsync thousands of times in even the sim-plest of tasks.Forﬁle systems and storage,the days of delayed writes[22]may be over;new ideas are needed to support applica-tions that desire durability.Renaming is popular.Home-user applications commonly use atomic operations,in particular rename,to present a consistent view ofﬁles to users.Forﬁle systems,this may mean that trans-actional capabilities[23]are needed.It may also necessitate a re-thinking of traditional means ofﬁle locality;for example,placing aﬁle on disk based on its parent directory[21]does not work as expected when theﬁle isﬁrst created in a temporary location and then renamed.Multiple threads perform I/O.Virtually all of the applications we study issue I/O requests from a number of threads;a few ap-plications launch I/Os from hundreds of threads.Part of this us-age stems from the GUI-based nature of these applications;it is well known that threads are required to perform long-latency oper-ations in the background to keep the GUI responsive[24].Thus,ﬁle and storage systems should be thread-aware so they can better allocate bandwidth.Frameworks inﬂuence I/O.Modern applications are often de-veloped in sophisticated IDEs and leverage powerful libraries,such as Cocoa and Carbon.Whereas UNIX-style applications often di-rectly invoke system calls to read and writeﬁles,modern libraries put more code between applications and the underlyingﬁle system; for example,including"cocoa.h"in a Mac application imports 112,047lines of code from689differentﬁles[28].Thus,the be-havior of the framework,and not just the application,determines I/O patterns.Weﬁnd that the default behavior of some Cocoa APIs induces extra I/O and possibly unnecessary(and costly)synchro-nizations to disk.In addition,use of different libraries for similar tasks within an application can lead to inconsistent behavior be-tween those tasks.Future storage design should take these libraries and frameworks into account.This paper contains four major contributions.First,we describe a general tracing framework for creating benchmarks based on in-teractive tasks that home users may perform(e.g.,importing songs, exporting video clips,saving documents).Second,we deconstruct the I/O behavior of the tasks in iBench;we quantify the I/O behav-ior of each task in numerous ways,including the types ofﬁles ac-cessed(e.g.,counts and sizes),the access patterns(e.g.,read/write, sequentiality,and preallocation),transactional properties(e.g.,dura-bility and atomicity),and threading.Third,we describe how these qualitative changes in I/O behavior may impact the design of future systems.Finally,we present the34traces from the iBench task suite;by making these traces publicly available and easy to use,we hope to improve the design,implementation,and evaluation of the next generation of local and cloud storage systems:/adsl/Traces/ibench The remainder of this paper is organized as follows.We begin by presenting a detailed timeline of the I/O operations performed by one task in the iBench suite;this motivates the need for a systematic study of home-user applications.We next describe our methodol-ogy for creating the iBench task suite.We then spend the majority of the paper quantitatively analyzing the I/O characteristics of the full iBench suite.Finally,we summarize the implications of our ﬁndings onﬁle-system design.2.CASE STUDYThe I/O characteristics of modern home-user applications are distinct from those of U NIX applications studied in the past.To motivate the need for a new study,we investigate the complex I/O behavior of a single representative task.Speciﬁcally,we report in detail the I/O performed over time by the Pages(4.0.3)application, a word processor,running on Mac OS X Snow Leopard(10.6.2)as it creates a blank document,inserts15JPEG images each of size 2.5MB,and saves the document as a Microsoft.docﬁle.Figure1shows the I/O this task performs(see the caption for a description of the symbols used).The top portion of theﬁgure il-lustrates the accesses performed over the full lifetime of the task:at a high level,it shows that more than385ﬁles spanning six different categories are accessed by eleven different threads,with many in-tervening calls to fsync and rename.The bottom portion of the ﬁgure magniﬁes a short time interval,showing the reads and writes performed by a single thread accessing the primary.doc productiv-ityﬁle.From this one experiment,we illustrate eachﬁnding de-scribed in the introduction.Weﬁrst focus on the single access that saves the user’s document(bottom),and then consider the broader context surrounding thisﬁle save,where we observe aﬂurry of ac-cesses to hundreds of helperﬁles(top).Aﬁle is not aﬁle.Focusing on the magniﬁed timeline of reads and writes to the productivity.docﬁle,we see that theﬁle format comprises more than just a simpleﬁle.Microsoft.docﬁles are based on the FATﬁle system and allow bundling of multipleﬁles in the single.docﬁle.This.docﬁle contains a directory(Root),three streams for large data(WordDocument,Data,and1Table),and a stream for small data(Ministream).Space is allocated in theﬁle with three sections:aﬁle allocation table(FAT),a double-indirect FAT(DIF)region,and a ministream allocation region(Mini). Sequential access is not sequential.The complex FAT-based ﬁle format causes random access patterns in several ways:ﬁrst,the header is updated at the beginning and end of the magniﬁed access; second,data from individual streams is fragmented throughout the ﬁle;and third,the1Table stream is updated before and after each image is appended to the WordDocument stream.Auxiliaryﬁles dominate.Although saving the single.doc we have been considering is the sole purpose of this task,we now turn our attention to the top timeline and see that385differentﬁles are accessed.There are several reasons for this multitude ofﬁles. First,Pages provides a rich graphical experience involving many images and other forms of multimedia;together with the15in-serted JPEGs,this requires118multimediaﬁles.Second,usersF i l e sSequential RunsF i l e O f f s e t (K B )Figure 1:Pages Saving A Word Document.The top graph shows the 75-second timeline of the entire run,while the bottom graph is a magniﬁed view of seconds 54to 58.In the top graph,annotations on the left categorize ﬁles by type and indicate ﬁle count and amount of I/O;annotations on the right show threads.Black bars are ﬁle accesses (reads and writes),with thickness logarithmically proportional to bytes of I/O./is an fsync ;\is a rename ;X is both.In the bottom graph,individual reads and writes to the .doc ﬁle are shown.Vertical bar position and bar length represent the offset within the ﬁle and number of bytes touched.Thick white bars are reads;thin gray bars are writes.Repeated runs are marked with the number of repetitions.Annotations on the right indicate the name of each ﬁle section.want to use Pages in their native language,so application text is not hard-coded into the executable but is instead stored in25different .stringsﬁles.Third,to save user preferences and other metadata, Pages uses a SQLite database(2ﬁles)and a number of key-value stores(218.plistﬁles).Writes are often forced;renaming is popular.Pages uses both of these actions to enforce basic transactional guarantees.It uses fsync toﬂush write data to disk,making it durable;it uses rename to atomically replace oldﬁles with newﬁles so that aﬁle never contains inconsistent data.The timeline shows these invo-cations numerous times.First,Pages regularly uses fsync and rename when updating the key-value store of a.plistﬁle.Second, fsync is used on the SQLite database.Third,for each of the15 image insertions,Pages calls fsync on aﬁle named“tempData”(classiﬁed as“other”)to update its automatic backup.Multiple threads perform I/O.Pages is a multi-threaded appli-cation and issues I/O requests from many different threads during the ing multiple threads for I/O allows Pages to avoid blocking while I/O requests are outstanding.Examining the I/O behavior across threads,we see that Thread1performs the most signiﬁcant portion of I/O,but ten other threads are also involved.In most cases,a single thread exclusively accesses aﬁle,but it is not uncommon for multiple threads to share aﬁle.Frameworks inﬂuence I/O.Pages was developed in a rich pro-gramming environment where frameworks such as Cocoa or Car-bon are used for I/O;these libraries impact I/O patterns in ways the developer might not expect.For example,although the appli-cation developers did not bother to use fsync or rename when saving the user’s work in the.docﬁle,the Cocoa library regularly uses these calls to atomically and durably update relatively unim-portant metadata,such as“recently opened”lists stored in.plist ﬁles.As another example,when Pages tries to read data in512-byte chunks from the.doc,each read goes through the STDIO library, which only reads in4KB chunks.Thus,when Pages attempts to read one chunk from the1Table stream,seven unrequested chunks from the WordDocument stream are also incidentally read(off-set12039KB).In other cases,regions of the.docﬁle are repeat-edly accessed unnecessarily.For example,around the3KB off-set,read/write pairs occur dozens of times.Pages uses a library to write2-byte words;each time a word is written,the library reads, updates,and writes back an entire512-byte chunk.Finally,we see evidence of redundancy between libraries:even though Pages has a backing SQLite database for some of its properties,it also uses.plistﬁles,which function across Apple applications as generic property stores.This one detailed experiment has shed light on a number of in-teresting I/O behaviors that indicate that home-user applications are indeed different than traditional workloads.A new workload suite is needed that more accurately reﬂects these applications.3.IBENCH TASK SUITEOur goal in constructing the iBench task suite is two-fold.First, we would like iBench to be representative of the tasks performed by home users.For this reason,iBench contains popular applications from the iLife and iWork suites for entertainment and productivity. Second,we would like iBench to be relatively simple for others to use forﬁle and storage system analysis.For this reason,we auto-mate the interactions of a home user and collect the resulting traces of I/O system calls.The traces are available online at this site: /adsl/Traces/ibench.We now describe in more detail how we met these two goals.3.1RepresentativeTo capture the I/O behavior of home users,iBench models the ac-tions of a“reasonable”user interacting with iPhoto,iTunes,iMovie, Pages,Numbers,and Keynote.Since the research community does not yet have data on the exact distribution of tasks that home users perform,iBench contains tasks that we believe are common and usesﬁles with sizes that can be justiﬁed for a reasonable user. iBench contains34different tasks,each representing a home user performing one distinct operation.If desired,these tasks could be combined to create more complex workﬂows and I/O workloads. The six applications and corresponding tasks are as follows.iLife iPhoto8.1.1(419):digital photo album and photo manip-ulation software.iPhoto stores photos in a library that contains the data for the photos(which can be in a variety of formats,including JPG,TIFF,and PNG),a directory of modiﬁedﬁles,a directory of scaled down images,and twoﬁles of thumbnail images.The library stores metadata in a SQLite database.iBench contains six tasks ex-ercising user actions typical for iPhoto:starting the application and importing,duplicating,editing,viewing,and deleting photos in the library.These tasks modify both the imageﬁles and the underlying database.Each of the iPhoto tasks operates on4002.5MB photos, representing a user who has imported12megapixel photos(2.5MB each)from a full1GBﬂash card on his or her camera.iLife iTunes9.0.3(15):a media player capable of both audio and video playback.iTunes organizes itsﬁles in a private library and supports most common music formats(e.g.,MP3,AIFF,W A VE, AAC,and MPEG-4).iTunes does not employ a database,keeping media metadata and playlists in both a binary and an XMLﬁle. iBench containsﬁve tasks for iTunes:starting iTunes,importing and playing an album of MP3songs,and importing and playing an MPEG-4movie.Importing requires copyingﬁles into the library directory and,for music,analyzing each songﬁle for gapless play-back.The music tasks operate over an album(or playlist)of ten songs while the movie tasks use a single3-minute movie.iLife iMovie8.0.5(820):video editing software.iMovie stores its data in a library that contains directories for raw footage and projects,andﬁles containing video footage thumbnails.iMovie supports both MPEG-4and Quicktimeﬁles.iBench contains four tasks for iMovie:starting iMovie,importing an MPEG-4movie, adding a clip from this movie into a project,and exporting a project to MPEG-4.The tasks all use a3-minute movie because this is a typical length found from home users on video-sharing websites. iWork Pages4.0.3(766):a word processor.Pages uses a ZIP-basedﬁle format and can export to DOC,PDF,RTF,and basic text. iBench includes eight tasks for Pages:starting up,creating and saving,opening,and exporting documents with and without images and with different formats.The tasks use15page documents. iWork Numbers2.0.3(332):a spreadsheet application.Num-bers organizes itsﬁles with a ZIP-based format and exports to XLS and PDF.The four iBench tasks for Numbers include starting Num-bers,generating a spreadsheet and saving it,opening the spread-sheet,and exporting that spreadsheet to XLS.To model a possible home user working on a budget,the tasks utilize aﬁve page spread-sheet with one column graph per sheet.iWork Keynote5.0.3(791):a presentation and slideshow appli-cation.Keynote saves to a.key ZIP-based format and exports to Microsoft’s PPT format.The seven iBench tasks for Keynote in-clude starting Keynote,creating slides with and without images, opening and playing presentations,and exporting to PPT.Each Keynote task uses a20-slide presentation.Accesses I/O MB Name DescriptionFiles (MB)Accesses (MB)RD%WR%/CPU Sec/CPU Seci L i f e i P h o t oStart Open iPhoto with library of 400photos 779(336.7)828(25.4)78.821.2151.1 4.6Imp Import 400photos into empty library 5900(1966.9)8709(3940.3)74.425.626.712.1Dup Duplicate 400photos from library2928(1963.9)5736(2076.2)52.447.6237.986.1Edit Sequentially edit 400photos from library 12119(4646.7)18927(12182.9)69.830.219.612.6Del Sequentially delete 400photos;empty trash 15246(23.0)15247(25.0)21.878.2280.90.5View Sequentially view 400photos 2929(1006.4)3347(1005.0)98.1 1.924.17.2i T u n e s Start Open iTunes with 10song album 143(184.4)195(9.3)54.745.372.4 3.4ImpS Import 10song album to library 68(204.9)139(264.5)66.333.775.2143.1ImpM Import 3minute movie to library 41(67.4)57(42.9)48.052.0152.4114.6PlayS Play album of 10songs 61(103.6)80(90.9)96.9 3.10.40.5PlayM Play 3minute movie56(77.9)69(32.0)92.37.7 2.2 1.0i M o v i e Start Open iMovie with 3minute clip in project 433(223.3)786(29.4)99.90.1134.8 5.0Imp Import 3minute .m4v (20MB)to “Events”184(440.1)383(122.3)55.644.429.39.3Add Paste 3minute clip from “Events”to project 210(58.3)547(2.2)47.852.2357.8 1.4Exp Export 3minute video clip 70(157.9)546(229.9)55.144.9 2.3 1.0i W o r kP a g e s Start Open Pages218(183.7)228(2.3)99.90.197.7 1.0New Create 15text page document;save as .pages 135(1.6)157(1.0)73.326.750.80.3NewP Create 15JPG document;save as .pages 408(112.0)997(180.9)60.739.354.69.9Open Open 15text page document 103(0.8)109(0.6)99.50.557.60.3PDF Export 15page document as .pdf 107(1.5)115(0.9)91.09.041.30.3PDFP Export 15JPG document as .pdf 404(77.4)965(110.9)67.432.649.7 5.7DOC Export 15page document as .doc 112(1.0)121(1.0)87.912.144.40.4DOCP Export 15JPG document as .doc 385(111.3)952(183.8)61.138.946.38.9N u m b e r s Start Open Numbers283(179.9)360(2.6)99.60.4115.50.8New Save 5sheets/column graphs as .numbers 269(4.9)313(2.8)90.79.39.60.1Open Open 5sheet spreadsheet119(1.3)137(1.3)99.80.248.70.5XLS Export 5sheets/column graphs as .xls 236(4.6)272(2.7)94.9 5.18.50.1K e y n o t e Start Open Keynote517(183.0)681(1.1)99.80.2229.80.4New Create 20text slides;save as .key 637(12.1)863(5.4)92.47.6129.10.8NewP Create 20JPG slides;save as .key654(92.9)901(103.3)66.833.270.88.1Play Open and play presentation of 20text slides 318(11.5)385(4.9)99.80.295.0 1.2PlayP Open and play presentation of 20JPG slides 321(45.4)388(55.7)69.630.472.410.4PPT Export 20text slides as .ppt 685(12.8)918(10.1)78.821.2115.2 1.3PPTP Export 20JPG slides as .ppt 723(110.6)996(124.6)57.642.461.07.6Table 1:34Tasks of the iBench Suite.The table summarizes the 34tasks of iBench,specifying the application,a short name for the task,and a longer description of the actions modeled.The I/O is characterized according to the number of ﬁles read or written,the sum of the maximum sizes of all accessed ﬁles,the number of ﬁle accesses that read or write data,the number of bytes read or written,the percentage of I/O bytes that are part of a read (or write),and the rate of I/O per CPU-second in terms of both ﬁle accesses and bytes.Each core is counted individually,so at most 2CPU-seconds can be counted per second on our dual-core test machine.CPU utilization is measured with the UNIX top utility,which in rare cases produces anomalous CPU utilization snapshots;those values are ignored.Table 1contains a brief description of each of the 34iBench tasks as well as the basic I/O characteristics of each task when running on Mac OS X Snow Leopard 10.6.2.The table illustrates that the iBench tasks perform a signiﬁcant amount of I/O.Most tasks access hundreds of ﬁles,which in aggregate contain tens or hundreds of megabytes of data.The tasks typically access ﬁles hundreds of times.The tasks perform widely differing amounts of I/O,from less than a megabyte to more than a gigabyte.Most of the tasks perform many more reads than writes.Finally,the tasks exhibit high I/O throughput,often transferring tens of megabytes of data for every second of computation.3.2Easy to UseTo enable other system evaluators to easily use these tasks,the iBench suite is packaged as a set of 34system call traces.To ensure reproducible results,the 34user tasks were ﬁrst automated with AppleScript,a general-purpose GUI scripting language.Apple-Script provides generic commands to emulate mouse clicks through menus and application-speciﬁc commands to capture higher-level operations.Application-speciﬁc commands bypass a small amount of I/O by skipping dialog boxes;however,we use them whenever possible for expediency.The system call traces were gathered using DTrace [8],a kernel and user level dynamic instrumentation tool.DTrace is used toinstrument the entry and exit points of all system calls dealing with the ﬁle system;it also records the current state of the system and the parameters passed to and returned from each call.While tracing with DTrace was generally straightforward,we ad-dressed four challenges in collecting the iBench traces.First,ﬁle sizes are not always available to DTrace;thus,we record every ﬁle’s initial size and compute subsequent ﬁle size changes caused by system calls such as write or ftruncate .Second,iTunes uses the ptrace system call to disable tracing;we circumvent this block by using gdb to insert a breakpoint that automatically re-turns without calling ptrace .Third,the volfs pseudo-ﬁle sys-tem in HFS+(Hierarchical File System)allows ﬁles to be opened via their inode number instead of a ﬁle name;to include path-names in the trace,we instrument the build path function to obtain the full path when the task is run.Fourth,tracing system calls misses I/O resulting from memory-mapped ﬁles;therefore,we purged memory and instrumented kernel page-in functions to measure the amount of memory-mapped ﬁle activity.We found that the amount of memory-mapped I/O is negligible in most tasks;we thus do not include this I/O in the iBench traces or analysis.To provide reproducible results,the traces must be run on a sin-gle ﬁle-system image.Therefore,the iBench suite also contains snapshots of the initial directories to be restored before each run;initial state is critical in ﬁle-system benchmarking [1].4.ANALYSIS OF IBENCH TASKSThe iBench task suite enables us to study the I/O behavior of a large set of home-user actions.As shown from the timeline of I/O behavior for one particular task in Section2,these tasks are likely to accessﬁles in complex ways.To characterize this complex behavior in a quantitative manner across the entire suite of34tasks, we focus on answering four categories of questions.•What different types ofﬁles are accessed and what are the sizes of theseﬁles?•How areﬁles accessed for reads and writes?Areﬁles ac-cessed sequentially?Is space preallocated?•What are the transactional properties?Are writesﬂushed with fsync or performed atomically?•How do multi-threaded applications distribute I/O across dif-ferent threads?Answering these questions has two beneﬁts.First,the answers can guideﬁle and storage system developers to target their systems better to home-user applications.Second,the characterization will help users of iBench to select the most appropriate traces for eval-uation and to understand their resulting behavior.All measurements were performed on a Mac Mini running Mac OS X Snow Leopard version10.6.2and the HFS+ﬁle system. The machine has2GB of memory and a2.26GHz Intel Core Duo processor.4.1Nature of FilesOur analysis begins by characterizing the high-level behavior of the iBench tasks.In particular,we study the different types ofﬁles opened by each iBench task as well as the sizes of thoseﬁles. 4.1.1File TypesThe iLife and iWork applications store data across a variety of ﬁles in a number of different formats;for example,iLife applica-tions tend to store their data in libraries(or data directories)unique to each user,while iWork applications organize their documents in proprietary ZIP-basedﬁles.The extent to which tasks access dif-ferent types ofﬁles greatly inﬂuences their I/O behavior.To understand accesses to differentﬁle types,we place eachﬁle into one of six categories,based onﬁle name extensions and us-age.Multimediaﬁles contain images(e.g.,JPEG),songs(e.g., MP3,AIFF),and movies(e.g.,MPEG-4).Productivityﬁles are documents(e.g.,.pages,DOC,PDF),spreadsheets(e.g.,.numbers, XLS),and presentations(e.g.,.key,PPT).SQLiteﬁles are database ﬁles.Plistﬁles are property-listﬁles in XML containing key-value pairs for user preferences and application properties.Stringsﬁles contain strings for localization of application text.Finally,Other contains miscellaneousﬁles such as plain text,logs,ﬁles without extensions,and binaryﬁles.Figure2shows the frequencies with which tasks open and ac-cessﬁles of each type;most tasks perform hundreds of these ac-cesses.Multimediaﬁle opens are common in all workloads,though they seldom predominate,even in the multimedia-heavy iLife ap-plications.Conversely,opens of productivityﬁles are rare,even in iWork applications that use them;this is likely because most iWork tasks create or view a single productivityﬁle.Because.plistﬁles act as generic helperﬁles,they are relatively common.SQLiteﬁles only have a noticeable presence in iPhoto,where they account for a substantial portion of the observed opens.Stringsﬁles occupy a signiﬁcant minority of most workloads(except iPhoto and iTunes). Finally,between5%and20%ofﬁles are of type“Other”(except for iTunes,where they are more prevalent).Figure3displays the percentage of I/O bytes accessed for each ﬁle type.In bytes,multimedia I/O dominates most of the iLife tasks,while productivity I/O has a signiﬁcant presence in the iWork tasks;ﬁle descriptors on multimedia and productivityﬁles tend to receive large amounts of I/O.SQLite,Plist,and Stringsﬁles have a smaller share of the total I/O in bytes relative to the number of openedﬁles;this implies that tasks access only a small quantity of data for each of theseﬁles opened(e.g.,several key-value pairs in a.plist).In most tasks,ﬁles classiﬁed as“Other”receive a more signiﬁcant portion of the I/O(the exception is iTunes). Summary:Home applications access a wide variety ofﬁle types, generally opening multimediaﬁles the most frequently.iLife tasks tend to access bytes primarily from multimedia orﬁles classiﬁed as“Other”;iWork tasks access bytes from a broader range ofﬁle types,with some emphasis on productivityﬁles.4.1.2File SizesLarge and smallﬁles present distinct challenges to theﬁle sys-tem.For largeﬁles,ﬁnding contiguous space can be difﬁcult,while for smallﬁles,minimizing initial seek time is more important.We investigate two different questions regardingﬁle size.First,what is the distribution ofﬁle sizes accessed by each task?Second,what portion of accessed bytes resides inﬁles of various sizes?To answer these questions,we recordﬁle sizes when each unique ﬁle descriptor is closed.We categorize sizes as very small(<4KB), small(<64KB),medium(<1MB),large(<10MB),or very large (≥10MB).We track how many accesses are toﬁles in each cate-gory and how many of the bytes belong toﬁles in each category. Figure4shows the number of accesses toﬁles of each size.Ac-cesses to very smallﬁles are extremely common,especially for iWork,accounting for over half of all the accesses in every iWork task.Smallﬁle accesses have a signiﬁcant presence in the iLife tasks.The large quantity of very small and smallﬁles is due to frequent use of.plistﬁles that store preferences,settings,and other application data;theseﬁles oftenﬁll just one or two4KB pages. Figure5shows the proportion of theﬁles in which the bytes of accessedﬁles rge and very largeﬁles dominate every startup workload and nearly every task that processes multimedia ﬁles.Smallﬁles account for few bytes and very smallﬁles are essentially negligible.Summary:Agreeing with many previous studies(e.g.,[4]),we ﬁnd that while applications tend to open many very smallﬁles (<4KB),most of the bytes accessed are in largeﬁles(>1MB).4.2Access PatternsWe next examine how the nature ofﬁle accesses has changed, studying the read and write patterns of home applications.These patterns include whetherﬁles are used for reading,writing,or both; whetherﬁles are accessed sequentially or randomly;andﬁnally, whether or not blocks are preallocated via hints to theﬁle system.4.2.1File AccessesOne basic characteristic of our workloads is the division between reading and writing on openﬁle descriptors.If an application uses an openﬁle only for reading(or only for writing)or performs more activity onﬁle descriptors of a certain type,then theﬁle system may be able to make more intelligent memory and disk allocations. To determine these characteristics,we classify each openedﬁle descriptor based on the types of accesses–read,write,or both read and write–performed during its lifetime.We also ignore the ac-tualﬂags used when opening theﬁle since we found they do not accurately reﬂect behavior;in all workloads,almost all write-only ﬁle descriptors were opened with O RDWR.We measure both the。

【老机专版SP2】深度联盟GHOST

【老机专版SP2】深度联盟GHOST【老机专版SP2】深度联盟GHOST_XP_SP2低配置电脑专业版V5.5图片:Snap3.jpg图片:Snap4.jpg图片:Snap5.jpg图片:Snap6.jpg图片:Snap7.jpg图片:Snap8.jpg图片:Snap9.jpg=======================【老机专版SP2】深度联盟GHOST_XP_SP2低配置电脑专业版V5.5=======================首要说明：本系统精心制作面向老机，低配置计算机，珍藏版。

封装母盘：深度技术论坛精简优化版SP2（2008年）驱动包：雨林木风更新的驱动包（2010年2月4日）封装工具：雨林木风SysPacker 3.65.2.7系统格式：FAT32雨林木风SysPacker 3.65.2.7+雨林木风更新的驱动包+深度技术论坛精简优化版SP2=完美组合=======================深度联盟GHOST系统采用最新的封装技术，全面提升系统在计算机上的部署速度，恢复效率更高.系统中集成2010年2月以前流行的各种硬件驱动和部分版本最常用的软件。

完美通过微软正版验证，支持在线更新。

适合电脑维护人员快速给各类计算机安装和恢复系统使用。

本系统主要适用于笔记本、品牌机，也支持组装兼容机，安装后自动激活可供品牌机专卖店及普通用户安装使用，系统安装简便快速，3-8分钟内即可安装完成=======================更新提示说明：1、Adobe Flash Player for IE_11.2；2、优化系统响应速度以及软件运行速度，最大化优化各项设置。

3、采用雨林木风2010年4月最后一次更新的驱动包，对于老机支持更全面。

并采用雨林木风最后一次更新的封装工具进行封装，驱动和封装工具搭配的更完美，雨林木风的驱动务必和雨林木风的封装工具搭配使用才是最佳的。

4、封装母盘采用深度技术论坛2008年的SP2精简版，稳定性以及各方面优化都是首屈一指的。

Quantum Computing for Computer Scientists

More informationQuantum Computing for Computer ScientistsThe multidisciplinaryﬁeld of quantum computing strives to exploit someof the uncanny aspects of quantum mechanics to expand our computa-tional horizons.Quantum Computing for Computer Scientists takes read-ers on a tour of this fascinating area of cutting-edge research.Writtenin an accessible yet rigorous fashion,this book employs ideas and tech-niques familiar to every student of computer science.The reader is notexpected to have any advanced mathematics or physics background.Af-ter presenting the necessary prerequisites,the material is organized tolook at different aspects of quantum computing from the speciﬁc stand-point of computer science.There are chapters on computer architecture,algorithms,programming languages,theoretical computer science,cryp-tography,information theory,and hardware.The text has step-by-stepexamples,more than two hundred exercises with solutions,and program-ming drills that bring the ideas of quantum computing alive for today’scomputer science students and researchers.Noson S.Yanofsky,PhD,is an Associate Professor in the Departmentof Computer and Information Science at Brooklyn College,City Univer-sity of New York and at the PhD Program in Computer Science at TheGraduate Center of CUNY.Mirco A.Mannucci,PhD,is the founder and CEO of HoloMathics,LLC,a research and development company with a focus on innovative mathe-matical modeling.He also serves as Adjunct Professor of Computer Sci-ence at George Mason University and the University of Maryland.QUANTUM COMPUTING FORCOMPUTER SCIENTISTSNoson S.YanofskyBrooklyn College,City University of New YorkandMirco A.MannucciHoloMathics,LLCMore informationMore informationcambridge university pressCambridge,New York,Melbourne,Madrid,Cape Town,Singapore,S˜ao Paulo,DelhiCambridge University Press32Avenue of the Americas,New York,NY10013-2473,USAInformation on this title:/9780521879965C Noson S.Yanofsky and Mirco A.Mannucci2008This publication is in copyright.Subject to statutory exceptionand to the provisions of relevant collective licensing agreements,no reproduction of any part may take place withoutthe written permission of Cambridge University Press.First published2008Printed in the United States of AmericaA catalog record for this publication is available from the British Library.Library of Congress Cataloging in Publication dataYanofsky,Noson S.,1967–Quantum computing for computer scientists/Noson S.Yanofsky andMirco A.Mannucci.p.cm.Includes bibliographical references and index.ISBN978-0-521-87996-5(hardback)1.Quantum computers.I.Mannucci,Mirco A.,1960–II.Title.QA76.889.Y352008004.1–dc222008020507ISBN978-0-521-879965hardbackCambridge University Press has no responsibility forthe persistence or accuracy of URLs for external orthird-party Internet Web sites referred to in this publicationand does not guarantee that any content on suchWeb sites is,or will remain,accurate or appropriate.More informationDedicated toMoishe and Sharon Yanofskyandto the memory ofLuigi and Antonietta MannucciWisdom is one thing:to know the tho u ght by which all things are directed thro u gh allthings.˜Heraclitu s of Ephe s u s(535–475B C E)a s quoted in Dio g ene s Laertiu s’sLives and Opinions of Eminent PhilosophersBook IX,1. More informationMore informationContentsPreface xi1Complex Numbers71.1Basic Deﬁnitions81.2The Algebra of Complex Numbers101.3The Geometry of Complex Numbers152Complex Vector Spaces292.1C n as the Primary Example302.2Deﬁnitions,Properties,and Examples342.3Basis and Dimension452.4Inner Products and Hilbert Spaces532.5Eigenvalues and Eigenvectors602.6Hermitian and Unitary Matrices622.7Tensor Product of Vector Spaces663The Leap from Classical to Quantum743.1Classical Deterministic Systems743.2Probabilistic Systems793.3Quantum Systems883.4Assembling Systems974Basic Quantum Theory1034.1Quantum States1034.2Observables1154.3Measuring1264.4Dynamics1294.5Assembling Quantum Systems1325Architecture1385.1Bits and Qubits138viiMore informationviii Contents5.2Classical Gates1445.3Reversible Gates1515.4Quantum Gates1586Algorithms1706.1Deutsch’s Algorithm1716.2The Deutsch–Jozsa Algorithm1796.3Simon’s Periodicity Algorithm1876.4Grover’s Search Algorithm1956.5Shor’s Factoring Algorithm2047Programming Languages2207.1Programming in a Quantum World2207.2Quantum Assembly Programming2217.3Toward Higher-Level Quantum Programming2307.4Quantum Computation Before Quantum Computers2378Theoretical Computer Science2398.1Deterministic and Nondeterministic Computations2398.2Probabilistic Computations2468.3Quantum Computations2519Cryptography2629.1Classical Cryptography2629.2Quantum Key Exchange I:The BB84Protocol2689.3Quantum Key Exchange II:The B92Protocol2739.4Quantum Key Exchange III:The EPR Protocol2759.5Quantum Teleportation27710Information Theory28410.1Classical Information and Shannon Entropy28410.2Quantum Information and von Neumann Entropy28810.3Classical and Quantum Data Compression29510.4Error-Correcting Codes30211Hardware30511.1Quantum Hardware:Goals and Challenges30611.2Implementing a Quantum Computer I:Ion Traps31111.3Implementing a Quantum Computer II:Linear Optics31311.4Implementing a Quantum Computer III:NMRand Superconductors31511.5Future of Quantum Ware316Appendix A Historical Bibliography of Quantum Computing319 by Jill CirasellaA.1Reading Scientiﬁc Articles319A.2Models of Computation320More informationContents ixA.3Quantum Gates321A.4Quantum Algorithms and Implementations321A.5Quantum Cryptography323A.6Quantum Information323A.7More Milestones?324Appendix B Answers to Selected Exercises325Appendix C Quantum Computing Experiments with MATLAB351C.1Playing with Matlab351C.2Complex Numbers and Matrices351C.3Quantum Computations354Appendix D Keeping Abreast of Quantum News:QuantumComputing on the Web and in the Literature357by Jill CirasellaD.1Keeping Abreast of Popular News357D.2Keeping Abreast of Scientiﬁc Literature358D.3The Best Way to Stay Abreast?359Appendix E Selected Topics for Student Presentations360E.1Complex Numbers361E.2Complex Vector Spaces362E.3The Leap from Classical to Quantum363E.4Basic Quantum Theory364E.5Architecture365E.6Algorithms366E.7Programming Languages368E.8Theoretical Computer Science369E.9Cryptography370E.10Information Theory370E.11Hardware371Bibliography373Index381More informationPrefaceQuantum computing is a fascinating newﬁeld at the intersection of computer sci-ence,mathematics,and physics,which strives to harness some of the uncanny as-pects of quantum mechanics to broaden our computational horizons.This bookpresents some of the most exciting and interesting topics in quantum computing.Along the way,there will be some amazing facts about the universe in which we liveand about the very notions of information and computation.The text you hold in your hands has a distinctﬂavor from most of the other cur-rently available books on quantum computing.First and foremost,we do not assumethat our reader has much of a mathematics or physics background.This book shouldbe readable by anyone who is in or beyond their second year in a computer scienceprogram.We have written this book speciﬁcally with computer scientists in mind,and tailored it accordingly:we assume a bare minimum of mathematical sophistica-tion,aﬁrst course in discrete structures,and a healthy level of curiosity.Because thistext was written speciﬁcally for computer people,in addition to the many exercisesthroughout the text,we added many programming drills.These are a hands-on,funway of learning the material presented and getting a real feel for the subject.The calculus-phobic reader will be happy to learn that derivatives and integrals are virtually absent from our text.Quite simply,we avoid differentiation,integra-tion,and all higher mathematics by carefully selecting only those topics that arecritical to a basic introduction to quantum computing.Because we are focusing onthe fundamentals of quantum computing,we can restrict ourselves to theﬁnite-dimensional mathematics that is required.This turns out to be not much more thanmanipulating vectors and matrices with complex entries.Surprisingly enough,thelion’s share of quantum computing can be done without the intricacies of advancedmathematics.Nevertheless,we hasten to stress that this is a technical textbook.We are not writing a popular science book,nor do we substitute hand waving for rigor or math-ematical precision.Most other texts in theﬁeld present a primer on quantum mechanics in all its glory.Many assume some knowledge of classical mechanics.We do not make theseassumptions.We only discuss what is needed for a basic understanding of quantumxiMore informationxii Prefacecomputing as aﬁeld of research in its own right,although we cite sources for learningmore about advanced topics.There are some who consider quantum computing to be solely within the do-main of physics.Others think of the subject as purely mathematical.We stress thecomputer science aspect of quantum computing.It is not our intention for this book to be the deﬁnitive treatment of quantum computing.There are a few topics that we do not even touch,and there are severalothers that we approach brieﬂy,not exhaustively.As of this writing,the bible ofquantum computing is Nielsen and Chuang’s magniﬁcent Quantum Computing andQuantum Information(2000).Their book contains almost everything known aboutquantum computing at the time of its publication.We would like to think of ourbook as a usefulﬁrst step that can prepare the reader for that text.FEATURESThis book is almost entirely self-contained.We do not demand that the reader comearmed with a large toolbox of skills.Even the subject of complex numbers,which istaught in high school,is given a fairly comprehensive review.The book contains many solved problems and easy-to-understand descriptions.We do not merely present the theory;rather,we explain it and go through severalexamples.The book also contains many exercises,which we strongly recommendthe serious reader should attempt to solve.There is no substitute for rolling up one’ssleeves and doing some work!We have also incorporated plenty of programming drills throughout our text.These are hands-on exercises that can be carried out on your laptop to gain a betterunderstanding of the concepts presented here(they are also a great way of hav-ing fun).We hasten to point out that we are entirely language-agnostic.The stu-dent should write the programs in the language that feels most comfortable.Weare also paradigm-agnostic.If declarative programming is your favorite method,gofor it.If object-oriented programming is your game,use that.The programmingdrills build on one another.Functions created in one programming drill will be usedand modiﬁed in later drills.Furthermore,in Appendix C,we show how to makelittle quantum computing emulators with MATLAB or how to use a ready-madeone.(Our choice of MATLAB was dictated by the fact that it makes very easy-to-build,quick-and-dirty prototypes,thanks to its vast amount of built-in mathematicaltools.)This text appears to be theﬁrst to handle quantum programming languages in a signiﬁcant way.Until now,there have been only research papers and a few surveyson the topic.Chapter7describes the basics of this expandingﬁeld:perhaps some ofour readers will be inspired to contribute to quantum programming!This book also contains several appendices that are important for further study:Appendix A takes readers on a tour of major papers in quantum computing.This bibliographical essay was written by Jill Cirasella,Computational SciencesSpecialist at the Brooklyn College Library.In addition to having a master’s de-gree in library and information science,Jill has a master’s degree in logic,forwhich she wrote a thesis on classical and quantum graph algorithms.This dualbackground uniquely qualiﬁes her to suggest and describe further readings.More informationPreface xiii Appendix B contains the answers to some of the exercises in the text.Othersolutions will also be found on the book’s Web page.We strongly urge studentsto do the exercises on their own and then check their answers against ours.Appendix C uses MATLAB,the popular mathematical environment and an es-tablished industry standard,to show how to carry out most of the mathematicaloperations described in this book.MATLAB has scores of routines for manip-ulating complex matrices:we brieﬂy review the most useful ones and show howthe reader can quickly perform a few quantum computing experiments with al-most no effort,using the freely available MATLAB quantum emulator Quack.Appendix D,also by Jill Cirasella,describes how to use online resources to keepup with developments in quantum computing.Quantum computing is a fast-movingﬁeld,and this appendix offers guidelines and tips forﬁnding relevantarticles and announcements.Appendix E is a list of possible topics for student presentations.We give briefdescriptions of different topics that a student might present before a class of hispeers.We also provide some hints about where to start looking for materials topresent.ORGANIZATIONThe book begins with two chapters of mathematical preliminaries.Chapter1con-tains the basics of complex numbers,and Chapter2deals with complex vectorspaces.Although much of Chapter1is currently taught in high school,we feel thata review is in order.Much of Chapter2will be known by students who have had acourse in linear algebra.We deliberately did not relegate these chapters to an ap-pendix at the end of the book because the mathematics is necessary to understandwhat is really going on.A reader who knows the material can safely skip theﬁrsttwo chapters.She might want to skim over these chapters and then return to themas a reference,using the index and the table of contents toﬁnd speciﬁc topics.Chapter3is a gentle introduction to some of the ideas that will be encountered throughout the rest of the ing simple models and simple matrix multipli-cation,we demonstrate some of the fundamental concepts of quantum mechanics,which are then formally developed in Chapter4.From there,Chapter5presentssome of the basic architecture of quantum computing.Here one willﬁnd the notionsof a qubit(a quantum generalization of a bit)and the quantum analog of logic gates.Once Chapter5is understood,readers can safely proceed to their choice of Chapters6through11.Each chapter takes its title from a typical course offered in acomputer science department.The chapters look at that subﬁeld of quantum com-puting from the perspective of the given course.These chapters are almost totallyindependent of one another.We urge the readers to study the particular chapterthat corresponds to their favorite course.Learn topics that you likeﬁrst.From thereproceed to other chapters.Figure0.1summarizes the dependencies of the chapters.One of the hardest topics tackled in this text is that of considering two quan-tum systems and combining them,or“entangled”quantum systems.This is donemathematically in Section2.7.It is further motivated in Section3.4and formallypresented in Section4.5.The reader might want to look at these sections together.xivPrefaceFigure 0.1.Chapter dependencies.There are many ways this book can be used as a text for a course.We urge instructors to ﬁnd their own way.May we humbly suggest the following three plans of action:(1)A class that provides some depth might involve the following:Go through Chapters 1,2,3,4,and 5.Armed with that background,study the entirety of Chapter 6(“Algorithms”)in depth.One can spend at least a third of a semester on that chapter.After wrestling a bit with quantum algorithms,the student will get a good feel for the entire enterprise.(2)If breadth is preferred,pick and choose one or two sections from each of the advanced chapters.Such a course might look like this:(1),2,3,4.1,4.4,5,6.1,7.1,9.1,10.1,10.2,and 11.This will permit the student to see the broad outline of quantum computing and then pursue his or her own path.(3)For a more advanced class (a class in which linear algebra and some mathe-matical sophistication is assumed),we recommend that students be told to read Chapters 1,2,and 3on their own.A nice course can then commence with Chapter 4and plow through most of the remainder of the book.If this is being used as a text in a classroom setting,we strongly recommend that the students make presentations.There are selected topics mentioned in Appendix E.There is no substitute for student participation!Although we have tried to include many topics in this text,inevitably some oth-ers had to be left out.Here are a few that we omitted because of space considera-tions:many of the more complicated proofs in Chapter 8,results about oracle computation,the details of the (quantum)Fourier transforms,and the latest hardware implementations.We give references for further study on these,as well as other subjects,throughout the text.More informationMore informationPreface xvANCILLARIESWe are going to maintain a Web page for the text at/∼noson/qctext.html/The Web page will containperiodic updates to the book,links to interesting books and articles on quantum computing,some answers to certain exercises not solved in Appendix B,anderrata.The reader is encouraged to send any and all corrections tonoson@Help us make this textbook better!ACKNOLWEDGMENTSBoth of us had the great privilege of writing our doctoral theses under the gentleguidance of the recently deceased Alex Heller.Professor Heller wrote the follow-ing1about his teacher Samuel“Sammy”Eilenberg and Sammy’s mathematics:As I perceived it,then,Sammy considered that the highest value in mathematicswas to be found,not in specious depth nor in the overcoming of overwhelmingdifﬁculty,but rather in providing the deﬁnitive clarity that would illuminate itsunderlying order.This never-ending struggle to bring out the underlying order of mathematical structures was always Professor Heller’s everlasting goal,and he did his best to passit on to his students.We have gained greatly from his clarity of vision and his viewof mathematics,but we also saw,embodied in a man,the classical and sober ideal ofcontemplative life at its very best.We both remain eternally grateful to him.While at the City University of New York,we also had the privilege of inter-acting with one of the world’s foremost logicians,Professor Rohit Parikh,a manwhose seminal contributions to theﬁeld are only matched by his enduring com-mitment to promote younger researchers’work.Besides opening fascinating vis-tas to us,Professor Parikh encouraged us more than once to follow new directionsof thought.His continued professional and personal guidance are greatly appre-ciated.We both received our Ph.D.’s from the Department of Mathematics in The Graduate Center of the City University of New York.We thank them for providingus with a warm and friendly environment in which to study and learn real mathemat-ics.Theﬁrst author also thanks the entire Brooklyn College family and,in partic-ular,the Computer and Information Science Department for being supportive andvery helpful in this endeavor.1See page1349of Bass et al.(1998).More informationxvi PrefaceSeveral faculty members of Brooklyn College and The Graduate Center were kind enough to read and comment on parts of this book:Michael Anshel,DavidArnow,Jill Cirasella,Dayton Clark,Eva Cogan,Jim Cox,Scott Dexter,EdgarFeldman,Fred Gardiner,Murray Gross,Chaya Gurwitz,Keith Harrow,JunHu,Yedidyah Langsam,Peter Lesser,Philipp Rothmaler,Chris Steinsvold,AlexSverdlov,Aaron Tenenbaum,Micha Tomkiewicz,Al Vasquez,Gerald Weiss,andPaula Whitlock.Their comments have made this a better text.Thank you all!We were fortunate to have had many students of Brooklyn College and The Graduate Center read and comment on earlier drafts:Shira Abraham,RachelAdler,Ali Assarpour,Aleksander Barkan,Sayeef Bazli,Cheuk Man Chan,WeiChen,Evgenia Dandurova,Phillip Dreizen,C.S.Fahie,Miriam Gutherc,RaveHarpaz,David Herzog,Alex Hoffnung,Matthew P.Johnson,Joel Kammet,SerdarKara,Karen Kletter,Janusz Kusyk,Tiziana Ligorio,Matt Meyer,James Ng,SeverinNgnosse,Eric Pacuit,Jason Schanker,Roman Shenderovsky,Aleksandr Shnayder-man,Rose B.Sigler,Shai Silver,Justin Stallard,Justin Tojeira,John Ma Sang Tsang,Sadia Zahoor,Mark Zelcer,and Xiaowen Zhang.We are indebted to them.Many other people looked over parts or all of the text:Scott Aaronson,Ste-fano Bettelli,Adam Brandenburger,Juan B.Climent,Anita Colvard,Leon Ehren-preis,Michael Greenebaum,Miriam Klein,Eli Kravits,Raphael Magarik,JohnMaiorana,Domenico Napoletani,Vaughan Pratt,Suri Raber,Peter Selinger,EvanSiegel,Thomas Tradler,and Jennifer Whitehead.Their criticism and helpful ideasare deeply appreciated.Thanks to Peter Rohde for creating and making available to everyone his MAT-LAB q-emulator Quack and also for letting us use it in our appendix.We had a gooddeal of fun playing with it,and we hope our readers will too.Besides writing two wonderful appendices,our friendly neighborhood librar-ian,Jill Cirasella,was always just an e-mail away with helpful advice and support.Thanks,Jill!A very special thanks goes to our editor at Cambridge University Press,HeatherBergman,for believing in our project right from the start,for guiding us through thisbook,and for providing endless support in all matters.This book would not existwithout her.Thanks,Heather!We had the good fortune to have a truly stellar editor check much of the text many times.Karen Kletter is a great friend and did a magniﬁcent job.We also ap-preciate that she refrained from killing us every time we handed her altered draftsthat she had previously edited.But,of course,all errors are our own!This book could not have been written without the help of my daughter,Hadas-sah.She added meaning,purpose,and joy.N.S.Y.My dear wife,Rose,and our two wondrous and tireless cats,Ursula and Buster, contributed in no small measure to melting my stress away during the long andpainful hours of writing and editing:to them my gratitude and love.(Ursula is ascientist cat and will read this book.Buster will just shred it with his powerful claws.)M.A.M.。

[Beizer 1995] B. Beizer, Black-Box Testing Techniques for Functional Testing of

References[Bai 2001a] X. Bai, W. T. Tsai, R. Paul, T. Shen and B. Li, “Distributed End-to-End Testing Management”, to appear in Proc. of IEEE EDOC, 2001.[Bai 2001b] X. Bai, W. T. Tsai, R. Paul, K. Feng, L. Yu, “Scenario-Based Business Modeling”, Department of Computer Science and Engineering, Arizona State University, Tempe, AZ 85287, 2001.[Beizer 1990] B. Beizer, Software Testing, 2nd edition, Van Nostrand Reinhold, New York, New York, 1990.[Beizer 1995] B. Beizer, Black-Box Testing: Techniques for Functional Testing of Software and Systems, John Wiley & Sons, New York, New York, 1995.[Binder 2000] R. Binder, Testing Object-Oriented Systems: Models, Patterns, and Tools, Addison Wesley, Reading, MA, 2000.[Burns 1990] A. Burns and A. Wellings, Real-Time Systems and Their Programming Languages, Addison Wesley, Reading, MA, 1990.[DoD 1999] DoD OASD C3I Investment and Acquisition, “Year 2000 Management Plan”, 1999.[DoD 2000] DoD OASD C3I Investment and Acquisition, “Guide for Remediating Latent Year 2000 Defects Caused by Date Windowing”, 2000.[DoD 2001] DoD OASD C3I Investment and Acquisition, “End-to-End Integration Testing Guidebook”, 2001.[Fewster 1999] M. Fewster and D. Graham, Software Test Automation: Effective Use of Test Execution Tools, Addison Wesley, Reading, MA, 1999.[Grehan 1998] R. Grehan, R. Moote, and I. Cyliax, Real-Time Programming: A Guide to 32-bit Embedded Development, Addison Wesley, Reading, MA, 1998.[Harmelen 2001] M. V. Harmelen, editor, Object Modeling and User Interface Design, Addison Wesley, Reading, MA, 2001.[Kalinowski 2001] K. Kalinowski, “GDLS Vetronics Software Strategy”, NDIA 2001 Vehicle Technologies Symposium, Intelligent Systems for the Objective Fleet, May 2001.[Kaner 1999] C. Kaner, J. Falk, and H. Q. Nguyen, Testing Computer Software, 2nd Edition, Wiley, New York, New York, 1999.[Kirani 1994] S. Kirani and W. T. Tsai, “Method Sequence Specification and Verification of Classes”, Journal of Object-Oriented Programming, 1994.[Kulak 1998] D. Kulak and E. Guiney, Use Cases: Requirements in Context, ACM Press, Addison Wesley, Reading, MA, 1998.[Kung 1999] D. C. Kung, P. Hsia, and J. Gao, Testing Object-Oriented Software, IEEE Computer Society Press, Los Alamitos, CA, 1999.[Leveson 1995] N. Leveson, Safeware: System Safety and Computers, Addison Wesley, Reading, MA, 1995.[Lyu 1996] M. Lyu, editor, Handbook of Software Reliability Engineering, IEEE Computer Society Press, McGraw Hill, New York, New York, 1996.[Marick 1995] B. Marick, The Craft of Software Testing, Prentice Hall, Englewood Cliffs, NJ, 1995.[Mojdehbakhsh 1994] R. Mojdehbakhsh, S. Kirani, W. T. Tsai, and L. Elliot, "Retrofitting Software Safety in an Implantable Medical Device", IEEE Software, Vol. 11, No. 1, Jan. 1994, pp. 41-50.[Mosley 2000] D. J. Mosley, Client-Server Software Testing on the Desktop and the Web, Prentice Hall PTR, Upper Saddle River, NJ, 2000.[Musa 1987] J. Musa, A. Iannino, and K. Okumoto, Software Reliability: Measurement, Prediction, Application, McGraw-Hill, New York, New York, 1987.[Nguyen 2001] H. Q. Nguyen, Testing Applications on the Web, Testing Planning for Internet-Based Sys tems, Wiley, 2001.[Onoma 1998] A. K. Onoma, W. T. Tsai, M. Poonawala, and H. Suganuma, “Regression Testing in an Industrial Environment”, Communications of ACM, May 1998.[Paul 2000] R. Paul and W. T. Tsai, “Assurance-Based Testing – A New Quality Assurance Technique”, Proc. of Quality Week, Europe, 2000.[Paul 2001] R. Paul, W.T. Tsai, B. Li, and X. Bai, “XML-Based Test Assets Management”, Department of Computer Science and Engineering, Arizona State University, Tempe, AZ 85287, 2001.[Poonawala 1997] M. Poonawala, S. Subramanian, R. Vishnuvajjala, W. T. Tsai, R. Mojdehbakhsh and L. Elliott,"Testing Safety-Critical Systems -- A Reuse-Oriented Approach", Proc. of 9th International Conference on SEKE, 1997, pp. 271-278. [Pressman 2000] R. Pressman, Software Engineering: A Practitioner’s Approach,5th edition, McGraw-Hill, New York, New York, 2000.[RAC 1998] Reliability Toolkit: Commercial Practices Edition, A Practical Guide for Commercial Products and Military Systems Under Acquisition Reform, Reliability Analysis Center (RAC), Rome Laboratory.[RTCA 1992] RTCA/DO-178B, "Software Considerations in Airborne Systems and Equipment Certification," December 1, 1992.[Rumbaugh 1999] J. Rumbaugh, I. Jacobson, and G. Booch, The Unified Modeling Language Reference Manual, Addison Wesley, Reading, MA, 1999.[Sommerville 2000] I. Sommerville, Software Engineering, 6th edition, Addison Wesley, Reading, MA, 2000.[Storey 1996] N. Storey, Safety-Critical Computer Systems, Addison-Wesley, Reading, MA, 1996.[Tsai 1998] W. T. Tsai, R. Mojdehbakhsh and F. Zhu, "Ensuring System and Software Reliability in Safety-Critical Applications", in Proc. of IEEE Application-Specific Software Engineering Technology, 1998.[Tsai 1999a] W. T. Tsai, R. Paul, W. Shao, S. Rayadurgam, and J. Li, “Assurance-Based Y2K Testing”, 1999 Proc. 4th IEEE International Symposium on High-Assurance Systems Engineering, pp. 27-34.[Tsai 1999b] W. T. Tsai, Y. Tu, W. Shao and E. Ebner, “Testing Extensible Design Patterns in Object-Oriented Frameworks through Hierarchical Scenario Templates”, Proc. COMPSAC’99, 1999, pp. 166-171.[Tsai 1999c] W. T. Tsai, R. Vishnuvajjala and D. Zhang, “Verification and Validation of Knowledge-Based Systems”, IEEE Trans. on Knowledge and Data Engineering, 1999.[Tsai 2001a] W.T. Tsai, X. Bai, R. Paul, W. Shao, V. Agarwal, T. Sheng, and B. Li, “End-to-End Integration Testing Design”, to appear in Proc. of IEEE COMPSAC 2001.[Tsai 2001b] W.T. Tsai, X. Bai, R. Paul, and L. Yu, “Scenario-Based Functional Regression Testing”, to appear in Proc. of IEEE COMPSAC, 2001.[Uehara 2000] S. Uehara, W. T. Tsai, T. Sano and Baba, Software Maintenance and Re-Engineering, Kyoritsu Publication, Japan, 2000.[Vishnuvajjala 2001] R. Vishnuvajjala, W. T. Tsai, R. Paul, “Testing Timing Constraints in Time-Critical Systems: Problems, Techniques and Patterns”, draft DoD OASD C3I Investment and Acquisition Guidebook, 2001.[Zhu 1998] F. Zhu and W. T. Tsai, "Automating Regression Testing for Real-Time Software in a Distributed Environment", Proc. of IEEE International Symposium on Object-Oriented Real-Time Distributed Computing, 1998.Website References[FAA_web] Federal Aviation Administration (FAA), Department of Transportation, “Quality Assurance of Software Used in Aircraft or Related Products”, AC 21-33, /software/Policy%20&%20Guidance/ac21-33.pdf.[FDA_web_1] Food and Drug Administration (FDA) “General Principle of Software Validation: Guidance for Industries,”/cdrh/comp/swareval.html.[FDA_web_2] Food and Drug Administration (FDA) “Medical Device Use-Safety:Incorporating Human Factors Engineering into Risk Management,”/cdrh/humfac/1497.pdf[Johnson_web 1998] L. A. Johnson, “Do-198B, ‘Software Consideration in Airborne Systems and Equipment Certification’”, /CrossTalk/1998/oct/schad.asp.[Musa_web] J. D. Musa and J. Widmaier “Software-Reliability-Engineered Testing,”/crosstalk/1996/jun/Reliabil.asp.[NASA_web_1] NASA Software Assurance Standards, NASA-STD-2201-93, /assure/astd.txt.[NASA_web_2] NASA Software Assurance Guidebook, NASA-GB-A201, /assure/agb.txt.[NASA_web_3] NASA, Software Safety NASA Technical Standards, NASA-STD-8719.13A, 1997, /assure/nss8719_13.html.[NRC_web] Office of Nuclear Regulatory Research, U.S. Nuclear Regulatory Commission (NRC), Fault Tree Handbook, 1981. Available at the website /NRC/NUREGS/SR0492/index.html.[Parasoft_web] Parasoft, “Jtest,”/products/jtest/index.htm Website Addresses for Similar Courses Offered at Other Universities orConferencesCMU (/~koopman/)Southern Polytechnic State University Southern Polytechnic State University (SPSU) (/pbobbie/embsys.htm)Georgia Tech (/~hamblen/489X/)University of Colorado at Bounder (/embedded.html), University of California at Irvine (/~rgupta/iec.html)Depaul University (/kbernstein/SE540/)University of Texas at Austin (/~bev ans/)Dublin City University at Ireland (papp.dcu.ie/~dsinclai/rtes.html) University of Florida (/)The Embedded Object-Based Systems Workshop(/news/meetings/embedded2001/progam.htm)The Embedded System Conference (/sf/classes.htm)Case Studies:[NRC_CASE1 1996] Office of Nuclear Regulatory Research, U.S. Nuclear Regulatory Commission, “Guide to Verification and Validation of the SCALE-4 Criticality Safety Software”, 1996. Available at the website /NRC/NRREGS/CR6483/index.html.[NRC_CASE2 1996] Office of Nuclear Regulatory Research, U.S. Nuclear Regulatory Commission,”Guide to Verification and Validation of the SCALE-4 Radiation Shielding Software”, 1996. Available at the website /NRC/NUREGS/CR6484/cr6484.pdf.。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。