发布时间 : 星期六 文章软件工程实践者的研究方法答案- 更新完毕开始阅读bf10aab6a4e9856a561252d380eb6294dd882290
软件工程实践者的研究方法答案
【篇一：外文翻译--《软件工程-实践者的研究方法》】
are engineering-a practitioner’s 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 aspects 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 equivalent of an architect’s 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 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 process 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 singleelement 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 encountered 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”
between 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 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 enable 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 processing, 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 implementation 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 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 addressed 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
users (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 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. 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 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 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 terminology 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 concentrate 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 software 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 we 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 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 abstraction is a named collection of data that describes a data object
chapter12). 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 type, 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 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 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