Software Engineering Body of Knowledge (v3) (2014) (811503), страница 15
Текст из файла (страница 15)
They can support part or whole of the following activities:• to translate the requirements model into adesign representation;• to provide support for representing functional components and their interface(s);• to implement heuristics refinement andpartitioning;• to provide guidelines for quality assessment.2-12 SWEBOK® Guide V3.02.7. Security3. Software Structureand Architecture3.1. ArchitecturalStructures andViewpoints3.2. ArchitecturalStyles3.3. Design Patternsc1c3c2c1c18c21c9c18c18c16c12,c18c4c1c1, c2,c3, c4,c5c3, c4,c5Nielsen 1993[17*]Gamma et al.
1994[15*]Clements et al. 2010[14*]c1, c8,c9Allen 2008[13*]c6, c7,c21Brookshear 2008[12*]Page-Jones 1999[6*]1. Software DesignFundamentals1.1. General DesignConcepts1.2. The Context ofSoftware Design1.3. The SoftwareDesign Process1.4. Software DesignPrinciples2. Key Issues inSoftware Design2.1. Concurrency2.2. Control andHandling of Events2.3. Data Persistence2.4. Distribution ofComponents2.5. Error andException Handlingand Fault Tolerance2.6. Interaction andPresentationSommerville 2011[5*]Budgen 2003[4*]MATRIX OF TOPICS VS. REFERENCE MATERIAL3.4. ArchitectureDesign Decisions3.5. Families ofPrograms andFrameworks4. User InterfaceDesign4.1. General UserInterface DesignPrinciple4.2. User InterfaceDesign Issues4.3. The Design ofUser InteractionModalities4.4. The Designof InformationPresentation4.5. User InterfaceDesign Process4.6. Localization andInternationalization4.7. Metaphors andConceptual Models5. Software DesignQuality Analysis andEvaluation5.1. QualityAttributes5.2. QualityAnalysis andEvaluationTechniques5.3. MeasuresNielsen 1993[17*]Gamma et al.
1994[15*]Clements et al. 2010[14*]Allen 2008[13*]Brookshear 2008[12*]Page-Jones 1999[6*]Sommerville 2011[5*]Budgen 2003[4*]Software Design 2-13c6c6, c7,c16c29webc2c29webc29webc29webc29webc8, c9c5c4c4c24c4c247.6. Other Methods8. Software DesignToolsc6, c7c4, c5,c6, c7c7c8c7c19,c21c10,App. ANielsen 1993[17*]c7Gamma et al. 1994[15*]c4, c5,c6, c7Clements et al. 2010[14*]Brookshear 2008[12*]c6, c7Allen 2008[13*]Page-Jones 1999[6*]6. Software DesignNotations6.1. StructuralDescriptions (Staticc7View)6.2. Behavioralc7, c13,Descriptionsc18(Dynamic View)7. Software DesignStrategies andMethods7.1. Generalc8, c9,Strategiesc107.2. FunctionOrientedc13(Structured) Design7.3. Object-Orientedc16Design7.4. Data Structurec14,Centered Designc157.5. Componentc17Based Design (CBD)Sommerville 2011[5*]Budgen 2003[4*]2-14 SWEBOK® Guide V3.0Software Design 2-15FURTHER READINGSREFERENCESRoger Pressman, Software Engineering: APractitioner’s Approach (Seventh Edition)[19].[1] ISO/IEC/IEEE 24765:2010 Systems andSoftware Engineering—Vocabulary, ISO/IEC/IEEE, 2010.For roughly three decades, Roger Pressman’sSoftware Engineering: A Practitioner’s Approachhas been one of the world’s leading textbooks insoftware engineering.
Notably, this complementary textbook to [5*] comprehensively presentssoftware design—including design concepts,architectural design, component-level design,user interface design, pattern-based design, andweb application design.[2] IEEE Std. 12207-2008 (a.k.a. ISO/IEC12207:2008) Standard for Systems andSoftware Engineering—Software Life CycleProcesses, IEEE, 2008.“The 4+1 View Model of Architecture” [20].The seminal paper “The 4+1 View Model” organizes a description of a software architectureusing five concurrent views.
The four views ofthe model are the logical view, the developmentview, the process view, and the physical view.In addition, selected use cases or scenarios areutilized to illustrate the architecture. Hence, themodel contains 4+1 views. The views are used todescribe the software as envisioned by differentstakeholders—such as end-users, developers, andproject managers.Len Bass, Paul Clements, and Rick Kazman,Software Architecture in Practice [21].This book introduces the concepts and best practices of software architecture, meaning how software is structured and how the software’s components interact. Drawing on their own experience,the authors cover the essential technical topicsfor designing, specifying, and validating softwarearchitectures.
They also emphasize the importance of the business context in which large software is designed. Their aim is to present softwarearchitecture in a real-world setting, reflectingboth the opportunities and constraints that organizations encounter. This is one of the best bookscurrently available on software architecture.[3] T.
DeMarco, “The Paradox of SoftwareArchitecture and Design,” Stevens PrizeLecture, 1999.[4*] D. Budgen, Software Design, 2nd ed.,Addison-Wesley, 2003.[5*] I. Sommerville, Software Engineering, 9thed., Addison-Wesley, 2011.[6*] M. Page-Jones, Fundamentals of ObjectOriented Design in UML, 1st ed., AddisonWesley, 1999.[7] Merriam-Webster’s Collegiate Dictionary,11th ed., 2003.[8] IEEE Std. 1069-2009 Standard forInformation Technology—SystemsDesign—Software Design Descriptions,IEEE, 2009.[9] ISO/IEC 42010:2011 Systems and SoftwareEngineering—Recommended Practice forArchitectural Description of SoftwareIntensive Systems, ISO/IEC, 2011.[10] J.
Bosch, Design and Use of SoftwareArchitectures: Adopting and Evolving aProduct-Line Approach, ACM Press, 2000.[11] G. Kiczales et al., “Aspect-OrientedProgramming,” Proc. 11th European Conf.Object-Oriented Programming (ECOOP97), Springer, 1997.2-16 SWEBOK® Guide V3.0[12*] J.G. Brookshear, Computer Science: AnOverview, 10th ed., Addison-Wesley, 2008.[17*] J.
Nielsen, Usability Engineering, MorganKaufmann, 1993.[13*] J.H. Allen et al., Software SecurityEngineering: A Guide for ProjectManagers, Addison-Wesley, 2008.[18] G. Booch, J. Rumbaugh, and I. Jacobson,The Unified Modeling Language UserGuide, Addison-Wesley, 1999.[14*] P. Clements et al., Documenting SoftwareArchitectures: Views and Beyond, 2nd ed.,Pearson Education, 2010.[19] R.S. Pressman, Software Engineering: APractitioner’s Approach, 7th ed., McGrawHill, 2010.[15*] E. Gamma et al., Design Patterns:Elements of Reusable Object-OrientedSoftware, 1st ed., Addison-WesleyProfessional, 1994.[20] P.B. Kruchten, “The 4+1 View Model ofArchitecture,” IEEE Software, vol.
12, no.6, 1995, pp. 42–55.[16] I. Jacobson, G. Booch, and J. Rumbaugh,The Unified Software DevelopmentProcess, Addison-Wesley Professional,1999.[21] L. Bass, P. Clements, and R. Kazman,Software Architecture in Practice, 3rd ed.,Addison-Wesley Professional, 2013.CHAPTER 3SOFTWARE CONSTRUCTIONACRONYMSAPICOTSGUIIDEOMGPOSIXTDDUMLThus, the Software Construction KA is closelylinked to the Software Testing KA as well.Software construction typically produces thehighest number of configuration items that needto be managed in a software project (source files,documentation, test cases, and so on).
Thus, theSoftware Construction KA is also closely linkedto the Software Configuration Management KA.While software quality is important in all theKAs, code is the ultimate deliverable of a software project, and thus the Software Quality KA isclosely linked to the Software Construction KA.Since software construction requires knowledgeof algorithms and of coding practices, it is closelyrelated to the Computing Foundations KA, whichis concerned with the computer science foundations that support the design and construction ofsoftware products.
It is also related to project management, insofar as the management of construction can present considerable challenges.Application ProgrammingInterfaceCommercial Off-the-ShelfGraphical User InterfaceIntegrated DevelopmentEnvironmentObject Management GroupPortable Operating SystemInterfaceTest-Driven DevelopmentUnified Modeling LanguageINTRODUCTIONThe term software construction refers to thedetailed creation of working software through acombination of coding, verification, unit testing,integration testing, and debugging.The Software Construction knowledge area(KA) is linked to all the other KAs, but it is moststrongly linked to Software Design and SoftwareTesting because the software construction processinvolves significant software design and testing.The process uses the design output and provides aninput to testing (“design” and “testing” in this casereferring to the activities, not the KAs).
Boundaries between design, construction, and testing (ifany) will vary depending on the software life cycleprocesses that are used in a project.Although some detailed design may be performed prior to construction, much design workis performed during the construction activity.Thus, the Software Construction KA is closelylinked to the Software Design KA.Throughout construction, software engineersboth unit test and integration test their work.BREAKDOWN OF TOPICS FORSOFTWARE CONSTRUCTIONFigure 3.1 gives a graphical representation of thetop-level decomposition of the breakdown for theSoftware Construction KA.1. Software Construction FundamentalsSoftware construction fundamentals include• minimizing complexity• anticipating change• constructing for verification• reuse• standards in construction.The first four concepts apply to design as wellas to construction.
The following sections define3-13-2 SWEBOK® Guide V3.0Figure 3.1. Breakdown of Topics for the Software Construction KASoftware Construction 3-3these concepts and describe how they apply toconstruction.1.1. Minimizing Complexity[1*]Most people are limited in their ability to holdcomplex structures and information in theirworking memories, especially over long periods of time. This proves to be a major factorinfluencing how people convey intent to computers and leads to one of the strongest drivesin software construction: minimizing complexity. The need to reduce complexity applies toessentially every aspect of software constructionand is particularly critical to testing of softwareconstructions.In software construction, reduced complexityis achieved through emphasizing code creationthat is simple and readable rather than clever.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
