软件工程实践者的研究方法答案.docx

1、软件工程实践者的研究方法答案软件工程实践者的研究方法答案【篇一：外文翻译-软件工程-实践者的研究方法】are engineering-a practitioners approach written by roger s. pressman, ph.d. （p.340-p.343） 13.3 design principles software design is both a process and a model. the design process is a sequence ofsteps that enable the designer to describe all aspect

2、s of the software to be built. it is important to note, however, that the design process is not simply a cookbook. creative skill, past experience, a sense of what makes “good” software, and an overallcommitment to quality are critical success factors for a competent design. the design model is the

3、equivalent of an architects plans for a house. it begins by representing the totality of the thing to be built (e.g., a three-dimensional renderingof the house) and slowly refines the thing to provide guidance for constructing eachdetail (e.g., the plumbing layout). similarly, the design model that

4、is created for softwareprovides a variety of different views of the computer software. basic design principles enable the software engineer to navigate the design process.davis suggests a setof principles for software design, which have beenadapted and extended in the following list: ? the design pr

5、ocess should not suffer from “tunnel vision.” a gooddesigner should consider alternative approaches, judging each based on therequirements of the the resources available to do the job, and thedesign concepts presented in section ? the design should be traceable to the analysis model. because a singl

6、eelement of the design model often traces to multiple requirements, it is necessaryto have a means for tracking how requirements have been satisfied bythe design model. ? the design should not reinvent the wheel. systems are constructed usinga set of design patterns, many of which have likely been e

7、ncountered before.these patterns should always be chosen as an alternative to reinvention.time is short and resources are limited! design time should be invested iepresenting truly new ideas and integrating those patterns that already exist. ? the design should “minimize the intellectual distance” b

8、etween the software and the problem as it exists in the real world.that is, the structure of the software design should (whenever possible)mimic the structure of the problem domain.? the design should exhibit uniformity and integration. a design is uniformif it appears that one person developed the

9、entire thing. rules of styleand format should be defined for a design team before design work begins. adesign is integrated if care is taken in defining interfaces between designcomponents. ? the design should be structured to accommodate change. the designconcepts discussed in the next section enab

10、le a design to achieve this principle. ? the design should be structured to degrade gently, even when aberrantdata, events, or operating conditions are encountered. welldesignedsoftware should never “bomb.” it should be designed toaccommodate unusual circumstances, and if it must terminate processin

11、g, doso in a graceful manner. ? design is not coding, coding is not design. even when detailed proceduraldesigns are created for program components, the level of abstraction ofthe design model is higher than source code. the only design decisions madeat the coding level address the small implementat

12、ion details that enable theprocedural design to be coded. ? the design should be assessed for quality as it is being created, notafter the fact. a variety of design concepts (section 13.4) and design measures(chapters 19 and 24) are available to assist the designer in assessing quality. ? the design

13、 should be reviewed to minimize conceptual (semantic)errors. there is sometimes a tendency to focus on minutiae when the design isreviewed, missing the forest for the trees. a design team should ensure thatmajor conceptual elements of the design (omissions, ambiguity, inconsistency)have been address

14、ed before worrying about the syntax of the design model. when these design principles are properly applied, the software engineer creates a designthat exhibits both external and internal quality factors . external quality factorsare those properties of the software that can be readily observed by us

15、ers (e.g., speed,reliability, correctness, usability).internal quality factors are of importance to softwareengineers. they lead to a high-quality design from the technical perspective. to achieveinternal quality factors, the designer must understand basic design concepts. 13.4 design concepts a set

16、 of fundamental software design concepts has evolved over the past four decades.although the degree of interest in each concept has varied over the years, each hasstood the test of time. each provides the software designer with a foundation fromwhich more sophisticated design methods can be applied.

17、 each helps the softwareengineer to answer the following questions:? what criteria can be used to partition software into individual components? ? how is function or data structure detail separated from a conceptual representation of the software? ? what uniform criteria define the technical quality

18、 of a software design? m. a. jackson once said: the beginning of wisdom for a software engineer is torecognize the difference between getting a program to work, and getting it right. fundamental software design concepts provide the necessary frameworkfor getting it right. 13.4.1 abstraction when we

19、consider a modular solution to any problem, many levels of abstraction canbe posed. at the highest level of abstraction, a solution is stated in broad terms usingthe language of the problem environment. at lower levels of abstraction, a more proceduralorientation is taken. problem-oriented terminolo

20、gy is coupled with implementation-oriented terminology in an effort to state a solution. finally, at the lowestlevel of abstraction, the solution is stated in a manner that can be directly implemented.wasserman provides a useful definition: the psychological notion of abstraction permits one to conc

21、entrate on a problem atsome level of generalization without regard to irrelevant low level details; use of abstractionalso permits one to work with concepts and terms that are familiar in the problem environmentwithout having to transform them to an unfamiliar structure . . . each step in the softwa

22、re process is a refinement in the level of abstraction of the software solution. during system engineering, software is allocated as an element ofa computer-based system. during software requirements analysis, the software solutionis stated in terms that are familiar in the problem environment. as w

23、e movethrough the design process, the level of abstraction is reduced. finally, the lowestlevel of abstraction is reached when source code is generated. as we move through different levels of abstraction, we work to create proceduraland data abstractions. a procedural abstraction is a named sequence

24、 of instructionsthat has a specific and limited function. an example of a procedural abstraction would be the word open for a door. open implies a long sequence of procedural steps (e.g.,walk to the door, reach out and grasp knob, turn knob and pull door, step away frommoving door, etc.). a data abs

25、traction is a named collection of data that describes a data objectchapter12). in the context of the procedural abstraction open, we can define a data abstractioncalled door. like any data object, the data abstraction for door would encompassa set of attributes that describe the door (e.g., door typ

26、e, swing direction, peningmechanism, weight, dimensions). it follows that the procedural abstraction open wouldmake use of information contained in the attributes of the data abstraction door. many modern programming languages provide mechanisms for creating abstractdata types. for example, the ada

27、package is a programming language mechanismthat provides support for both data and procedural abstraction. the original abstractdata type is used as a template or generic data structure from which other data structurescan be instantiated. control abstraction is the third form of abstraction used in

28、software design. likeprocedural and data abstraction, control abstraction implies a program control mechanismwithout specifying internal details. an example of a control abstraction is thesynchronization semaphore used to coordinate activities in an operating system.the concept of the control abstra

29、ction is discussed briefly in chapter 14. 13.4.2 refinement stepwise refinement is a top-down design strategy originally proposed by niklaus wirth. a program is developed by successively refining levels of procedural detail.a hierarchy is developed by decomposing a macroscopic statement of function

30、(aprocedural abstraction) in a stepwise fashion until programming language statementsare reached. an overview of the concept is provided by wirth: in each step (of the refinement), one or several instructions of the given program are decomposedinto more detailed instructions. this successive decompo

31、sition or refinement of specificationsterminates when all instructions are expressed in terms of any underlying computeror programming language . . . as tasks are refined, so the data may have to be refined,decomposed, or structured, and it is natural to refine the program and the data specification

32、sin parallel. every refinement step implies some design decisions. it is important that . . . the programmerbe aware of the underlying criteria (for design decisions) and of the existence ofalternative solutions . . . refinement is actually a process of elaboration.we begin with a statement offuncti

33、on(or description of information) that is defined at a high level of abstraction. thatis, the statement describes function or information conceptually but provides no informationabout the internal workings of the function or the internal structure of theinformation. refinement causes the designer to elaborate on