1、毕业设计（论文） 外文翻译（原文） Introduction to Analysis Purpose The analysis phase of object-oriented software development is an activity aimed at clarifying the requirements of an intended software system, with: Input: A fuzzy, minimal, possibly inconsistent target specification, user policy and project charter
2、. Output: Understanding, a complete, consistent description of essential characteristics and behavior. Techniques: Study, brainstorming, interviewing, documenting. Key notion for the descriptions: Object. The final item in this list distinguishes object-oriented analysis from other approaches, such
3、as Structured Analysis and Jacksons method. Importance Constructing a complex artifact is 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 th
4、e early 1970s 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 error during the requirement phase and fixing that error in the acceptance test,
5、 and a factor of 100 with respect to the maintenance phase. Given the fact that maintenance can be a sizable fraction of software costs, getting the requirements correct should yield a substantial payoff. Development Phase Relative Cost of Repair Requirements 0.1 - 0.2 Design 0.5 Coding 1 Unit test
6、2 Acceptance test 5 Maintenance 20 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 of systems to be developed. A domain analysis factors out what is otherwise repeated for each syste
7、m in the family. Domain analysis lays the foundation for reuse across systems. Input There are several common input scenarios, generally corresponding to the amount of homework done by the customer: At one extreme, we can have as input a nice idea. In this case, the requirements are most likely high
8、ly 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 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
9、and client will be the norm. In the 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 or are circumscribed by reference to other existing systems. One purpose of the
10、analysis is to make sure that there are indeed no surprises hiding in the omissions. Moreover, a translation into (semi) formal notations is bound to yield new insights in the requirements of the target system. In another scenario, the requirements are not yet complete. Certain trade-offs may have b
11、een left open on purpose. This may be 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 different members of the consortium may have di
12、fferent regulations, certain areas may have been underdefined and left to be detailed in a later phase. A main aim of the analysis will be the precise demarcation of these white areas on the map. A requirements document may propose construction of a line of products rather than one system in particu
13、lar. 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 one product. The resulting domain characterization can then be used as a basis for multiple target models. Domain analysis is discussed in mor
14、e detail in Chapter 13 . Until then, we will concentrate most heavily on the analysis of single target systems. However, we also note that by nature, OO analysis techniques often generate model components with applicability stretching well beyond the needs of the target system under consideration. E
15、ven if only implicit, some form and extent of domain analysis is intrinsic to any OO analysis. Across such scenarios we may classify inputs as follows: Functionality: Descriptions that outline behavior in terms of the expectations and needs of clients of a system. (Client is used here in a broad sen
16、se. A client can be another system.) Resource: Descriptions that outline 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. Performance: Descriptions that constrain acceptable response-t
17、ime characteristics. Miscellaneous: Auxiliary constraints such as the necessity for a new system to interface with existing systems, the dictum that a particular programming language is to be used, etc. Not all these categories are present in all inputs. It is the task of the analyst to alert the cu
18、stomer when there are omissions. 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 hand may lead to deviations of the initial problem characterization. Feedback from the
19、 analyst to the initiating customer is crucial. Feedback failure leads to the following consideration: If an analyst does exactly what the customer asked for, but the result does not meet the customers real need, the analyst will be blamed anyway. Output The output of an analysis for a single target
20、 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 miscellaneous requirements often pass right through, although these categories may be expan
21、ded as the result of new insights obtained during analysis. The output of the analysis activity should be 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
22、 system faithfully and in 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 course, especially for small projects, the client, user, an
23、alyst, designer, and implementor parties may overlap, and may even all be the same people. An analyst must deal with the delicate question of the feasibility of the clients requirements. For example, a transportation system with the requirement that it provide interstellar travel times of the order
24、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 implementable. Unrealistic resource and/or performance constraints are clear reasons for nonrealizability. Less obvio
25、us reasons often hide in behavioral characterizations. Complex operations such as Understand, 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 communi
26、ty. 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 demonstrate infeasibility. System tests may show nonsatisfaction of requirements. When repeated fi
27、xes in the implementation and/or design do not solve the problem, backtracking becomes necessary in order to renegotiate the requirements. When the feasibility of requirements is suspect, prototyping of a relevant vertical slice is recommended. A mini-analysis and mini-design for such a prototype can prevent rampant throwaway prototyping. Models Most attention in the analysis phase is given to an elaboration of functional requirements. This is performed via the construction of models describing objects, classes, relations, interactions, etc. Declarative Modeling
