計(jì)算機(jī)外文翻譯分析導(dǎo)論

1、<p>　　畢業(yè)設(shè)計(jì)（論文）——外文翻譯（原文）</p><p>　　Introduction to Analysis</p><p><b>　　Purpose</b></p><p>　　The analysis phase of object-oriented software development is an activit

2、y aimed at clarifying the requirements of an intended software system, with: </p><p><b>　　Input: </b></p><p>　　A fuzzy, minimal, possibly inconsistent target specification, user poli

3、cy and project charter. </p><p><b>　　Output: </b></p><p>　　Understanding, a complete, consistent description of essential characteristics and behavior. </p><p>　　Techniq

4、ues: </p><p>　　Study, brainstorming, interviewing, documenting. </p><p>　　Key notion for the descriptions: </p><p><b>　　Object. </b></p><p>　　The final item

5、 in this list distinguishes object-oriented analysis from other approaches, such as Structured Analysis and Jackson's method. </p><p>　　Importance</p><p>　　Constructing a complex artifact is

6、 an error-prone process. The intangibility of the intermediate results in the development of a software product amplifies sensitivity to early errors. For example, Davis reports the results of studies done in the early 1

7、970's at GTE, TRW and IBM regarding the costs to repair errors made in the different phases of the life cycle. As seen in the following summary table, there is about a factor of 30 between the costs of fixing an erro

8、r during the requirement phase</p><p>　　Further savings are indeed possible. Rather than being aimed at a particular target system, an analysis may attempt to understand a domain that is common to a family o

9、f systems to be developed. A domain analysis factors out what is otherwise repeated for each system in the family. Domain analysis  lays the foundation for reuse  across systems. </p><p><b>　

10、　Input</b></p><p>　　There are several common input scenarios, generally corresponding to the amount of ``homework'' done by the customer: </p><p>　　At one extreme, we can have as i

11、nput a ``nice idea''. In this case, the requirements are most likely highly incomplete. The characterization of the ATM system in Chapter 1 is an example. The notion of a bank card (or any other technique) to be

12、used by a customer for authentication is not even mentioned. In this case, elaboration on the requirements is a main goal. Intensive interaction between analyst and client will be the norm. </p><p>　　In the

13、ideal case, a document may present a ``totally'' thought-through set of requirements. However, ``totally'' seldom means that the specification is really complete. ``Obvious'' aspects are left out

14、or are circumscribed by reference to other existing systems. One purpose of the analysis is to make sure that there are indeed no surprises hiding in the omissions. Moreover, a translation into (semi) formal notations is

15、 bound to yield new insights in the requirements of the target system. </p><p>　　In another scenario, the requirements are not yet complete. Certain trade-offs may have been left open on purpose. This may be

16、 the case when the requirements are part of a public offering for which parties can bid. For instance, we can imagine that our ATM example is a fragment of the requirements formulated by a bank consortium. Since the diff

17、erent members of the consortium may have different regulations, certain areas may have been underdefined and left to be detailed in a later phase. A main </p><p>　　A requirements document may propose constru

18、ction of a line of products rather than one system in particular. This represents a request for an OO domain analysis. Domain analysis specifies features common to a range of systems rather than, or in addition to, any o

19、ne product. The resulting domain characterization can then be used as a basis for multiple target models. Domain analysis is discussed in more detail in Chapter 13 . Until then, we will concentrate most heavily on the an

20、alysis of single </p><p>　　Across such scenarios we may classify inputs as follows:     </p><p>　　Functionality: </p><p>　　Descriptions that outline behavior in terms

21、 of the expectations and needs of clients of a system. (``Client'' is used here in a broad sense. A client can be another system.) </p><p>　　Resource: </p><p>　　Descriptions that outline

22、 resource consumptions for the development of a system (or for a domain analysis) and/or descriptions that outline the resources that an intended system can consume. </p><p>　　Performance: </p><p&

23、gt;　　Descriptions that constrain acceptable response-time characteristics. </p><p>　　Miscellaneous: </p><p>　　Auxiliary constraints such as the necessity for a new system to interface with exist

24、ing systems, the dictum that a particular programming language is to be used, etc. </p><p>　　Not all these categories are present in all inputs. It is the task of the analyst to alert the customer when there

25、 are omissions. </p><p>　　As observed by Rumbaugh et al, the input of a fuzzy target specification is liable to change due to the very nature of the analysis activity. Increased understanding of the task at

26、hand may lead to deviations of the initial problem characterization. Feedback from the analyst to the initiating customer is crucial. Feedback failure leads to the following consideration: If an analyst does exactly what

27、 the customer asked for, but the result does not meet the customer's real need, the analyst will be</p><p><b>　　Output </b></p><p>　　The output of an analysis for a single target

28、 system is, in a sense, the same as the input, and may be classified into the same categories. The main task of the analysis activity is to elaborate, to detail, and to fill in ``obvious'' omissions. Resource and

29、 miscellaneous requirements often pass right through, although these categories may be expanded as the result of new insights obtained during analysis. </p><p>　　The output of the analysis activity should be

30、 channeled in two directions. The client who provided the initial target specification is one recipient. The client should be convinced that the disambiguated specification describes the intended system faithfully and in

31、 sufficient detail. The analysis output might thus serve as the basis for a contractual agreement between the customer and a third party (the second recipient) that will design and implement the described system. Of cour

32、se, especially </p><p>　　An analyst must deal with the delicate question of the feasibility of the client's requirements. For example, a transportation system with the requirement that it provide interst

33、ellar travel times of the order of seconds is quite unambiguous, but its realization violates our common knowledge. Transposed into the realm of software systems, we should insist that desired behavior be plausibly imple

34、mentable. </p><p>　　Unrealistic resource and/or performance constraints are clear reasons for nonrealizability. Less obvious reasons often hide in behavioral characterizations. Complex operations such as Und

35、erstand, Deduce, Solve, Decide, Induce, Generalize, Induct, Abduct and Infer are not as yet recommended in a system description unless these notions correspond to well-defined concepts in a certain technical community. &

36、lt;/p><p>　　Even if analysts accept in good faith the feasibility of the stated requirements, they certainly do not have the last word in this matter. Designers and implementors may come up with arguments that

37、demonstrate infeasibility. System tests may show nonsatisfaction of requirements. When repeated fixes in the implementation and/or design do not solve the problem, backtracking becomes necessary in order to renegotiate t

38、he requirements. When the feasibility of requirements is suspect, prototyping  of </p><p><b>　　Models</b></p><p>　　Most attention in the analysis phase is given to an elaboratio

39、n of functional requirements. This is performed via the construction of models describing objects, classes, relations, interactions, etc. </p><p>　　Declarative Modeling</p><p>　　We quote from Al

40、an Davis : </p><p>　　A Software Requirements Specification is a document containing a complete description of what the software will do without describing how it will do it.  </p><p>　　Subs

41、equently, he argues that this what/how distinction is less obvious than it seems. He suggests that in analogy to the saying ``One person's floor is another person's ceiling'' we have ``One person's ho

42、w is another person's what''. He gives examples of multiple what/how layers that connect all the way from user needs to the code. </p><p>　　We will follow a few steps of his reasoning using the s

43、ingle requirement from our ATM example that clients can obtain cash from any of their accounts. </p><p>　　Investigating the desired functionality from the user's perspective may be seen as a definition o

44、f what the system will do. </p><p>　　The ability of clients to obtain cash is an example of functionality specified by the user. </p><p>　　``The next step might be to define all possible systems

45、 ... that could satisfy these needs. This step clearly defines how these needs might be satisfied. ...'' </p><p>　　The requirements already exclude a human intermediary. Thus, we can consider differe

46、nt techniques for human-machine interaction, for example screen and keyboard interaction, touch screen interaction, audio and voice recognition. We can also consider different authentication techniques such as PIN, iris

47、analysis, handline analysis. These considerations address the how dimension. </p><p>　　``On the other hand, we can define the set of all systems that could possibly satisfy user needs as a statement of what

48、we want our system to do without describing how the particular system ... will behave.'' </p><p>　　The suggestion to construct this set of all systems (and apply behavior abstraction?) strikes us as

49、artificial for the present discussion, although an enumeration of techniques may be important to facilitate a physical design decision. </p><p>　　``The next step might be to define the exact behavior of the

50、actual software system to be built ... This step ... defines how the system behaves ...'' </p><p>　　This is debatable and depends on the intended meaning of ``exact behavior''. If this refers

51、 to the mechanism of the intended system then we subscribe to the quotation. However, it could also encompass the removal of ambiguity by elaborating on the description of the customer-ATM interaction. If so, we still re

52、side in what country. For example, we may want to exemplify that customer authentication precedes all transactions, that account selection is to be done for those customers who own multiple</p><p>　　``On the

53、 other hand, we can define the external behavior of the actual product ... as a statement of what the system will do without defining how it works internally.'' </p><p>　　We may indeed be more specif

54、ic by elaborating an interaction sequence with: ``A client can obtain cash from an ATM by doing the following things: Obtaining proper access to the ATM, selecting one of his or her accounts when more than one owned, sel

55、ecting the cash dispense option, indicating the desired amount, and obtaining the delivered cash.'' We can go further in our example by detailing what it means to obtain proper access to an ATM, by stipulating th

56、at a bank card has to be inserted, and t</p><p>　　``The next step might be to define the constituent architectural components of the software system. This step ... defines how the system works internally ...

57、'' </p><p>　　Davis continues by arguing that one can define what these components do without describing how they work internally. </p><p>　　In spite of such attempts to blur how versus w

58、hat, we feel that these labels still provide a good initial demarcation of the analysis versus the design phase. </p><p>　　On the other hand, analysis methods (and not only OO analysis methods) do have a how

59、 flavor. This is a general consequence of any modeling technique. Making a model of an intended system is a constructive affair. A model of the dynamic dimension of the intended system describes how that system behaves.

60、However, analysts venture into how-country only to capture the intended externally observable behavior, while ignoring the mechanisms that realize this behavior. </p><p>　　The object-oriented paradigm puts a

61、nother twist on this discussion. OO analysis models are grounded in object models that often retain their general form from analysis (via design) into an implementation. As a result, there is an illusion that what and ho

62、w get blurred (or even should be blurred). We disagree with this fuzzification. It is favorable indeed that the transitions between analysis, design, and implementation are easier (as discussed in Chapter 15), but we do

63、want to keep separate the</p><p>　　We should also note that the use of models of any form is debatable. A model  often contains spurious elements that are not strictly demanded to represent the requirem

64、ents. The coherence and concreteness of a model and its resulting (mental) manipulability is, however, a distinct advantage. </p><p>　　Objects in Analysis</p><p>　　OO analysis models center on o

65、bjects. The definition of objects given in Chapter 1 is refined here for the analysis phase. The bird's eye view definition is that an object is a conceptual entity that: </p><p>　　is identifiable; </

66、p><p>　　has features that span a local state space; </p><p>　　has operations that can change the status of the system locally, while also inducing operations in peer objects. </p><p>　

67、　Since we are staying away from solution construction in the analysis phase, the objects allowed in this stage are constrained. The output of the analysis should make sense to the customer of the system development activ

68、ity. Thus we should insist that the objects correspond with customers' notions, and add: </p><p>　　an object refers to a thing which is identifiable by the users of the target system -- either a tangible

69、 thing or a mental construct. </p><p>　　Another ramification of avoiding solution construction pertains to the object's operator descriptions. We will stay away from procedural characterizations in favor

70、 of declarative ones. </p><p>　　Active Objects</p><p>　　Some OO analysis methods have made the distinction between active and passive objects.   For instance Colbert defines an object

71、as active if it ``displays independent motive power'', while a passive object ``acts only under the motivation of an active object''. </p><p>　　We do not ascribe to these distinctions, at lea

72、st at the analysis level. Our definition of objects makes them all active, as far as we can tell. This active versus passive distinction seems to be more relevant for the design phase (cf., Bailin ). </p><p>

73、;　　This notion of objects being active is motivated by the need to faithfully represent the autonomy of the entities in the ``world'', the domain of interest. For example, people, cars, accounts, banks, transacti

74、ons, etc., are all behaving in a parallel, semi-independent fashion. By providing OO analysts with objects that have at least one thread of control,  they have the means to stay close to a natural representation of

75、the world. This should facilitate explanations of the analysis output to a c</p><p>　　Four-Component View</p><p>　　A representation of a system is based on a core vocabulary. The foundation of t

76、his vocabulary includes both static and dynamic dimensions. Each of these dimensions complements the other. Something becomes significant as a result of how it behaves in interaction with other things, while it is distin

77、guished from those other things by more or less static features. This distinction between static and dynamic dimensions is one of the axes that we use to distinguish the models used in analysis. </p><p>　　Ou

78、r other main distinction refers to whether a model concentrates on a single object or whether interobject connections are addressed. The composition of these two axes give us the following matrix: </p><p>　　

79、Detailed treatments of the cells in this matrix are presented in the following chapters. </p><p>　　The static row includes a disguised version of entity-relationship (ER) modeling . ER modeling was init

80、ially developed for database design. Entities correspond to objects, and relations occur between objects.1 Entities are described using attributes . Constraints  capture limitations among attribute value combin

81、ations. Acquaintanceships represent the static connections among interacting objects. </p><p>　　1Footnote:The terms ``relation'' and ``relationship'' are generally interchangeable. ``Relatio

82、nship'' emphasizes the notion as a noun phrase. </p><p>　　The dynamic row indicates that some form of state machinery is employed to describe the behavior of a prototypical element of a class .

83、Multiple versions of causal connections capture the ``social'' behavior of objects. </p><p>　　Inheritance  impacts all four cells by specifying relationships among classes. Inheritance allows th

84、e construction of compact descriptions by factoring out commonalities. </p><p>　　Other Model Components</p><p>　　The four models form a core. Additional models are commonly added to give summary

85、 views and/or to highlight a particular perspective. The core models are usually represented in graphic notations. Summary models are subgraphs that suppress certain kinds of detail. </p><p>　　For instance,

86、a summary model in the static realm may remove all attributes and relationship interconnections in a class graph to highlight inheritance structures. Alternatively, we may want to show everything associated with a certai

87、n class C, for example, its attributes, relationships in which C plays a role, and inheritance links in which C plays a role. </p><p>　　An example in the dynamic realm is a class interaction graph  wher

88、e the significance of a link between two classes signifies that an instance of one class can connect in some way or another with an instance of another class. Different interaction mechanisms can give rise to various int

89、eraction summary graphs. Another model component can capture prototypical interaction sequences between a target system and its context. Jacobson has labeled this component use cases . They are discussed in Chapter&

90、lt;/p><p>　　All of these different viewpoints culminate in the construction of a model of the intended system  as discussed in Chapter 10.</p><p><b>　　Process</b></p><p&

91、gt;　　Several factors prevent analysis from being performed according to a fixed regime. The input to the analysis phase varies not only in completeness but also in precision. Backtracking to earlier phases is required to

92、 the extent of the incompleteness and the fuzziness of the input. Problem size, team size, corporate culture, etc., will influence the analysis process as well. </p><p>　　After factoring out these sources of

93、 variation, we may still wonder whether there is an underlying ``algorithm'' for the analysis process. Investigation of current OO analysis methods reveals that: </p><p>　　The creators of a method us

94、ually express only a weak preferences for the sequence in which models are developed. </p><p>　　There is as yet no consensus about the process. </p><p>　　There appear to be two clusters of appro

95、aches: (1) Early characterization of the static dimension by developing a vocabulary in terms of classes, relations, etc. (2) Early characterization of the behavioral dimension, the system-context interactions. </p>

96、;<p>　　We have similarly adopted a weak bias. Our presentation belongs to the cluster of methods that focuses on the static dimension first and, after having established the static models, gives attention to the d

97、ynamic aspects. However, this position is mutable if and when necessary. For instance in developing large systems, we need top-down  functional decompositions to get a grip on manageable subsystems. Such a decomposi

98、tion requires a preliminary investigation of the dynamic realm. Chapter 9 (Ense</p><p>　　The article from </p><p>　　http://g.oswego.edu/dl/oosdw3/ch2.html#SECTION00040000000000000000</p>

99、<p>　　It is the Chapter 2 of book Object-Oriented System Development.</p><p>　　畢業(yè)設(shè)計(jì)（論文）——外文翻譯（譯文）</p><p><b>　　分析導(dǎo)論</b></p><p><b>　　目的</b></p><

100、;p>　　面向?qū)ο筌浖_發(fā)的分析階段是一項(xiàng)旨在闡明預(yù)期軟件系統(tǒng)的需求為目標(biāo)的活動(dòng)，它包括：</p><p><b>　　輸入：</b></p><p>　　一份模糊的，較小的，可能不規(guī)范的目標(biāo)說明書，用戶政策和項(xiàng)目大綱。</p><p><b>　　輸出：</b></p><p>　　可以理解

101、的，一種完整的，一致的基本特征和行為的描述。</p><p><b>　　技巧：</b></p><p>　　研究，集思廣益，訪談，記錄。</p><p><b>　　關(guān)鍵概念的說明：</b></p><p><b>　　對象。</b></p><p>

102、　　在上述清單上的最后一項(xiàng)是區(qū)別于其他途徑的分析，就像結(jié)構(gòu)化分析和Jackson方法。</p><p><b>　　重要性</b></p><p>　　構(gòu)建一個(gè)復(fù)雜的工件是一個(gè)易錯(cuò)的過程。開發(fā)軟件產(chǎn)品的中間結(jié)果會(huì)無形的擴(kuò)大了早期的敏感性錯(cuò)誤。例如，Davis報(bào)告了一項(xiàng)研究成果，是在1970年代研究了關(guān)于GTE,TRW和IBM修改生命周期的不同階段產(chǎn)生的錯(cuò)誤的花費(fèi)。正如