软件工程基本名词

Software engineering is a discipline whose aim is the production of fault-free, delivered on time and within budget, that satisfies the client’s needs. Furthermore, the software must be easy to modify when the user’s needs change.Life-cycle model: The steps (phases) to follow when building software.It is a theoretical description of what should be done.Life cycle: The actual steps performed on a specific product.Maintenance is the process that occurs when a software artifact is modified because of a problem or because of a need for improvement or adaptation.Verification: Determine if the workflow was completed correctlyValidation: Determine if the product as a whole satisfies its requirementsObject: A software component that incorporates both data and the actions that are performed on that dataBaseline:a complete set of artifactsMoving Target Problem: A change in the requirements while the software product is being developedRegression fault: A fault in an apparently unrelated part of the software because of a change made to a software productMiller’s Law: At any one time, we can concentrate on only approximately seven chunks (units of information)Stepwise refinement:Concentrate on the aspects that are currently the most importantPostpone aspects that are currently less criticalEvery aspect is eventually handled, but in order of current importanceArchitecture: the various component modules of a product and how they fit togetherRobustness of the architecture: the property of being able to handle extensions and changes without falling apartBrooks’s Law: Adding additional programming personnel to a team when a product is late has the effect of making the product even laterSoftware Quality: The extent to which software satisfies its specificationsUtility: The extent to which the product meets the user’s needsReliability: A measure of the frequency and criticality of failurePerformance: The extent to which space and time constraints are metCorrectness: A product is correct if it satisfies its specificationsModule: A lexically contiguous sequence of program statements, bounded by boundary elements, with an aggregate identifierCohesion: The degree of interaction within a moduleCoincidental Cohesion: A module has coincidental cohesion if it performs multiple, completely unrelated actionsLogical Cohesion: A module has logical cohesion when it performs a series of related actions, one of which is selected by the calling moduleTemporal Cohesion: A module has temporal cohesion when it performs a series of actions related in timeProcedural Cohesion: A module has procedural cohesion if it performs a series of actions related by the procedure to be followed by the productCommunicational Cohesion: A module has communicational cohesion if it performs a series of actions related by the procedure to be followed by the product, but in addition all the actions operate on the same dataFunctional Cohesion: A module with functional cohesion performs exactly one actionInformational Cohesion:A module has informational cohesion if it performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structureCoupling: The degree of interaction between two modulesContent Coupling: Two modules are content coupled if one directly references contents of the otherCommon Coupling: Two modules are common coupled if they have write access to global dataControl Coupling: Two modules are control coupled if one passes an element of control to the otherStamp Coupling: Two modules are stamp coupled if a data structure is passed as a parameter, but the called module operates on some but not all of the individual components of the data structureData Coupling: Two modules are data coupled if all parameters are homogeneous data items (simple parameters, or data structures all of whose elements are used by called module)Application domain ( domain):The specific environment in which the target product is to operateRequirements elicitation (or requirements capture): Discovering the client’s requirementsRequirements analysis: Refining and extending the initial requirementsGlossary: A list of technical words used in the domain, and their meaningsbusiness model:A business model is a description of the business processes of an organization.The business model gives an understanding of the client’s business as a whole.use case:A use case models an interaction between the software product itself and the users of that software product (actors)functional requirement :A functional requirement specifies an action that the software product must be able to perform, Often expressed in terms of inputs and outputsA nonfunctional requirement specifies properties of the software product itself, such as platform constraints, response times,reliabilityEntity class: models long-lived informationBoundary class: models the interaction between the product and the environmentControl class: models complex computations and algorithmsFunctional modeling: present scenarios of all the use casesEntity Class modeling: determine the entity classes and their attributes, present this information in the form of a class diagramDynamic modeling: determine the operations performed by or to each entity class, present this information in the form of a statechartscenario: a scenario is an instance of a use caseCRC Card: For each class, fill in a card showing the name of Class, functionality (Responsibility),list of classes it invokes (Collaboration)use-case realization:The process of extending and refining use casesUML is an acronym for Unified Modeling Language.A class diagram depicts classes and their interrelationshipsAggregation is the UML term for the part–whole relationshipMultiplicity: The number of times that the one class is associated with the other classComposition: It is an instance of composition, a stronger form of position also models the part–whole relationship but, in addition,every part may belong to only one whole, and if the whole is deleted, so are the partsA use-case diagram is a single diagram that incorporates a number of use casesA class diagram is a model of the classes showing the static relationships between themA statechart shows states (specific values of attributes of objects), events that cause transitions between states (subject to guards), and actions taken by objectsAn interaction diagram (sequence diagram or collaboration diagram) shows how objects interact as messages are passed between themAn activity diagram shows how events that occur at the same time are coordinatedA component diagram shows dependencies among software componentsA deployment diagram shows on which hardware component each software component is installed (or deployed)Pseudocode (PDL — program design language)Top-down Integration: If code artifact mAbove sends a message to artifact mBelow, then mAbove is implemented and integrated before mBelowBottom-up Integration: If code artifact mAbove calls code artifact mBelow, then mBelow is implemented and integrated before mAboveSandwich Integration: Logic artifacts are integrated top-down. Operational artifacts are integrated bottom-up. Finally, the interfaces between the two groups are tested.Test to specifications (also called black-box, data-driven, functional, or input/output driven testing):Ignore the code —use the specifications to select test casesTest to code (also called glass-box, logic-driven, structured, or path-oriented testing):Ignore the specifications —use the code to select test casesAny one member of an equivalence class is as good a test case as any other member of the equivalence classBoundary Value Analysis: Select test cases on or just to one side of the boundary of equivalence classes.This greatly increases the probability of detecting a fault.Statement coverage: Running a set of test cases in which every statement is executed at least onceBranch Coverage/ Decision Coverage: Running a set of test cases in which every branch is executed at least onceCondition Coverage: Running a set of test cases in which true and false of every condition is executed at least onceDecision/Condition Coverage: Running a set of test cases in which every branch is executed at least once and true and false of every condition is executed at least onceMultijob Coverage/ Condition Combination Coverage: Running a set of test cases in which every condition combination of every decision is executed at least oncePath Coverage: Running a set of test cases in which every path is executed at least onceCyclomatic complexity M (McCabe): The number of binary decisions plus 1Postdelivery maintenance: Any change to any component of the product (including documentation) after it has passed the acceptance testCorrective maintenance: To correct residual faults of analysis, design, implementation, documentation, or any other type of faultsPerfective maintenance: Client requests changes to improve product effectivenessAdaptive maintenance: Responses to changes in the environment in which the product operates。