软件工程复习题内容总结英文版高伟

1、Chapter 1 : introduction to software engineering1.1 the goal of software engineering：on time, within budget, satisfies the user's needs, fault-free software1.2software(1)difference between software and hardware. and why ?(a)software is developed or engineered; it is not manufactured in the class

2、ical sense. (b) software doesnt “wear out”, it deteriorates. Because multiple change requests introduce errors in component interactions.figure1.2 failure curves for software.(2) Although the industry is moving toward component-based construction, most software continues to be custom built. Why? Off

3、-the-shelf software components are unavailable in many application domains.chapter 2: a generic view of process2.1 Software Engineering A Layered Technology Layered Technology (figure2.1): a quality focus, process, methods, tools.2.2 A Process Framework whats the five framework activities in the gen

4、eric process framework?communication, planning, modeling, construction, deployment.2.3 The Capability Maturity Model Integration (CMMI)five capability levels : incomplete, performed, managed, defined, quantitatively managed, optimized Team software process(1)The objectives of Team Software Process (

5、a)Build self-directed teams that plan and track their work, establish goals, and own their processes and plans. These can be pure software teams or integrated product teams (IPT) of 3 to about 20 engineers. (b) Show managers how to coach and motivate their teams and how to help them sustain peak per

6、formance. (highly trained professionals) (c) Accelerate software process improvement by making CMM level 5 behavior normal and expected. (d) Provide improvement guidance to high-maturity organizations. (e) Facilitate university teaching of industrial-grade team skills.chapter 3 : process models3.2 t

7、he waterfall model (the classic life cycle) the waterfall model is a reasonable approach when requirements are well defined.whats the situation this model can be used and not can be used?what is the problem of this model?3.3 incremental process models 3.3.1 the incremental modelsthe incremental mode

8、ls is a good approach when a working core product is required quicklywhats the situation this model can be used and not can be used?what is the problem of this model? the RAD modelThe Rapid Application Development(RAD) is an incremental software process model that emphasizes a shot development cycle

9、.(highly speed)whats the features of this model?whats the situation this model can be used and not can be used?what is the problem of this model?3.4 evolutionary process models prototypingRegardless of the manner in which it is applied, the prototyping paradigm assists the software engineer and the

10、customer to better under stand what is to be built when requirements are fuzzy.whats the features of this model?whats the situation this model can be used and not can be used?what is the problem of this model? the spiral modelRisk is considered as each revolution is made.whats the features of this m

11、odel?whats the situation this model can be used and not can be used?what is the problem of this model? the concurrent development modelwhats the features of this model?whats the situation this model can be used and not can be used?what is the problem of this model?3.5 Specialized Process Models Comp

12、onent-Based DevelopmentComponent-Based Development works best when object technologies are available for support. The Formal Methods ModelThe formal methods model encompasses a set of activities that leads to formal mathematical specification of computer software. Formal methods enabled a software e

13、ngineer to specify, develop, and verify a computer-based system by applying a rigorous, mathematical notation.3.6 The Unified Process whats the Unified Process Model?（answer the phases of the unified process） Phase of the Unified Processinception phase, elaboration phase, construction phase, transit

14、ion phase, production phaseactivities (like requirements, design etc.) are determined iteratively and may span more than one phase of the Unified process.chapter 6 : System Engineering6.1 computer-based systemA computer-based system makes use of a variety of system elements: software, hardware, peop

15、le, database, documentation, procedures.6.3 Business Process Engineering: An OverviewThree different architectures must be analyzed and designed within the context of business objectives and goals:(a) Data architecture(b) Applications architecture(c) Technology infrastructure6.3 Product Engineering

16、: An OverviewThe architecture encompasses four distinct system components : software, hardware, data (and database), and people.chapter 7 : Requirements Engineering7.2 Requirements Engineering Taskswhats the Requirements engineering? (answer the 7 tasks) Inception ElicitationA number of problems tha

17、t help us understand why requirements elicitation is difficult:problems of blems of understanding. problems of volatility ElaborationThe end-result of elaboration is an analysis model that defines the informational, functional, and behavioral domain of the problem. Negotiation Specification

18、 Validation Requirements ManagementFeatures traceability table are maintained as part of a requirements database so that they can be quickly searched to understand how a change in one requirement will affect different aspects of the system to be built.7.5 Developing Use-casewhats use-case? draw the

19、use-case diagram.(figure7.3)7.6 Building the Analysis Model Elements of the Analysis Modelwhats activity diagram? draw the activity diagram.(figure7.4)7.8 Validating Requirements A review of the analysis model addresses the following a list of questions. A checklist of questions should be asked and

20、answered to ensure that the requirements model is an accurate reflection of the customers needs and that it provides a solid foundation for design.chapter 8 : Building the Analysis ModelA model is a simplification of reality. It can help us to visualize a system, give us a template for constructing

21、a system and document our decisions.8.1 Requirements Analysis Domain AnalysisSoftware domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain.Object-oriented

22、domain analysis is the identification, analysis, and specification of common, reusable capabilities within a specific application domain, in terms of common objects, classes, subassemblies, and frameworks.8.3 Data Modeling ConceptsThe data dictionary contains control item and data object of each sof

23、tware.The state of an object is defined by an objects attributes and relationships. The Control Specification8.5Scenario-based modelingWhats the scenario?Whats the uses case?Whats the relationship between scenario and use case?In a use case diagram, an actor is represented by a labeled stick figure8

24、.6Flow-Oriented Modeling Creating a Data Flow Model Create a Control Flow Model. The Control SpecificationThe control specification(CSPEC) represents the behavior of the system(at the level from which it has been referenced) in two different ways.figure 8.12 state diagram(whats the meaning of the Do

25、 and Entry in a state) The Process SpecificationThe process specification(PSPEC) is used to describe all flow model processes that appear at the final level of refinement. used to descript every bubble.8.7 Class-based Modeling Analysis PackagesAn analysis package involves the categorization of analy

26、sis model elements into useful groupings 8.8 Creating a Behavioral Model The behavioral model indicates how software will respond to external events or stimuli. whats the steps to create the model? Identifying Events with the use-caseWhats a Sequence Diagram, Collaboration Diagram respectively? What

27、s the difference between them? State RepresentationsThe state of an object is defined by an objects attributes and relationships.Two different behavioral representations : (a) state diagrams for analysis classes,. whats state transition diagram?(b) sequence diagram. whats sequence diagram?chapter 9

28、: Design Engineering9.1 Design within the Context of Software Engineering Each of the elements of the analysis model provides information that is necessary to create the four design models required for a complete specification of design.(figure9-1)the Data/class designthe architectural designthe int

29、erface designthe component-level design9.2 Design Process And Design QualityThe three characteristics that serve as a guide for the evaluation of a good design.The eight guidelines to evaluate the quality for a good design.9.3 Design Concepts Abstraction ArchitectureStructural model, framework model

30、s, Dynamic models, process models, functional models. Patterns Modularity“divide and conquer” strategy. Information Hidingwhats information hiding?information hiding and encapsulation Functional Independence Refinement Refactoring Design Classes9.5 Pattern-based Software Design Using Patterns in Des

31、ignArchitectural patternsDesign patternsidioms Frameworkschapter 10 : Creating an Architectural DesignThe informal, functional, and behavioral domains serve as a guide for the creation of the software design.10.1 Software Architecture What Is ArchitectureThe software architecture of a program or com

32、puting system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.10.3 Architectural Styles and Patterns The software that is built for computer-based systems also exhibits one of ma

33、ny architectural styles. Each style describes a system category that encompasses(1) a set of components(e.g., a database, computational modules) that perform a function required by a system; (2) a set of connectors that enable” communication, coordination, and cooperation” among components; (3) cons

34、traints that define how components can be integrated to form the system; and (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts. Refining the Architecture into ComponentsThe application domain is one

35、source for the derivation and refinement of components. Another source is the infrastructure domain. The architecture must accommodate many infrastructure components that enable application components but have no business connection to the application domain. For example, memory management component

36、s, communication components, database components, and task management components are often integrated into the software architecture. An architecture Trade-off Analysis MethodWhats the evaluation process for software architecture?How to descript the architecture style?(module, data flow, process)10.

37、6 Mapping Data Flow Into a Software Architecture Transform Flow Transaction FlowIn transaction mapping the first level factoring results in the derivation of the control hierarchy.When the Transform flow mapping or transaction flow mapping is finished, we should design the module interface descripti

38、ons and the processing narratives for each modulechapter 11 : Modeling Component-Level Design11.1 Whats Is A Component? Stated in a general fashion, a component is a modular building block for computer software. An Object-Oriented View In the context of object-oriented software engineering, a compon

39、ent contains a set of collaborating classes. The Conventional ViewIn the context of conventional software engineering, a component is a functional element of a program that incorporates processing logic, the internal data structures that are required to implement the processing logic, and an interfa

40、ce that enabled the component to be invoked and data to be passed to it. A Conventional component, also called a module, resides within the software architecture and serves one of three important roles as: (1) a control component that coordinates the invocation of all other problem domain components

41、, (2) a problem domain component that implements a complete or partial function that is required by the customer, or (3) an infrastructure component that is responsible for functions that support the processing required in the problem domain.11.5 Designing Conventional Components Tabular Design Nota

42、tionDecision Table : evaluated a complex combination of conditions and select appropriate actions based on these conditions.chapter 13 : Testing Strategies13.1 A Strategic Approach to Software Testing Verification and ValidationVerification : are we building the product right?Validation : Are we bui

43、lding the right product?13.4 Test Strategies For Object-Oriented Software Unit Test in the OO ContextWe can no longer test a single operation in isolation but rather as part of a class.chapter 14 : Testing Tactics14.1 Software Testing FundamentalsTestability: Characteristics of testable software inc

44、lude : Operability, Observability , Controllability, Decomposability, Simplicity, Stability, UnderstandabilityTest characteristics: ?14.3 White-Box Testing White-box testing, sometimes called glass-box testing, is a test case design philosophy that uses the control structure described as part of com

45、ponent-level design to derive test cases. Using white-box methods, the software engineer can derive test cases that (1)guarantee that all independent paths within a module have been exercised at least once, (2) exercise all logical decisions on their true and false sides, (3)execute all loops at the

46、ir boundaries and within their operational bounds, and (4)exercise internal data structures to ensure their validity.14.6 Black-Box TestingBlack-box testing attempts to find errors in the following categories : (a) incorrect or missing functions.(b) interface errors.(c) errors in data structures or

47、external data base access.(d) behavior or performance errors.(e) initialization and termination errors. Equivalence PartitioningEquivalence partitioning is a black-box testing method that divides the input domain of a program into classes of data from which test cases can be derived.from each equiva

48、lence classes, test cases for each input domain data object can be developed and executed14.7 Object-Oriented Testing Method Applicability of Conventional Test Case Design MethodsUse-cases can provide useful input in the design of black-box and state-based tests. Scenario-Based TestingScenario-based

49、 testing concentrates on what the user does, not what the product does. This means capturing the tasks(via use-case) that the user has to perform, then applying them and their variants as tests.14.10 Testing for Specialized Environments, Architectures, and Application Testing GUIs Testing of Client/

50、Server ArchitecturesThe following testing approaches are commonly encountered for client/server application(a) application function tests(b) server tests(c) database tests(d) transaction tests(e) network communication testchapter 16 Web Engineering16.1 Attributes of Web-Based Systems and ApplicationsThe following attributes are encountered in the vast majority of WebApps:(a) network intensiveness.(b) concurrency(c) unpredictable load(d) performance(e)