2023年-软件工程课后习题答案.docx

《2023年-软件工程课后习题答案.docx》由会员分享，可在线阅读，更多相关《2023年-软件工程课后习题答案.docx（13页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件工程课后习题答案1.1) The definition for software presented in Section 1.2 applies to the Web sites. There are, however, subtle differences between a Web site and conventional software. Among the most important are that the content that a Web site presents is considered to be part of the Web Application wh

2、ile that data processed by conventional software is often considered to be separate fiom the processing functions delivered.1.4) Who would have thought that software would lead to: (1) a change in the dating habits of many young people (Internet dating); (2) the way people communicate (cell phones);

3、 (3) methods of warfare (cyberweapons); (4) the diagnosis of diseases (MRIs and related computer-based diagnostic devices), and (5) the manner in which people acquire and enjoy media (music, DVDs, etc.).1.6) The Law of Conservation of Familiarity: As the system evolves the users engineers, developer

4、s all those associated must have the complete knowledge of the content and behavior to achieve satisfactory results. Increase in growth may diminish that knowledge (mastery); hence the average increase in growth remains invariant as the system evolves.1.7) Many modern applications change frequently

5、before they are presented to the end user and then after the first versions have been used. A few ways to build software to stop deterioration due to change would be: Make sure that software is designed so that changes in one part of a program do not create side-effects in another part of the progra

6、m. Make sure that software is designed so that it does not depend on external devices or systems that are likely to change with time. Make sure test cases and results are archived and available so that the software can be retested when changes are made. Make sure you spend time understanding what th

7、e customer wants.1.8) The two broadest categories encompass risks associated with economic loss and risks to the well being of people. It might be a good idea to select five risks (culled from the sources noted) and present them to the class. Look for humorous as well as serious risks.1.9) The same

8、approach to software engineering can be applied for each of the six categories, but it must be adapted to accommodate the special requirements of each category.1.10) There are literally dozens of real life circumstances to choose from. For example, software errors that have caused major telephone ne

9、tworks to fail, failures in avionics that have contributed to plane crashes, computer viruses (e.g., Michelangelo) that have caused significant economic losses and attacks on major e-commerce sites.1.11) The Law of Declining Quality: The quality of systems will decline unless they are maintained by

10、various procedures to adapt to the environmental changes. This concept is similar to the deterioration” discussed in Problem 1-5.1.12) The Law of Conservation of Organizational Stability: The average effective global activity rate is invariant over the lifetime of a product.Pattern:CommunicationInte

11、nt:To establish a collaborative relationship with the customer in an effort to define project scope, business requirements and other project constraints.,Type:Initial context:Stage pattern(1) Appropriate stakeholders have been identified and are willing to participate in communication (2) Stakeholde

12、rs agree that a problem exists and that software may provide a solutionProblem:Requirements must be elicited from stakeholders and organized in a way that can be used by software engineers. All stakeholders must collaborate to define requirements and to identify those areas where requirements are un

13、certain.Solution: Each stakeholder must develop a description of the functions, features, information and behavior that are exhibited by the software. To accomplish this, a structured, facilitated meeting is conducted. For more details, see Sections 7.3, 7.4 and 7.5.Resulting Context:When this patte

14、rn has been successfully completed, basic information required for thedevelopment of an analysis model has been acquired and documented in some manner. Use-cases (user scenarios) have been developed, along with basic descriptions of system function and behavior and the data objects that are to be ma

15、nipulated and/or produced/Related Patterns: Conducted a meeting; requirement gathering; developing use-cases; building a mini-spec; negotiating requirements, prioritization.Known Uses/Examples: Communication is mandatory at the beginning of every software project; is recommended throughout the softw

16、are project; and is mandatory once the deployment activity is underway.1.5) ) Hierarchical: dataflow, call return, layerNon-hierarchical: data centered, object-orientedNon-hierarchical architectures are probably best implemented using object-oriented and event driven programming techniques.1.6) ) A

17、compete design of the PHTRS system can be accomplished the architectural design model elements discussed in this chapter, Because the application is driven by the data architecture that is chosen, you should begin with a detailed data design. Following that, design classes and related architectural

18、information should be represented.1.9) ) When transform mapping is used where transaction mapping should be used, two problems arise: (1) the program structure tends to become top heavy with control modules-these should be eliminated; (2) significant data coupling occurs because information associat

19、ed with one of many processing actions* must be passed to an outgoing path. Classic examples include: many engineering analysis algorithms, many process control applications, some commercial applications. Look for a well-developed DFD and correct mapping to program structure.1.10) ) Many people defi

20、ne architectural style and architectural pattern as being one in the same (a general system model used as the starting point for system design). A framework might be defined by some people as a set of classes providing a general solution to a problem that can be refined to create an application or s

21、ubsystem.1.11) ) Data centered architecture: airline reservation system; library catalog system; hotel booking system Data flow architecture: any engineering/scientific application where computation is the major functionCall and return architecture: any I-P-0 applicationObject-oriented architectures

22、: GUI-based applications; any OO application Layered architecture: any application in which the application functions must be decoupled from the underlying OS or network detail. Client server software is often layered.1.12) ) The concepts of styles and patterns occur for buildings and software at bo

23、th macroscopic and microscopic levels. For example, overall styles (center-hall colonial, A-frame) can be found in a house. These represent macroscopic styles. Lower-level microscopic patterns (for a house) can be found in categories of wood molding, fireplace designs, windows, etc.11.1) Guard-condi

24、tion is written in Object Constraint Language (OCL) and specifies a condition that must be met before the event can occur, and action expression defines an action that occurs as the transition takes place.11.2) Like object-oriented components, traditional software components are derived from the ana

25、lysis model. In this case, however, the data flow-oriented element of the analysis model serves as the basis for the derivation. Each transform (bubble) represented at the lowest levels of the data flow diagram is mapped (Section 10.6) into a module hierarchy. Control components (modules) reside nea

26、r the top of the hierarchy (architecture) and problem domain components tend to reside toward the bottom of the hierarchy. To achieve effective modularity, design concepts like functional independence arc applied as components are elaborated.11.3) The Open-Closed Principle (OCP) states module compon

27、ent should be open for extension but closed fbr modification. The designer creates the designer should specify the component in a way that allows it to be extended (within the functional domain that it addresses) without the need to make internal (code abstractions that serve as a buffer between the

28、 functionality that is likely to be extended and the design class itself.11.4) External coupling occurs when a component communicates or collaborates with infrastructure components (e.g., operation system functions, database capability, telecommunication functions). Although this type of coupling is

29、 necessary, it should be limited to a small number of components or classes within a system. Software must coinmunicate internally and externally. Therefore, coupling is a fact of life. However, the designer should work to reduce coupling whenever possible and understand the ramifications of high co

30、upling when it cannot be avoided.11.5) Dependency Inversion Principle (DIP) states, depend on abstractions. Do not depend on concretions. The more a component depends on other concrete components (rather than on abstractions such as an interface), the more difficult it will be to extend.11.6) Within

31、 the context of componcnt-lcvel design fbr object-oriented systems, cohesion implies that a component or class encapsulates only attributes and operations that are closely related to one another and to the class or component itself. Components that highly cohesive are insulated from relying on servi

32、ces provided by other components will make their implementation and maintenance of easier.11.7) Coupling is a qualitative measure of the degree to which classes are connected to one another. As classes (and components) become more interdependent, coupling increases. A benefit of low coupling if the

33、ease among components is the ease with which components can be modified without affected the behavior of other components.11.8) Some possibilities for infrastructure components might be user interface classes, data storage subsystem, physics engine in a video game, etc.11.9) Component-level design d

34、efines the data structures, algorithms, interface characteristics, and communication mechanisms allocated to each software component. In object-oriented languages (e.g. Java or Smalltalk) components are classes or objects. In traditional languages (e.g. C or Fortran) components are functions or proc

35、edures. In mixed languages like C+ components might be either functions or classes.11.10) Public attributes are data that are visible and accessible to all other components, private attributes are only visible and accessible within the component in which they are defined. They are used to enforce da

36、ta encapsulation and information hiding.11.12) Databases and files normally transcend the design description of an individual component. In most cases, these persistent data stores are initially specified as part of architectural design. However, as design elaboration proceeds, it is often useful to

37、 provide additional detail about the structure and organization of these persistent data sources. The term persistent means that the data exist before the application is executed and after it has terminated execution.11.13) Factoring is the process of distributing the control a decision-making of th

38、e system so that the top-level modules perform control functions and the low-level modules perform all input, processing, and output work. In stepwise refinement a program is developed by successively refining levels of procedural detail. For traditional software development they are very similar.11

39、.16) To conduct component-level design in this context, classes are elaborated by specifying messaging details, identifying appropriate interfaces, elaborating attributes and defining data structures to implement them, describing processing flow within each operation, and representing behavior at a

40、class or component level. In every case, design iteration (refactoring) is an essential activity.12.1) When response time is unpredictable, the user becomes impatient and re-attempts the command requested or tries another command. In some cases, this can create queuing problems (fbr commands) and in

41、 extreme cases, cause loss of data or even a system failure. Research has shown that users can tolerate up to 50% variation in response rates fbr applications they are familiar with. For unfamiliar applications users become anxious after 15-30 second unexpected delays (the half-life of their short t

42、erm memory).12.2) Examples might be: If the user desires, display shortcut command sequences on the screen at all times. Provide the facilities fbr hints” when a WebApp requires password input12.3) Answers will vary; typical questions to be added: Where are audio prompts used and fbr what purpose? A

43、re content object generated dynamically? Are there constraints on the placement of graphical objects? Are there screen size limitations that dictate placement of content? Is there a mechanism fbr magnification of screen content?12.4) Examples might be: Use color consistently, e.g., red for warning m

44、essages, blue fbr informational content. Provide keyword driven on-line help.12.7) Examples might be: Catch potential interaction errors before they do undoable damage. Allow the user to customize screen layout as well as commands. Make use of breakaway menus so that common functions are always read

45、ily available.13.1) The most common problem in the creation of an ITG is getting and keeping good people. In addition, hostility between the ITG and the software engineering group can arise if the interaction between groups is not properly managed. Finally, the ITG may get involved in a project too

46、late一when time is short and a thorough job of test planning and execution cannot be accomplished. An ITG and an SQA group are not necessarily the same. The ITG focuses solely on testing, while the SQA group considers all aspects of quality assurance.13.2) Verification focuses on the correctness of a

47、 program by attempting to find errors in function or performance. Validation focuses on nconformance to requirementsa fundamental characteristic of quality.13.3) A highly coupled module interacts with other modules, data and other system elements. Therefore its function is often dependent of the ope

48、ration of those coupled elements. In order to thoroughly unit test such a module, the function of the coupled elements must be simulated in some manner. This can be difficult and time consuming.13.4) Developer, if customer acceptance test is planned. Both developer and customer (user) if no further

49、tests arc contemplated. An independent test group is probably the best alternative here, but it isnt one of the choices.13.5) It is not always possible to conduct thorough unit testing in that the complexity of a test environment to accomplish unit testing (i.e., complicated drivers and stubs) may not justify the benefit. Integration testing is complicated by the scheduled availability of unit-tested modules (especially