Software Engineering Body of Knowledge (v3) (2014) (811503), страница 44
Текст из файла (страница 44)
The discussion guidesthe reader through a summary of heuristicmethods, formal methods, prototyping, andagile methods.INTRODUCTIONSoftware engineering models and methodsimpose structure on software engineering withthe goal of making that activity systematic,repeatable, and ultimately more success-oriented.Using models provides an approach to problemsolving, a notation, and procedures for modelconstruction and analysis. Methods provide anapproach to the systematic specification, design,construction, test, and verification of the end-itemsoftware and associated work products.Software engineering models and methodsvary widely in scope—from addressing a singlesoftware life cycle phase to covering the complete software life cycle.
The emphasis in thisknowledge area (KA) is on software engineering models and methods that encompass multiplesoftware life cycle phases, since methods specificfor single life cycle phases are covered by otherKAs.The breakdown of topics for the SoftwareEngineering Models and Methods KA is shownin Figure 9.1.1. ModelingModeling of software is becoming a pervasivetechnique to help software engineers understand,9-19-2 SWEBOK® Guide V3.0Figure 9.1.
Breakdown of Topics for the Software Engineering Models and Methods KAengineer, and communicate aspects of the software to appropriate stakeholders. Stakeholdersare those persons or parties who have a statedor implied interest in the software (for example,user, buyer, supplier, architect, certifying authority, evaluator, developer, software engineer, andperhaps others).While there are many modeling languages,notations, techniques, and tools in the literatureand in practice, there are unifying general concepts that apply in some form to them all. Thefollowing sections provide background on thesegeneral concepts.1.1. Modeling Principles[1*, c2s2, c5s1, c5s2] [2*, c2s2] [3*, c5s0]Modeling provides the software engineer withan organized and systematic approach for representing significant aspects of the software understudy, facilitating decision-making about the software or elements of it, and communicating thosesignificant decisions to others in the stakeholdercommunities.
There are three general principlesguiding such modeling activities:• Model the Essentials: good models do notusually represent every aspect or feature ofthe software under every possible condition.Modeling typically involves developing onlythose aspects or features of the software thatneed specific answers, abstracting away anynonessential information. This approachkeeps the models manageable and useful.• Provide Perspective: modeling providesviews of the software under study usinga defined set of rules for expression of themodel within each view.
This perspectivedriven approach provides dimensionality tothe model (for example, a structural view,behavioral view, temporal view, organizational view, and other views as relevant).Organizing information into views focusesthe software modeling efforts on specificSoftware Engineering Models and Methods 9-3concerns relevant to that view using theappropriate notation, vocabulary, methods,and tools.• Enable Effective Communications: modelingemploys the application domain vocabularyof the software, a modeling language, andsemantic expression (in other words, meaning within context). When used rigorouslyand systematically, this modeling results ina reporting approach that facilitates effectivecommunication of software information toproject stakeholders.A model is an abstraction or simplification ofa software component.
A consequence of usingabstraction is that no single abstraction completely describes a software component. Rather,the model of the software is represented as anaggregation of abstractions, which—when takentogether—describe only selected aspects, perspectives, or views—only those that are neededto make informed decisions and respond to thereasons for creating the model in the first place.This simplification leads to a set of assumptionsabout the context within which the model isplaced that should also be captured in the model.Then, when reusing the model, these assumptionscan be validated first to establish the relevancy ofthe reused model within its new use and context.1.2. Properties and Expression of Models[1*, c5s2, c5s3] [3*, c4s1.1p7, c4s6p3,c5s0p3]Properties of models are those distinguishing features of a particular model used to characterizeits completeness, consistency, and correctnesswithin the chosen modeling notation and toolingused.
Properties of models include the following:• Completeness: the degree to which allrequirements have been implemented andverified within the model.• Consistency: the degree to which the modelcontains no conflicting requirements, assertions, constraints, functions, or componentdescriptions.• Correctness: the degree to which the modelsatisfies its requirements and design specifications and is free of defects.Models are constructed to represent real-worldobjects and their behaviors to answer specificquestions about how the software is expectedto operate.
Interrogating the models—eitherthrough exploration, simulation, or review—mayexpose areas of uncertainty within the model andthe software to which the model refers. Theseuncertainties or unanswered questions regardingthe requirements, design, and/or implementationcan then be handled appropriately.The primary expression element of a model isan entity. An entity may represent concrete artifacts (for example, processors, sensors, or robots)or abstract artifacts (for example, software modules or communication protocols). Model entities are connected to other entities using relations (in other words, lines or textual operatorson target entities). Expression of model entitiesmay be accomplished using textual or graphicalmodeling languages; both modeling languagetypes connect model entities through specific language constructs.
The meaning of an entity maybe represented by its shape, textual attributes, orboth. Generally, textual information adheres tolanguage-specific syntactic structure. The precise meanings related to the modeling of context,structure, or behavior using these entities andrelations is dependent on the modeling languageused, the design rigor applied to the modelingeffort, the specific view being constructed, andthe entity to which the specific notation elementmay be attached. Multiple views of the modelmay be required to capture the needed semanticsof the software.When using models supported with automation, models may be checked for completenessand consistency.
The usefulness of these checksdepends greatly on the level of semantic and syntactic rigor applied to the modeling effort in addition to explicit tool support. Correctness is typically checked through simulation and/or review.1.3. Syntax, Semantics, and Pragmatics[2* c2s2.2.2p6] [3*, c5s0]Models can be surprisingly deceptive.
The factthat a model is an abstraction with missing information can lead one into a false sense of completely understanding the software from a singlemodel. A complete model (“complete” being9-4 SWEBOK® Guide V3.0relative to the modeling effort) may be a unionof multiple submodels and any special functionmodels.
Examination and decision-making relative to a single model within this collection ofsubmodels may be problematic.Understanding the precise meanings of modeling constructs can also be difficult. Modelinglanguages are defined by syntactic and semanticrules. For textual languages, syntax is definedusing a notation grammar that defines valid language constructs (for example, Backus-NaurForm (BNF)).
For graphical languages, syntax isdefined using graphical models called metamodels. As with BNF, metamodels define the validsyntactical constructs of a graphical modelinglanguage; the metamodel defines how these constructs can be composed to produce valid models.Semantics for modeling languages specify themeaning attached to the entities and relationscaptured within the model.
For example, a simplediagram of two boxes connected by a line is opento a variety of interpretations. Knowing that thediagram on which the boxes are placed and connected is an object diagram or an activity diagramcan assist in the interpretation of this model.As a practical matter, there is usually a goodunderstanding of the semantics of a specificsoftware model due to the modeling languageselected, how that modeling language is used toexpress entities and relations within that model,the experience base of the modeler(s), and thecontext within which the modeling has beenundertaken and so represented.
Meaning is communicated through the model even in the presenceof incomplete information through abstraction;pragmatics explains how meaning is embodiedin the model and its context and communicatedeffectively to other software engineers.There are still instances, however, where caution is needed regarding modeling and semantics.For example, any model parts imported fromanother model or library must be examined forsemantic assumptions that conflict in the newmodeling environment; this may not be obvious.The model should be checked for documentedassumptions. While modeling syntax may beidentical, the model may mean something quitedifferent in the new environment, which is a different context. Also, consider that as softwarematures and changes are made, semantic discordcan be introduced, leading to errors.
With manysoftware engineers working on a model part overtime coupled with tool updates and perhaps newrequirements, there are opportunities for portionsof the model to represent something differentfrom the original author’s intent and initial modelcontext.1.4. Preconditions, Postconditions, andInvariants[2*, c4s4] [4*, c10s4p2, c10s5p2p4]When modeling functions or methods, the software engineer typically starts with a set ofassumptions about the state of the software priorto, during, and after the function or method executes.
These assumptions are essential to the correct operation of the function or method and aregrouped, for discussion, as a set of preconditions,postconditions, and invariants.• Preconditions: a set of conditions that mustbe satisfied prior to execution of the functionor method. If these preconditions do not holdprior to execution of the function or method,the function or method may produce erroneous results.• Postconditions: a set of conditions that isguaranteed to be true after the function ormethod has executed successfully. Typically,the postconditions represent how the stateof the software has changed, how parameters passed to the function or method havechanged, how data values have changed, orhow the return value has been affected.• Invariants: a set of conditions within theoperational environment that persist (inother words, do not change) before and afterexecution of the function or method.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
