Software Engineering Body of Knowledge (v3) (2014) (811503), страница 14
Текст из файла (страница 14)
(See also the SoftwareQuality KA.)5.1. Quality Attributes[4*, c4]Various attributes contribute to the quality ofa software design, including various “-ilities”(maintainability, portability, testability, usability)2-8 SWEBOK® Guide V3.0and “-nesses” (correctness, robustness). There isan interesting distinction between quality attributes discernible at runtime (for example, performance, security, availability, functionality,usability), those not discernible at runtime (forexample, modifiability, portability, reusability,testability), and those related to the architecture’sintrinsic qualities (for example, conceptual integrity, correctness, completeness). (See also theSoftware Quality KA.)5.2. Quality Analysis and Evaluation Techniques[4*, c4] [5*, c24]Various tools and techniques can help in analyzing and evaluating software design quality.• Software design reviews: informal and formalized techniques to determine the qualityof design artifacts (for example, architecturereviews, design reviews, and inspections;scenario-based techniques; requirementstracing).
Software design reviews can alsoevaluate security. Aids for installation, operation, and usage (for example, manuals andhelp files) can be reviewed.• Static analysis: formal or semiformal static(nonexecutable) analysis that can be usedto evaluate a design (for example, faulttree analysis or automated cross-checking).Design vulnerability analysis (for example,static analysis for security weaknesses) canbe performed if security is a concern. Formaldesign analysis uses mathematical modelsthat allow designers to predicate the behaviorand validate the performance of the softwareinstead of having to rely entirely on testing.Formal design analysis can be used to detectresidual specification and design errors (perhaps caused by imprecision, ambiguity, andsometimes other kinds of mistakes).
(Seealso the Software Engineering Models andMethods KA.)• Simulation and prototyping: dynamic techniques to evaluate a design (for example,performance simulation or feasibilityprototypes).5.3. Measures[4*, c4] [5*, c24]Measures can be used to assess or to quantitatively estimate various aspects of a softwaredesign; for example, size, structure, or quality.Most measures that have been proposed dependon the approach used for producing the design.These measures are classified in two broadcategories:• Function-based (structured) design measures: measures obtained by analyzing functional decomposition; generally representedusing a structure chart (sometimes called ahierarchical diagram) on which various measures can be computed.• Object-oriented design measures: the designstructure is typically represented as a classdiagram, on which various measures can becomputed.
Measures on the properties of theinternal content of each class can also becomputed.6. Software Design NotationsMany notations exist to represent software designartifacts. Some are used to describe the structuralorganization of a design, others to represent software behavior. Certain notations are used mostlyduring architectural design and others mainlyduring detailed design, although some notations can be used for both purposes. In addition,some notations are used mostly in the context ofspecific design methods (see topic 7, SoftwareDesign Strategies and Methods).
Please note thatsoftware design is often accomplished using multiple notations. Here, they are categorized intonotations for describing the structural (static)view vs. the behavioral (dynamic) view.6.1. Structural Descriptions (Static View)[4*, c7] [5*, c6, c7] [6*, c4, c5, c6, c7][12*, c7] [14*, c7]The following notations, mostly but not alwaysgraphical, describe and represent the structuralaspects of a software design—that is, they areSoftware Design 2-9used to describe the major components and howthey are interconnected (static view):• Architecture description languages (ADLs):textual, often formal, languages used todescribe software architecture in terms ofcomponents and connectors.• Class and object diagrams: used to represent a set of classes (and objects) and theirinterrelationships.• Component diagrams: used to represent aset of components (“physical and replaceable part[s] of a system that [conform] toand [provide] the realization of a set of interfaces” [18]) and their interrelationships.• Class responsibility collaborator cards(CRCs): used to denote the names of components (class), their responsibilities, and theircollaborating components’ names.• Deployment diagrams: used to represent aset of (physical) nodes and their interrelationships, and, thus, to model the physicalaspects of software.• Entity-relationship diagrams (ERDs): usedto represent conceptual models of data storedin information repositories.• Interface description languages (IDLs):programming-like languages used to definethe interfaces (names and types of exportedoperations) of software components.• Structure charts: used to describe the callingstructure of programs (which modules call,and are called by, which other modules).6.2. Behavioral Descriptions (Dynamic View)[4*, c7, c13] [5*, c6, c7] [6*, c4, c5, c6, c7][14*, c8]The following notations and languages, somegraphical and some textual, are used to describethe dynamic behavior of software systems andcomponents.
Many of these notations are useful mostly, but not exclusively, during detaileddesign. Moreover, behavioral descriptions caninclude a rationale for design decision such ashow a design will meet security requirements.• Activity diagrams: used to show control flowfrom activity to activity. Can be used to represent concurrent activities.• Communication diagrams: used to showthe interactions that occur among a groupof objects; emphasis is on the objects, theirlinks, and the messages they exchange onthose links.• Data flow diagrams (DFDs): used to showdata flow among elements. A data flow diagram provides “a description based on modeling the flow of information around a networkof operational elements, with each elementmaking use of or modifying the informationflowing into that element” [4*]. Data flows(and therefore data flow diagrams) can beused for security analysis, as they offer identification of possible paths for attack and disclosure of confidential information.• Decision tables and diagrams: used to represent complex combinations of conditionsand actions.• Flowcharts: used to represent the flow ofcontrol and the associated actions to beperformed.• Sequence diagrams: used to show the interactions among a group of objects, withemphasis on the time ordering of messagespassed between objects.• State transition and state chart diagrams:used to show the control flow from state tostate and how the behavior of a componentchanges based on its current state in a statemachine.• Formal specification languages: textual languages that use basic notions from mathematics (for example, logic, set, sequence)to rigorously and abstractly define softwarecomponent interfaces and behavior, often interms of pre- and postconditions.
(See alsothe Software Engineering Models and Methods KA.)• Pseudo code and program design languages(PDLs): structured programming-like languages used to describe, generally at thedetailed design stage, the behavior of a procedure or method.2-10 SWEBOK® Guide V3.07. Software Design Strategies and MethodsThere exist various general strategies to helpguide the design process. In contrast with generalstrategies, methods are more specific in that theygenerally provide a set of notations to be usedwith the method, a description of the process tobe used when following the method, and a set ofguidelines for using the method.
Such methodsare useful as a common framework for teams ofsoftware engineers. (See also the Software Engineering Models and Methods KA).7.1. General Strategies[4*, c8, c9, c10] [12*, c7]Some often-cited examples of general strategiesuseful in the design process include the divideand-conquer and stepwise refinement strategies,top-down vs. bottom-up strategies, and strategiesmaking use of heuristics, use of patterns and pattern languages, and use of an iterative and incremental approach.7.2. Function-Oriented (Structured) Design[4*, c13]This is one of the classical methods of softwaredesign, where decomposition centers on identifying the major software functions and then elaborating and refining them in a hierarchical topdown manner.
Structured design is generally usedafter structured analysis, thus producing (amongother things) data flow diagrams and associatedprocess descriptions. Researchers have proposedvarious strategies (for example, transformationanalysis, transaction analysis) and heuristics (forexample, fan-in/fan-out, scope of effect vs. scopeof control) to transform a DFD into a softwarearchitecture generally represented as a structurechart.7.3. Object-Oriented Design[4*, c16]Numerous software design methods basedon objects have been proposed.
The field hasevolved from the early object-oriented (OO)design of the mid-1980s (noun = object; verb= method; adjective = attribute), where inheritance and polymorphism play a key role, to thefield of component-based design, where metainformation can be defined and accessed (throughreflection, for example). Although OO design’sroots stem from the concept of data abstraction,responsibility-driven design has been proposedas an alternative approach to OO design.7.4. Data Structure-Centered Design[4*, c14, c15]Data structure-centered design starts from the datastructures a program manipulates rather than fromthe function it performs. The software engineerfirst describes the input and output data structuresand then develops the program’s control structurebased on these data structure diagrams.
Variousheuristics have been proposed to deal with specialcases—for example, when there is a mismatchbetween the input and output structures.7.5. Component-Based Design (CBD)[4*, c17]A software component is an independent unit,having well-defined interfaces and dependencies that can be composed and deployed independently. Component-based design addressesissues related to providing, developing, andintegrating such components in order to improvereuse. Reused and off-the-shelf software components should meet the same security requirements as new software. Trust management isa design concern; components treated as having a certain degree of trustworthiness shouldnot depend on less trustworthy components orservices.7.6. Other Methods[5*, c19, c21]Other interesting approaches also exist (see theSoftware Engineering Models and MethodsKA). Iterative and adaptive methods implement software increments and reduce emphasison rigorous software requirement and design.Software Design 2-11Aspect-oriented design is a method by whichsoftware is constructed using aspects to implement the crosscutting concerns and extensionsthat are identified during the software requirements process.
Service-oriented architecture isa way to build distributed software using webservices executed on distributed computers. Software systems are often constructed by using services from different providers because standardprotocols (such as HTTP, HTTPS, SOAP) havebeen designed to support service communicationand service information exchange.8. Software Design Tools[14*, c10, Appendix A]Software design tools can be used to support thecreation of the software design artifacts duringthe software development process.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
