|
|
| Line 1: |
Line 1: |
| | + | {{TOC}} |
| | {{Acronyms|{{Acronym|name=API|description=Application Programming Interface}} | | {{Acronyms|{{Acronym|name=API|description=Application Programming Interface}} |
| | {{Acronym|name=COTS|description=Commercial Off-the-Shelf}} | | {{Acronym|name=COTS|description=Commercial Off-the-Shelf}} |
| Line 8: |
Line 9: |
| | {{Acronym|name=UML|description=Unified Modeling Language}} | | {{Acronym|name=UML|description=Unified Modeling Language}} |
| | }} | | }} |
| − |
| |
| − | {{IntroSection|title=Introduction|body=
| |
| − | The term software construction refers to the detailed creation of working software through a combination 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 most strongly linked to Software Design and Software Testing because the software construction process involves significant software design and testing.
| |
| − | The process uses the design output and provides an input to testing (“design” and “testing” in this case referring to the activities, not the KAs). Boundaries between design, construction, and testing (if any) will vary depending on the software life cycle processes that are used in a project. Although some detailed design may be performed prior to construction, much design work is performed during the construction activity.
| |
| − | Thus, the Software Construction KA is closely linked to the Software Design KA.
| |
| − | Throughout construction, software engineers both unit test and integration test their work. Thus, the Software construction KA is closely linked to the Software Testing KA as well.
| |
| − | Software construction typically produces the highest number of configuration items that need to be managed in a software project (source files, documentation, test cases, and so on). Thus, the Software Construction KA is also closely linked to the Software Configuration Management KA. While software quality is important in all the KAs, code is the ultimate deliverable of a software project, and thus the Software Quality KA is closely linked to the Software Construction KA.
| |
| − | Since software construction requires knowledge of algorithms and of coding practices, it is closely related to the Computing Foundations KA, which is concerned with the computer science foundations that support the design and construction of software products. It is also related to project management, insofar as the management of construction can present considerable challenges. }}
| |
| − |
| |
| − | {{IntroSection|title=Breakdown of Topics for Software Construction|body=
| |
| − | Figure 3.1 gives a graphical representation of the top-level decomposition of the breakdown for the Software Construction KA.}}
| |
| − |
| |
| − | ==Software Construction Fundamentals==
| |
| − |
| |
| − | Software construction fundamentals include
| |
| − | *minimizing complexity
| |
| − | *anticipating change
| |
| − | *constructing for verification
| |
| − | *reuse
| |
| − | *standards in construction.
| |
| − |
| |
| − | The first four concepts apply to design as well as to construction. The following sections define these concepts and describe how they apply to construction.
| |
| − | ===Minimizing Complexity===
| |
| − |
| |
| − | [1*]
| |
| − |
| |
| − | Most people are limited in their ability to hold complex structures and information in their working memories, especially over long periods of time. This proves to be a major factor influencing how people convey intent to computers and leads to one of the strongest drives in software construction: ''minimizing'' complexity.
| |
| − | The need to reduce complexity applies to essentially every aspect of software construction and is particularly critical to testing of software constructions. In software construction, reduced complexity is achieved through emphasizing code creation that is simple and readable rather than clever.
| |
| − | It is accomplished through making use of standards (see section 1.5, Standards in Construction), modular design (see section 3.1, Construction
| |
| − | Design), and numerous other specific techniques (see section 3.3, Coding). It is also supported by construction-focused quality techniques (see section 3.7, Construction Quality).
| |
| − |
| |
| − | ===Anticipating Change===
| |
| − | [1*]
| |
| − |
| |
| − | Most software will change over time, and the anticipation of change drives many aspects of software construction; changes in the environments in which software operates also affect software in diverse ways.
| |
| − | Anticipating change helps software engineers build extensible software, which means they can enhance a software product without disrupting the underlying structure. Anticipating change is supported by many specific techniques (see section 3.3, Coding).
| |
| − |
| |
| − | ===Constructing for Verification===
| |
| − | [1*]
| |
| − |
| |
| − | Constructing for verification means building software in such a way that faults can be readily found by the software engineers writing the software as well as by the testers and users during independent testing and operational activities. Specific techniques that support constructing for verification include following coding standards to support code reviews and unit testing, organizing code to support automated testing, and restricting the use of complex or hard-to-understand language structures, among others.
| |
| − |
| |
| − | ===Reuse===
| |
| − | [2*]
| |
| − |
| |
| − | Reuse refers to using existing assets in solving different problems. In software construction, typical assets that are reused include libraries, modules, components, source code, and commercial off-the-shelf (COTS) assets. Reuse is best practiced systematically, according to a well-defined, repeatable process. Systematic reuse can enable significant software productivity, quality, and cost improvements. Reuse has two closely related facets:"construction for reuse" and "construction with reuse." The former means to create reusable software assets,
| |
| − | while the latter means to reuse software assets in the construction of a new solution. Reuse often transcends the boundary of projects, which means reused assets can be constructed in other projects or organizations.
| |
| − |
| |
| − | ===Standards in Construction===
| |
| − | [1*]
| |
| − |
| |
| − | Applying external or internal development standards during construction helps achieve a project’s objectives for efficiency, quality, and cost. Specifically, the choices of allowable programming language subsets and usage standards are important aids in achieving higher security. Standards that directly affect construction issues include
| |
| − | *communication methods (for example, standards for document formats and contents)
| |
| − | *programming languages (for example, language standards for languages like Java and C++)*coding standards (for example, standards for naming conventions, layout, and indentation)
| |
| − | *platforms (for example, interface standards for operating system calls)
| |
| − | *tools (for example, diagrammatic standards for notations like UML (Unified Modeling Language)).
| |
| − | ''Use of external standards''. Construction depends on the use of external standards for construction languages, construction tools, technical interfaces, and interactions between the Software Construction KA and other KAs. Standards come from numerous sources, including hardware and software interface specifications (such as the Object Management Group (OMG)) and international organizations (such as the IEEE or ISO). Use of internal standards. Standards may also be created on an organizational basis at the corporate level or for use on specific projects. These standards support coordination of group activities, minimizing complexity, anticipating change, and constructing for verification.
| |
| − |
| |
| − | ==Managing Construction==
| |
| − | ===Construction in Life Cycle Models===
| |
| − | [1*]
| |
| − |
| |
| − | Numerous models have been created to develop software; some emphasize construction more than others.
| |
| − | Some models are more linear from the construction point of view—such as the waterfall and staged-delivery life cycle models. These models treat construction as an activity that occurs only after significant prerequisite work has been completed—including detailed requirements work, extensive design work, and detailed planning. The more linear approaches tend to emphasize the activities that precede construction (requirements and design) and to create more distinct separations between activities. In these models, the main emphasis of construction may be coding.
| |
| − | Other models are more iterative—such as evolutionary prototyping and agile development.
| |
| − | These approaches tend to treat construction as an activity that occurs concurrently with other software development activities (including requirements, design, and planning) or that overlaps them.
| |
| − | These approaches tend to mix design, coding, and testing activities, and they often treat the combination of activities as construction (see the Software Management and Software Process KAs).
| |
| − | Consequently, what is considered to be “construction” depends to some degree on the life cycle model used.
| |
| − | In general, software construction is mostly coding and debugging, but it also involves construction planning, detailed design, unit testing, integration testing, and other activities.
| |
| − |
| |
| − | ===Construction Planning===
| |
| − | [1*]
| |
| − |
| |
| − | The choice of construction method is a key aspect of the construction-planning activity. The choice of construction method affects the extent to which construction prerequisites are performed, the order in which they are performed, and the degree to which they should be completed before construction work begins. The approach to construction affects the project team’s ability to reduce complexity, anticipate change, and construct for verification. Each of these objectives may also be addressed at the process, requirements, and design levels—but they will be influenced by the choice of construction method. Construction planning also defines the order in which components are created and integrated, the integration strategy (for example, phased or incremental integration), the software quality management processes, the allocation of task assignments to specific software engineers, and
| |
| − | other tasks, according to the chosen method.
| |
| − |
| |
| − | ===Construction Measurement===
| |
| − | [1*]
| |
| − |
| |
| − | Numerous construction activities and artifacts can be measured—including code developed, code modified, code reused, code destroyed, code complexity, code inspection statistics, fault-fix and fault-find rates, effort, and scheduling. These measurements can be useful for purposes of managing construction, ensuring quality during construction, and improving the construction process, among other uses (see the Software Engineering Process (KA for more on measurement).
| |
| − |
| |
| − | ==Practical Considerations==
| |
| − | Software Construction
| |
| − | 3-5
| |
| − | 3.
| |
| − | Practical Considerations
| |
| − | Construction is an activity in which the software
| |
| − | engineer has to deal with sometimes chaotic and
| |
| − | changing real-world constraints, and he or she
| |
| − | must do so precisely. Due to the influence of real-
| |
| − | world constraints, construction is more driven by
| |
| − | practical considerations than some other KAs,
| |
| − | and software engineering is perhaps most craft-
| |
| − | like in the construction activities.
| |
| − | ===Construction Design===
| |
| − | 3.1.
| |
| − | Construction
| |
| − | Design
| |
| − | [1*]
| |
| − | Some projects allocate considerable design activ
| |
| − | -
| |
| − | ity to construction, while others allocate design
| |
| − | to a phase explicitly focused on design. Regard
| |
| − | -
| |
| − | less of the exact allocation, some detailed design
| |
| − | work will occur at the construction level, and that
| |
| − | design work tends to be dictated by constraints
| |
| − | imposed by the real-world problem that is being
| |
| − | addressed by the software.
| |
| − | Just as construction workers building a physi
| |
| − | -
| |
| − | cal structure must make small-scale modifica
| |
| − | -
| |
| − | tions to account for unanticipated gaps in the
| |
| − | builder’s plans, software construction workers
| |
| − | must make modifications on a smaller or larger
| |
| − | scale to flesh out details of the software design
| |
| − | during construction.
| |
| − | The details of the design activity at the construc
| |
| − | -
| |
| − | tion level are essentially the same as described in
| |
| − | the Software Design KA, but they are applied on
| |
| − | a smaller scale of algorithms, data structures, and
| |
| − | interfaces.
| |
| − | ===Construction Languages===
| |
| − | 3.2.
| |
| − | Construction
| |
| − | Languages
| |
| − | [1*]
| |
| − | Construction languages include all forms of
| |
| − | communication by which a human can specify an
| |
| − | executable problem solution to a problem. Con
| |
| − | -
| |
| − | struction languages and their implementations
| |
| − | (for example, compilers) can affect software
| |
| − | quality attributes of performance, reliability, por
| |
| − | -
| |
| − | tability, and so forth. They can be serious con
| |
| − | -
| |
| − | tributors to security vulnerabilities.
| |
| − | The simplest type of construction language
| |
| − | is a
| |
| − | configuration
| |
| − | language,
| |
| − | in which software
| |
| − | engineers choose from a limited set of pre
| |
| − | -
| |
| − | defined options to create new or custom software
| |
| − | installations. The text-based configuration files
| |
| − | used in both the Windows and Unix operating
| |
| − | systems are examples of this, and the menu-style
| |
| − | selection lists of some program generators consti
| |
| − | -
| |
| − | tute another example of a configuration language.
| |
| − | Toolkit
| |
| − | languages
| |
| − | are used to build applica
| |
| − | -
| |
| − | tions out of elements in toolkits (integrated sets
| |
| − | of application-specific reusable parts); they are
| |
| − | more complex than configuration languages.
| |
| − | Toolkit languages may be explicitly defined as
| |
| − | application programming languages, or the appli
| |
| − | -
| |
| − | cations may simply be implied by a toolkit’s set
| |
| − | of interfaces.
| |
| − | Scripting
| |
| − | languages
| |
| − | are commonly used kinds
| |
| − | of application programming languages. In some
| |
| − | scripting languages, scripts are called batch files
| |
| − | or macros.
| |
| − | Programming
| |
| − | languages
| |
| − | are the most flexible
| |
| − | type of construction languages. They also contain
| |
| − | the least amount of information about specific
| |
| − | application areas and development processes—
| |
| − | therefore, they require the most training and skill
| |
| − | to use effectively. The choice of programming lan
| |
| − | -
| |
| − | guage can have a large effect on the likelihood of
| |
| − | vulnerabilities being introduced during coding—
| |
| − | for example, uncritical usage of C and C++ are
| |
| − | questionable choices from a security viewpoint.
| |
| − | There are three general kinds of notation used
| |
| − | for programming languages, namely
| |
| − | •
| |
| − | linguistic (e.g., C/C++, Java)
| |
| − | •
| |
| − | formal (e.g., Event-B)
| |
| − | •
| |
| − | visual (e.g., MatLab).
| |
| − | Linguistic
| |
| − | notations
| |
| − | are distinguished in par
| |
| − | -
| |
| − | ticular by the use of textual strings to represent
| |
| − | complex software constructions. The combina
| |
| − | -
| |
| − | tion of textual strings into patterns may have a
| |
| − | sentence-like syntax. Properly used, each such
| |
| − | string should have a strong semantic connotation
| |
| − | providing an immediate intuitive understanding
| |
| − | of what will happen when the software construc
| |
| − | -
| |
| − | tion is executed.
| |
| − | Formal
| |
| − | notations
| |
| − | rely less on intuitive, every
| |
| − | -
| |
| − | day meanings of words and text strings and more
| |
| − | on definitions backed up by precise, unambigu
| |
| − | -
| |
| − | ous, and formal (or mathematical) definitions.
| |
| − | Formal construction notations and formal meth
| |
| − | -
| |
| − | ods are at the semantic base of most forms of
| |
| − | 3-6
| |
| − | SWEBOK® Guide
| |
| − | V3.0
| |
| − | system programming notations, where accuracy,
| |
| − | time behavior, and testability are more important
| |
| − | than ease of mapping into natural language. For
| |
| − | -
| |
| − | mal constructions also use precisely defined ways
| |
| − | of combining symbols that avoid the ambiguity
| |
| − | of many natural language constructions.
| |
| − | Visual
| |
| − | notations
| |
| − | rely much less on the textual
| |
| − | notations of linguistic and formal construction
| |
| − | and instead rely on direct visual interpretation
| |
| − | and placement of visual entities that represent the
| |
| − | underlying software. Visual construction tends to
| |
| − | be somewhat limited by the difficulty of making
| |
| − | “complex” statements using only the arrange
| |
| − | -
| |
| − | ment of icons on a display. However, these icons
| |
| − | can be powerful tools in cases where the primary
| |
| − | programming task is simply to build and “adjust”
| |
| − | a visual interface to a program, the detailed
| |
| − | behavior of which has an underlying definition.
| |
| − | ===Coding===
| |
| − | 3.3.
| |
| − | Coding
| |
| − | [1*]
| |
| − | The following considerations apply to the soft
| |
| − | -
| |
| − | ware construction coding activity:
| |
| − | •
| |
| − | Techniques for creating understandable
| |
| − | source code, including naming conventions
| |
| − | and source code layout;
| |
| − | •
| |
| − | Use of classes, enumerated types, variables,
| |
| − | named constants, and other similar entities;
| |
| − | •
| |
| − | Use of control structures;
| |
| − | •
| |
| − | Handling of error conditions—both antici
| |
| − | -
| |
| − | pated and exceptional (input of bad data, for
| |
| − | example);
| |
| − | •
| |
| − | Prevention of code-level security breaches
| |
| − | (buffer overflows or array index bounds, for
| |
| − | example);
| |
| − | •
| |
| − | Resource usage via use of exclusion mecha
| |
| − | -
| |
| − | nisms and discipline in accessing serially
| |
| − | reusable resources (including threads and
| |
| − | database locks);
| |
| − | •
| |
| − | Source code organization (into state
| |
| − | -
| |
| − | ments, routines, classes, packages, or other
| |
| − | structures);
| |
| − | •
| |
| − | Code documentation;
| |
| − | •
| |
| − | Code tuning,
| |
| − | ===Construction Testing===
| |
| − | 3.4.
| |
| − | Construction
| |
| − | Testing
| |
| − | [1*]
| |
| − | Construction involves two forms of testing,
| |
| − | which are often performed by the software engi
| |
| − | -
| |
| − | neer who wrote the code:
| |
| − | •
| |
| − | Unit testing
| |
| − | •
| |
| − | Integration testing.
| |
| − | The purpose of construction testing is to reduce
| |
| − | the gap between the time when faults are inserted
| |
| − | into the code and the time when those faults are
| |
| − | detected, thereby reducing the cost incurred to
| |
| − | fix them. In some instances, test cases are writ
| |
| − | -
| |
| − | ten after code has been written. In other instances,
| |
| − | test cases may be created before code is written.
| |
| − | Construction testing typically involves a
| |
| − | subset of the various types of testing, which
| |
| − | are described in the Software Testing KA. For
| |
| − | instance, construction testing does not typically
| |
| − | include system testing, alpha testing, beta testing,
| |
| − | stress testing, configuration testing, usability test
| |
| − | -
| |
| − | ing, or other more specialized kinds of testing.
| |
| − | Two standards have been published on the topic
| |
| − | of construction testing: IEEE Standard 829-1998
| |
| − | ,
| |
| − | IEEE
| |
| − | Standard
| |
| − | for
| |
| − | Software
| |
| − | Test
| |
| − | Documentation,
| |
| − | and IEEE Standard 1008-1987,
| |
| − | IEEE
| |
| − | Standard
| |
| − | for
| |
| − | Software
| |
| − | Unit
| |
| − | Testing
| |
| − | .
| |
| − | (See sections 2.1.1.,
| |
| − | Unit Testing, and 2.1.2.,
| |
| − | Integration Testing, in the Software Testing KA
| |
| − | for more specialized reference material.)
| |
| − | 3.5.
| |
| − | Construction
| |
| − | for
| |
| − | Reuse
| |
| − | [2*]
| |
| − | Construction for reuse creates software that has
| |
| − | the potential to be reused in the future for the
| |
| − | present project or other projects taking a broad-
| |
| − | based, multisystem perspective. Construction for
| |
| − | reuse is usually based on variability analysis and
| |
| − | design. To avoid the problem of code clones, it
| |
| − | is desired to encapsulate reusable code fragments
| |
| − | into well-structured libraries or components.
| |
| − | The tasks related to software construction for
| |
| − | reuse during coding and testing are as follows:
| |
| − | Software Construction
| |
| − | 3-7
| |
| − | •
| |
| − | Variability implementation with mecha
| |
| − | -
| |
| − | nisms such as parameterization, conditional
| |
| − | compilation, design patterns, and so forth.
| |
| − | •
| |
| − | Variability encapsulation to make the soft
| |
| − | -
| |
| − | ware assets easy to configure and customize.
| |
| − | •
| |
| − | Testing the variability provided by the reus
| |
| − | -
| |
| − | able software assets.
| |
| − | •
| |
| − | Description and publication of reusable soft
| |
| − | -
| |
| − | ware assets.
| |
| − | 3.6.
| |
| − | Construction
| |
| − | with
| |
| − | Reuse
| |
| − | [2*]
| |
| − | Construction with reuse means to create new
| |
| − | software with the reuse of existing software
| |
| − | assets. The most popular method of reuse is to
| |
| − | reuse code from the libraries provided by the lan
| |
| − | -
| |
| − | guage, platform, tools being used, or an organiza
| |
| − | -
| |
| − | tional repository. Asides from these, the applica
| |
| − | -
| |
| − | tions developed today widely make use of many
| |
| − | open-source libraries. Reused and off-the-shelf
| |
| − | software often have the same—or better—quality
| |
| − | requirements as newly developed software (for
| |
| − | example, security level).
| |
| − | The tasks related to software construction with
| |
| − | reuse during coding and testing are as follows:
| |
| − | •
| |
| − | The selection of the reusable units, data
| |
| − | -
| |
| − | bases, test procedures, or test data.
| |
| − | •
| |
| − | The evaluation of code or test reusability.
| |
| − | •
| |
| − | The integration of reusable software assets
| |
| − | into the current software.
| |
| − | •
| |
| − | The reporting of reuse information on new
| |
| − | code, test procedures, or test data.
| |
| − | ===Construction for Reuse===
| |
| − | ===Construction with Reuse===
| |
| − | ===Construction Quality===
| |
| − | ===Integration===
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | 3.7.
| |
| − | Construction
| |
| − | Quality
| |
| − | [1*]
| |
| − | In addition to faults resulting from requirements
| |
| − | and design, faults introduced during construction
| |
| − | can result in serious quality problems—for exam
| |
| − | -
| |
| − | ple, security vulnerabilities. This includes not
| |
| − | only faults in security functionality but also faults
| |
| − | elsewhere that allow bypassing of this functional
| |
| − | -
| |
| − | ity and other security weaknesses or violations.
| |
| − | Numerous techniques exist to ensure the qual
| |
| − | -
| |
| − | ity of code as it is constructed. The primary tech
| |
| − | -
| |
| − | niques used for construction quality include
| |
| − | •
| |
| − | unit testing and integration testing (see sec
| |
| − | -
| |
| − | tion 3.4, Construction Testing)
| |
| − | •
| |
| − | test-first development (see section 2.2 in the
| |
| − | Software Testing KA)
| |
| − | •
| |
| − | use of assertions and defensive programming
| |
| − | •
| |
| − | debugging
| |
| − | •
| |
| − | inspections
| |
| − | •
| |
| − | technical reviews, including security-ori
| |
| − | -
| |
| − | ented reviews (see section 2.3.2 in the Soft
| |
| − | -
| |
| − | ware Quality KA)
| |
| − | •
| |
| − | static analysis (see section 2.3 of the Soft
| |
| − | -
| |
| − | ware Quality KA)
| |
| − | The specific technique or techniques selected
| |
| − | depend on the nature of the software being con
| |
| − | -
| |
| − | structed as well as on the skillset of the software
| |
| − | engineers performing the construction activi
| |
| − | -
| |
| − | ties. Programmers should know good practices
| |
| − | and common vulnerabilities—for example, from
| |
| − | widely recognized lists about common vulner
| |
| − | -
| |
| − | abilities. Automated static analysis of code for
| |
| − | security weaknesses is available for several com
| |
| − | -
| |
| − | mon programming languages and can be used in
| |
| − | security-critical projects.
| |
| − | Construction quality activities are differenti
| |
| − | -
| |
| − | ated from other quality activities by their focus.
| |
| − | Construction quality activities focus on code and
| |
| − | artifacts that are closely related to code—such
| |
| − | as detailed design—as opposed to other artifacts
| |
| − | that are less directly connected to the code, such
| |
| − | as requirements, high-level designs, and plans.
| |
| − | 3.8.
| |
| − | Integration
| |
| − | [1*]
| |
| − | A key activity during construction is the integra
| |
| − | -
| |
| − | tion of individually constructed routines, classes,
| |
| − | components, and subsystems into a single sys
| |
| − | -
| |
| − | tem. In addition, a particular software system
| |
| − | may need to be integrated with other software or
| |
| − | hardware systems.
| |
| − | Concerns related to construction integration
| |
| − | include planning the sequence in which compo
| |
| − | -
| |
| − | nents will be integrated, identifying what hard
| |
| − | -
| |
| − | ware is needed, creating scaffolding to support
| |
| − | interim versions of the software, determining
| |
| − | the degree of testing and quality work performed
| |
| − | on components before they are integrated, and
| |
| − | 3-8
| |
| − | SWEBOK® Guide
| |
| − | V3.0
| |
| − | determining points in the project at which interim
| |
| − | versions of the software are tested.
| |
| − | Programs can be integrated by means of either
| |
| − | the phased or the incremental approach. Phased
| |
| − | integration, also called “big bang” integration,
| |
| − | entails delaying the integration of component
| |
| − | software parts until all parts intended for release
| |
| − | in a version are complete. Incremental integration
| |
| − | is thought to offer many advantages over the tra
| |
| − | -
| |
| − | ditional phased integration—for example, easier
| |
| − | error location, improved progress monitoring,
| |
| − | earlier product delivery, and improved customer
| |
| − | relations. In incremental integration, the develop
| |
| − | -
| |
| − | ers write and test a program in small pieces and
| |
| − | then combine the pieces one at a time. Additional
| |
| − | test infrastructure, such as stubs, drivers, and
| |
| − | mock objects, are usually needed to enable incre
| |
| − | -
| |
| − | mental integration. By building and integrating
| |
| − | one unit at a time (for example, a class or compo
| |
| − | -
| |
| − | nent), the construction process can provide early
| |
| − | feedback to developers and customers. Other
| |
| − | advantages of incremental integration include
| |
| − | easier error location, improved progress monitor
| |
| − | -
| |
| − | ing, more fully tested units, and so forth
| |
| − |
| |
| − | ==Construction Technologies==
| |
| − | ===API Design and Use===
| |
| − | ===Object-Oriented Runtime Issues===
| |
| − | ===Parameterization and Generics===
| |
| − | ===Assertions, Design by Contract, and Defensive Programming===
| |
| − | ===Error Handling, Exception Handling, and Fault Tolerance===
| |
| − | ===Executable Models===
| |
| − | ===State-Based and Table-Driven Construction Techniques===
| |
| − | ===Runtime Configuration and Internationalization===
| |
| − | ===Grammar-Based Input Processing===
| |
| − | ===Concurrency Primitives===
| |
| − | ===Middleware===
| |
| − | ===Construction Methods for DistributedSoftware Constructing Heterogeneous Systems===
| |
| − | ===Performance Analysis and Tuning===
| |
| − | ===Platform Standards===
| |
| − | ===Test-First Programming===
| |
| − | ==Software Construction Tools==
| |
| − | ===Development Environments===
| |
| − | [1*]
| |
| − |
| |
| − | A development environment, or integrated development environment (IDE), provides comprehensive facilities to programmers for software construction by integrating a set of development tools. The choices of development environments can affect the efficiency and quality of software construction. In additional to basic code editing functions, modern IDEs often offer other features like compilation and error detection from within the editor, integration with source code control, build/test/debugging tools, compressed or outline views of programs, automated code transforms, and support for refactoring.
| |
| − |
| |
| − | ===GUI Builders===
| |
| − | [1*]
| |
| − |
| |
| − | A GUI (Graphical User Interface) builder is a software development tool that enables the developer to create and maintain GUIs in a WYSIWYG (what you see is what you get) mode. A GUI builder usually includes a visual editor for the developer to design forms and windows and manage the layout of the widgets by dragging, dropping, and parameter setting. Some GUI builders can automatically generate the source code corresponding to the visual GUI design. Because current GUI applications usually follow the event-driven style (in which the flow of the program is determined by events and event handling), GUI builder tools usually provide code generation assistants, which automate the most repetitive tasks required for event handling. The supporting code connects widgets with the outgoing and incoming events that trigger the functions providing the application logic. Some modern IDEs provide integrated GUI builders or GUI builder plug-ins. There are also many standalone GUI builders.
| |
| − |
| |
| − | ===Unit Testing Tools===
| |
| − | [1*] [2*]
| |
| − |
| |
| − | Unit testing verifies the functioning of software modules in isolation from other software elements that are separately testable (for example, classes, routines, components). Unit testing is often automated. Developers can use unit testing tools and frameworks to extend and create automated testing environment. With unit testing tools and
| |
| − | frameworks, the developer can code criteria into the test to verify the unit’s correctness under various data sets. each individual test is implemented as an object, and a test runner runs all of the tests. During the test execution, those failed test cases will be automatically flagged and reported.
| |
| − |
| |
| − | ===Profiling, Performance Analysis, and Slicing Tools===
| |
| − | [1*]
| |
| − |
| |
| − | Performance analysis tools are usually used to support code tuning. The most common performance analysis tools are profiling tools. An execution profiling tool monitors the code while it runs and records how many times each statement is executed or how much time the program spends on each statement or execution path. Profiling the code while it is running gives insight into how the program works, where the hot spots are, and where the developers should focus the code tuning efforts.Program slicing involves computation of the set of program statements (i.e., the program slice) that may affect the values of specified variables at some point of interest, which is referred to as a slicing criterion. Program slicing can be used for locating the source of errors, program understanding, and optimization analysis. Program slicing tools compute program slices for various programming languages using static or dynamic analysis methods.
| |
