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

软件工程课后习题答案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 while that data processed by conventional software is often considered to be separate fi'om 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) 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, developers 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 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 program. 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 the 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 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 networks 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 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:CommunicationIntent: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) Stakeholders 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 uncertain.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 pattern 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 manipulated 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 software 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 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 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 associated 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 define 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 subsystem.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: 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 both 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-condition 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 analysis 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 near 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 component 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 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 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 coupling 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 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 services 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 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 defines 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 procedures. 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 data 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 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 the 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.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 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 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 term 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? Are 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 messages, 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 readily 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 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 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 operation 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 tests arc contemplated. An independent test group is probably the best alternative here, but it isn't 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