Software Engineering Body of Knowledge (v3) (2014) (811503), страница 45
Текст из файла (страница 45)
Theseinvariants are relevant and necessary to thesoftware and the correct operation of thefunction or method.2. Types of ModelsA typical model consists of an aggregation ofsubmodels. Each submodel is a partial description and is created for a specific purpose; it maybe comprised of one or more diagrams. Thecollection of submodels may employ multipleSoftware Engineering Models and Methods 9-5modeling languages or a single modeling language. The Unified Modeling Language (UML)recognizes a rich collection of modeling diagrams.
Use of these diagrams, along with themodeling language constructs, brings about threebroad model types commonly used: informationmodels, behavioral models, and structure models(see section 1.1).2.1. Information Modeling[1*, c7s2.2] [3*, c8s1]Information models provide a central focus ondata and information. An information model is anabstract representation that identifies and definesa set of concepts, properties, relations, and constraints on data entities.
The semantic or conceptual information model is often used to providesome formalism and context to the software beingmodeled as viewed from the problem perspective,without concern for how this model is actuallymapped to the implementation of the software.The semantic or conceptual information modelis an abstraction and, as such, includes only theconcepts, properties, relations, and constraintsneeded to conceptualize the real-world view ofthe information. Subsequent transformations ofthe semantic or conceptual information modellead to the elaboration of logical and then physical data models as implemented in the software.2.2. Behavioral Modeling[1*, c7s2.1, c7s2.3, c7s2.4] [2*, c9s2][3*, c5s4]Behavioral models identify and define the functions of the software being modeled.
Behavioral models generally take three basic forms:state machines, control-flow models, and dataflow models. State machines provide a modelof the software as a collection of defined states,events, and transitions. The software transitionsfrom one state to the next by way of a guardedor unguarded triggering event that occurs in themodeled environment. Control-flow modelsdepict how a sequence of events causes processesto be activated or deactivated. Data-flow behavior is typified as a sequence of steps where datamoves through processes toward data stores ordata sinks.2.3. Structure Modeling[1*, c7s2.5, c7s3.1, c7s3.2] [3*, c5s3] [4*, c4]Structure models illustrate the physical or logicalcomposition of software from its various component parts.
Structure modeling establishes thedefined boundary between the software beingimplemented or modeled and the environmentin which it is to operate. Some common structural constructs used in structure modeling arecomposition, decomposition, generalization, andspecialization of entities; identification of relevant relations and cardinality between entities;and the definition of process or functional interfaces.
Structure diagrams provided by the UMLfor structure modeling include class, component,object, deployment, and packaging diagrams.3. Analysis of ModelsThe development of models affords the softwareengineer an opportunity to study, reason about,and understand the structure, function, operational usage, and assembly considerations associated with software. Analysis of constructedmodels is needed to ensure that these models arecomplete, consistent, and correct enough to servetheir intended purpose for the stakeholders.The sections that follow briefly describe theanalysis techniques generally used with software models to ensure that the software engineerand other relevant stakeholders gain appropriatevalue from the development and use of models.3.1. Analyzing for Completeness[3*, c4s1.1p7, c4s6] [5*, p8–11]In order to have software that fully meets the needsof the stakeholders, completeness is critical—fromthe requirements elicitation process to code implementation.
Completeness is the degree to whichall of the specified requirements have been implemented and verified. Models may be checked forcompleteness by a modeling tool that uses techniques such as structural analysis and state-spacereachability analysis (which ensure that all paths inthe state models are reached by some set of correctinputs); models may also be checked for completeness manually by using inspections or other reviewtechniques (see the Software Quality KA). Errors9-6 SWEBOK® Guide V3.0and warnings generated by these analysis tools andfound by inspection or review indicate probableneeded corrective actions to ensure completenessof the models.3.2. Analyzing for Consistency[3*, c4s1.1p7, c4s6] [5*, p8–11]Consistency is the degree to which models contain no conflicting requirements, assertions, constraints, functions, or component descriptions.Typically, consistency checking is accomplishedwith the modeling tool using an automated analysisfunction; models may also be checked for consistency manually using inspections or other reviewtechniques (see the Software Quality KA).
Aswith completeness, errors and warnings generatedby these analysis tools and found by inspection orreview indicate the need for corrective action.3.3. Analyzing for Correctness[5*, p8–11]Correctness is the degree to which a model satisfies its software requirements and softwaredesign specifications, is free of defects, and ultimately meets the stakeholders’ needs. Analyzingfor correctness includes verifying syntactic correctness of the model (that is, correct use of themodeling language grammar and constructs) andverifying semantic correctness of the model (thatis, use of the modeling language constructs tocorrectly represent the meaning of that which isbeing modeled).
To analyze a model for syntacticand semantic correctness, one analyzes it—eitherautomatically (for example, using the modelingtool to check for model syntactic correctness)or manually (using inspections or other reviewtechniques)—searching for possible defects andthen removing or repairing the confirmed defectsbefore the software is released for use.3.4. Traceability[3*, c4s7.1, c4s7.2]Developing software typically involves the use,creation, and modification of many work productssuch as planning documents, process specifications, software requirements, diagrams, designsand pseudo-code, handwritten and tool-generatedcode, manual and automated test cases and reports,and files and data.
These work products may berelated through various dependency relationships(for example, uses, implements, and tests). As software is being developed, managed, maintained, orextended, there is a need to map and control thesetraceability relationships to demonstrate software requirements consistency with the softwaremodel (see Requirements Tracing in the SoftwareRequirements KA) and the many work products.Use of traceability typically improves the management of software work products and software process quality; it also provides assurances to stakeholders that all requirements have been satisfied.Traceability enables change analysis once the software is developed and released, since relationshipsto software work products can easily be traversedto assess change impact.
Modeling tools typicallyprovide some automated or manual means to specify and manage traceability links between requirements, design, code, and/or test entities as may berepresented in the models and other software workproducts. (For more information on traceability,see the Software Configuration Management KA).3.5. Interaction Analysis[2*, c10, c11] [3*, c29s1.1, c29s5] [4*, c5]Interaction analysis focuses on the communications or control flow relations between entitiesused to accomplish a specific task or functionwithin the software model. This analysis examines the dynamic behavior of the interactionsbetween different portions of the software model,including other software layers (such as the operating system, middleware, and applications).
Itmay also be important for some software applications to examine interactions between the computer software application and the user interfacesoftware. Some software modeling environmentsprovide simulation facilities to study aspects ofthe dynamic behavior of modeled software. Stepping through the simulation provides an analysisoption for the software engineer to review theinteraction design and verify that the differentparts of the software work together to provide theintended functions.Software Engineering Models and Methods 9-74. Software Engineering MethodsSoftware engineering methods provide an organized and systematic approach to developing software for a target computer.
There are numerousmethods from which to choose, and it is importantfor the software engineer to choose an appropriatemethod or methods for the software developmenttask at hand; this choice can have a dramatic effecton the success of the software project. Use of thesesoftware engineering methods coupled with peopleof the right skill set and tools enable the softwareengineers to visualize the details of the softwareand ultimately transform the representation into aworking set of code and data.Selected software engineering methods are discussed below.
The topic areas are organized intodiscussions of Heuristic Methods, Formal Methods, Prototyping Methods, and Agile Methods.4.1. Heuristic Methods[1*, c13, c15, c16] [3*, c2s2.2, c5s4.1, c7s1,]Heuristic methods are those experience-basedsoftware engineering methods that have been andare fairly widely practiced in the software industry. This topic area contains three broad discussion categories: structured analysis and designmethods, data modeling methods, and objectoriented analysis and design methods.• Structured Analysis and Design Methods:The software model is developed primarilyfrom a functional or behavioral viewpoint,starting from a high-level view of the software (including data and control elements)and then progressively decomposing or refining the model components through increasingly detailed designs. The detailed designeventually converges to very specific detailsor specifications of the software that must becoded (by hand, automatically generated, orboth), built, tested, and verified.• Data Modeling Methods: The data model isconstructed from the viewpoint of the data orinformation used.
Data tables and relationships define the data models. This data modeling method is used primarily for definingand analyzing data requirements supportingdatabase designs or data repositories typically found in business software, where datais actively managed as a business systemsresource or asset.• Object-Oriented Analysis and Design Methods: The object-oriented model is representedas a collection of objects that encapsulatedata and relationships and interact with otherobjects through methods.
Objects may bereal-world items or virtual items. The software model is constructed using diagramsto constitute selected views of the software.Progressive refinement of the software models leads to a detailed design. The detaileddesign is then either evolved through successive iteration or transformed (using somemechanism) into the implementation viewof the model, where the code and packaging approach for eventual software productrelease and deployment is expressed.4.2. Formal Methods[1*, c18] [3*, c27] [5*, p8–24]Formal methods are software engineering methods used to specify, develop, and verify the software through application of a rigorous mathematically based notation and language. Through useof a specification language, the software modelcan be checked for consistency (in other words,lack of ambiguity), completeness, and correctnessin a systematic and automated or semi-automatedfashion.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
