Software Engineering Body of Knowledge (v3) (2014) (811503), страница 12
Текст из файла (страница 12)
Breakdown of Topics for the Software Design KAConstruction, Software Engineering Management, Software Engineering Models and Methods, Software Quality, and Computing Foundations KAs.BREAKDOWN OF TOPICS FORSOFTWARE DESIGNThe breakdown of topics for the Software DesignKA is shown in Figure 2.1.1. Software Design FundamentalsThe concepts, notions, and terminology introduced here form an underlying basis for understanding the role and scope of software design.1.1. General Design Concepts[4*, c1]In the general sense, design can be viewed as aform of problem solving. For example, the concept of a wicked problem—a problem with nodefinitive solution—is interesting in terms ofunderstanding the limits of design. A number ofother notions and concepts are also of interest inunderstanding design in its general sense: goals,constraints, alternatives, representations, andsolutions (see Problem Solving Techniques in theComputing Foundations KA).1.2. Context of Software Design[4*, c3]Software design is an important part of the software development process.
To understand therole of software design, we must see how it fitsin the software development life cycle. Thus, itis important to understand the major characteristics of software requirements analysis, softwaredesign, software construction, software testing,and software maintenance.1.3. Software Design Process[4*, c2]Software design is generally considered a twostep process:Software Design 2-3• Architectural design (also referred to as highlevel design and top-level design) describeshow software is organized into components.• Detailed design describes the desired behavior of these components.The output of these two processes is a set ofmodels and artifacts that record the major decisions that have been taken, along with an explanation of the rationale for each nontrivial decision.By recording the rationale, long-term maintainability of the software product is enhanced.1.4. Software Design Principles[4*] [5*, c6, c7, c21] [6*, c1, c8, c9]A principle is “a comprehensive and fundamental law, doctrine, or assumption” [7].
Softwaredesign principles are key notions that providethe basis for many different software designapproaches and concepts. Software design principles include abstraction; coupling and cohesion;decomposition and modularization; encapsulation/information hiding; separation of interfaceand implementation; sufficiency, completeness,and primitiveness; and separation of concerns.• Abstraction is “a view of an object thatfocuses on the information relevant to aparticular purpose and ignores the remainder of the information” [1] (see Abstractionin the Computing Foundations KA). In thecontext of software design, two key abstraction mechanisms are parameterization andspecification.
Abstraction by parameterization abstracts from the details of data representations by representing the data as namedparameters. Abstraction by specificationleads to three major kinds of abstraction:procedural abstraction, data abstraction, andcontrol (iteration) abstraction.• Coupling and Cohesion. Coupling is definedas “a measure of the interdependence amongmodules in a computer program,” whereascohesion is defined as “a measure of thestrength of association of the elements withina module” [1].• Decomposition and modularization. Decomposing and modularizing means that largesoftware is divided into a number of smallernamed components having well-definedinterfaces that describe component interactions.
Usually the goal is to place differentfunctionalities and responsibilities in different components.• Encapsulation and information hiding meansgrouping and packaging the internal detailsof an abstraction and making those detailsinaccessible to external entities.• Separation of interface and implementation.Separating interface and implementationinvolves defining a component by specifying a public interface (known to the clients)that is separate from the details of how thecomponent is realized (see encapsulation andinformation hiding above).• Sufficiency, completeness, and primitiveness.Achieving sufficiency and completenessmeans ensuring that a software componentcaptures all the important characteristics ofan abstraction and nothing more. Primitiveness means the design should be based onpatterns that are easy to implement.• Separation of concerns.
A concern is an“area of interest with respect to a softwaredesign” [8]. A design concern is an area ofdesign that is relevant to one or more of itsstakeholders. Each architecture view framesone or more concerns. Separating concernsby views allows interested stakeholders tofocus on a few things at a time and offers ameans of managing complexity [9].2. Key Issues in Software DesignA number of key issues must be dealt with whendesigning software. Some are quality concernsthat all software must address—for example,performance, security, reliability, usability, etc.Another important issue is how to decompose,organize, and package software components.This is so fundamental that all design approachesaddress it in one way or another (see section 1.4,Software Design Principles, and topic 7, Software Design Strategies and Methods).
In contrast,other issues “deal with some aspect of software’sbehavior that is not in the application domain,but which addresses some of the supporting2-4 SWEBOK® Guide V3.0domains” [10]. Such issues, which often crosscutthe system’s functionality, have been referred toas aspects, which “tend not to be units of software’s functional decomposition, but rather to beproperties that affect the performance or semantics of the components in systemic ways” [11].A number of these key, crosscutting issues arediscussed in the following sections (presented inalphabetical order).2.1. Concurrency[5*, c18]Design for concurrency is concerned with decomposing software into processes, tasks, and threadsand dealing with related issues of efficiency,atomicity, synchronization, and scheduling.2.2. Control and Handling of Events[5*, c21]This design issue is concerned with how toorganize data and control flow as well as howto handle reactive and temporal events throughvarious mechanisms such as implicit invocationand call-backs.2.3. Data Persistence[12*, c9]This design issue is concerned with how to handle long-lived data.2.4. Distribution of Components[5*, c18]This design issue is concerned with how to distribute the software across the hardware (including computer hardware and network hardware),how the components communicate, and howmiddleware can be used to deal with heterogeneous software.2.5. Error and Exception Handling and FaultTolerance[5*, c18]This design issue is concerned with how to prevent, tolerate, and process errors and deal withexceptional conditions.2.6. Interaction and Presentation[5*, c16]This design issue is concerned with how to structure and organize interactions with users as wellas the presentation of information (for example,separation of presentation and business logicusing the Model-View-Controller approach).Note that this topic does not specify user interfacedetails, which is the task of user interface design(see topic 4, User Interface Design).2.7. Security[5*, c12, c18] [13*, c4]Design for security is concerned with how to prevent unauthorized disclosure, creation, change,deletion, or denial of access to information andother resources.
It is also concerned with how totolerate security-related attacks or violations bylimiting damage, continuing service, speedingrepair and recovery, and failing and recoveringsecurely. Access control is a fundamental concept of security, and one should also ensure theproper use of cryptology.3. Software Structure and ArchitectureIn its strict sense, a software architecture is“the set of structures needed to reason aboutthe system, which comprise software elements,relations among them, and properties of both”[14*]. During the mid-1990s, however, software architecture started to emerge as a broaderdiscipline that involved the study of softwarestructures and architectures in a more genericway. This gave rise to a number of interestingconcepts about software design at different levels of abstraction.
Some of these concepts canbe useful during the architectural design (forexample, architectural styles) as well as duringthe detailed design (for example, design patterns). These design concepts can also be usedto design families of programs (also known asproduct lines). Interestingly, most of these concepts can be seen as attempts to describe, andthus reuse, design knowledge.Software Design 2-53.1. Architectural Structures and Viewpoints[14*, c1]Different high-level facets of a software designcan be described and documented. These facetsare often called views: “A view represents a partialaspect of a software architecture that shows specific properties of a software system” [14*]. Viewspertain to distinct issues associated with softwaredesign—for example, the logical view (satisfyingthe functional requirements) vs. the process view(concurrency issues) vs.
the physical view (distribution issues) vs. the development view (how thedesign is broken down into implementation unitswith explicit representation of the dependenciesamong the units). Various authors use differentterminologies—like behavioral vs. functional vs.structural vs. data modeling views.
In summary, asoftware design is a multifaceted artifact producedby the design process and generally composed ofrelatively independent and orthogonal views.3.2. Architectural Styles[14*, c1, c2, c3, c4, c5]An architectural style is “a specialization of element and relation types, together with a set ofconstraints on how they can be used” [14*]. Anarchitectural style can thus be seen as providingthe software’s high-level organization. Variousauthors have identified a number of major architectural styles:• General structures (for example, layers, pipesand filters, blackboard)• Distributed systems (for example, clientserver, three-tiers, broker)• Interactive systems (for example, Model-ViewController, Presentation-Abstraction-Control)• Adaptable systems (for example, microkernel, reflection)• Others (for example, batch, interpreters, process control, rule-based).3.3. Design Patterns[15*, c3, c4, c5]Succinctly described, a pattern is “a commonsolution to a common problem in a given context”[16].
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
