Chapter 3: Software Construction - Revision history

Daniel Robbins: /* Profiling, Performance Analysis, and Slicing Tools */

2015-08-24T23:48:08Z

‎Profiling, Performance Analysis, and Slicing Tools

Daniel Robbins: /* Profiling, Performance Analysis, and Slicing Tools */

2015-08-24T23:41:07Z

‎Profiling, Performance Analysis, and Slicing Tools

Daniel Robbins: /* Profiling, Performance Analysis, and Slicing Tools */

2015-08-24T23:39:56Z

‎Profiling, Performance Analysis, and Slicing Tools

Daniel Robbins: /* Profiling, Performance Analysis, and Slicing Tools */

2015-08-24T23:33:49Z

‎Profiling, Performance Analysis, and Slicing Tools

Daniel Robbins: /* Unit Testing Tools */

2015-08-24T23:29:28Z

‎Unit Testing Tools

Daniel Robbins: /* Software Construction Tools */

2015-08-24T23:28:49Z

‎Software Construction Tools

Daniel Robbins: /* Construction Technologies */

2015-08-24T23:27:51Z

‎Construction Technologies

Daniel Robbins: /* Grammar-Based Input Processing */

2015-08-24T23:24:28Z

‎Grammar-Based Input Processing

Daniel Robbins: /* Construction Technologies */

2015-08-24T23:23:34Z

‎Construction Technologies

Daniel Robbins: /* Practical Considerations */

2015-08-24T23:19:51Z

‎Practical Considerations

@@ Line 316: / Line 316: @@
 }}{{reference
 |number=2
-|author=K.E. Wiegers
+|author=I. Sommerville
 |article=
-|publication=Software Requirements
+|publication=Software Engineering
-|edition=2th ed.
+|edition=9th ed.
-|publisher=Microsoft Press
+|publisher=Addison-Wesley
 |issue=
-|date=2003
+|date=2011
 |part=
 |link=
 }}{{reference
 |number=3
-|author=INCOSE
+|author=P. Clements et al.
 |article=
-|publication=Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities
+|publication=Documenting Software Architectures: Views and Beyond
-|edition=version 3.2.2
+|edition=2nd ed.
-|publisher=International Council on Systems Engineering
+|publisher=Pearson Education
 |issue=
-|date=2012
+|date=2010
 |part=
 |link=
@@ Line 339: / Line 339: @@
 {{reference
 |number=4
-|author=S. Friedenthal, A. Morre, and R. Steiner
+|author=E. Gamma et al.
 |article=
-|publication=A Practical Guide to SysML: The Systems Modeling Language |edition=2nd ed.
+|publication=Design Patterns: Elements of Reusable Object-Oriented Software
-|publisher=Morgan Kaufmann
+|edition=1st ed.
 |issue=
-|date=2012
+|date=1994
 |part=
 |link=
 }}{{reference
 |number=5
-|author=I. Alexander and L. Beus-Duekic
+|author=S.J. Mellor and M.J. Balcer
 |article=
-|publication=Discovering Requirements: How to Specify Products and Services
+|publication=Executable UML: A Foundation for Model-Driven Architecture
-|edition=
+|edition=1st ed.
-|publisher=Wiley
+|publisher=Addison-Wesley
 |issue=
-|date=2009
+|date=2002
 |part=
 |link=
 }}{{reference
 |number=6
-|author=C. Potts, K. Takahashi, and A.I. Antón
+|author=L. Null and J. Lobur
-|article=Inquiry-Based Requirements Analysis
+|article=The Essentials of Computer Organization and Architecture
-|publication=IEEE Software
+|publication=
-|edition=
+|edition=2nd ed.
-|publisher=International Council on Systems Engineering
+|publisher=Jones and Bartlett Publishers
-|issue=vol. 11, no. 2
+|issue=
-|date=Mar. 1994
+|date=2006
-|part=pp. 21-32
+|part=
 |link=
 }}{{reference
 |number=7
-|author=A. van Lamsweerde
+|author=A. Silberschatz, P.B. Galvin, and G. Gagne
 |article=
-|publication=Requirements Engineering: From System Goals to UML Models to Software Specifications
+|publication=Operating System Concepts
-|edition=
+|edition= 8th ed.
 |publisher=Wiley
 |issue=
-|date=2009
+|date=2008
 |part=
 |link=
@@ Line 394: / Line 395: @@
 |number=9
 |author=IEEE
-|article='IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008) Standard for Systems and Software Engineering—Software Life Cycle Processes'
+|article=IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008) Standard for Systems and Software Engineering—Software Life Cycle Processes
 |publication=
 |edition=
@@ Line 404: / Line 405: @@
 }}{{ReferenceList}}
 }}

@@ Line 394: / Line 394: @@
 |number=9
 |author=IEEE
-|article=''IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008) Standard for Systems and Software Engineering—Software Life Cycle Processes''
+|article='IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008) Standard for Systems and Software Engineering—Software Life Cycle Processes'
 |publication=
 |edition=

@@ Line 305: / Line 305: @@
 {{reference
 |number=1
-|author=I. Sommerville
+|author=S. McConnell
 |article=
-|publication=Software Engineering
+|publication=Code Complete
-|edition=9th ed.
+|edition=2nd ed.
-|publisher=Addison-Wesley
+|publisher=Microsoft Press
 |issue=
-|date=2011
+|date=2004
 |part=
 |link=
@@ Line 382: / Line 382: @@
 }}{{reference
 |number=8
-|author=O. Gotel and C.W. Finkelstein
+|author=IEEE
-|article=An Analysis of the Requirements Traceability Problem
+|article=IEEE Std. 1517-2010 Standard for Information Technology—System and Software Life Cycle Processes—Reuse Processes
-|publication=Proc 1st Int'l Conf. Requirements Eng.
+|publication=
 |edition=
 |publisher=IEEE
 |issue=
-|date=1994
+|date=2010
 |part=
 |link=
 }}{{reference
 |number=9
-|author=N.A. Maiden and C. Ncube
+|author=IEEE
-|article=Acquiring COTS Software Selection Requirements
+|article=''IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008) Standard for Systems and Software Engineering—Software Life Cycle Processes''
-|publication=IEEE Software
+|publication=
 |edition=
-|publisher=
+|publisher=IEEE
-|issue=vol. 15, no. 2
+|issue=
-|date=Mar.-Apr. 1998
+|date=2008
-|part=pp. 46-56
+|part=
 |link=
 }}{{ReferenceList}}
 }}

@@ Line 293: / Line 293: @@
 {{EndSection|title=Further Readings|body=
-I. Alexander and L. Beus-Dukic, ''Discovering Requirements'' [5].
+''IEEE Std. 1517-2010 Standard for Information Technology—System and Software Life Cycle Processes—Reuse Processes'', IEEE, 2010 [8].
-An easily digestible and practically oriented
+This standard specifies the processes, activities, and tasks to be applied during each phase of the software life cycle to enable a software product to be constructed from reusable assets. It covers the concept of reuse-based development and the processes of construction for reuse and construction with reuse.
-book on software requirements, this is perhaps
-the best of current textbooks on how the various
-elements of software requirements fit together. It
-is full of practical advice on (for example) how
-to identify the various system stakeholders and
-how to evaluate alternative solutions. Its coverage
-is exemplary and serves as a useful reference
-for key techniques such as use case modeling and
-requirements prioritization.
-C. Potts, K. Takahashi, and A. Antón, “Inquiry-Based Requirements Analysis” [6].
+''IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008) Standard for Systems and Software Engineering—Software Life Cycle Processes'', IEEE, 2008 [9].
-−
-This paper is an easily digested account of work
-that has proven to be very influential in the development
-of requirements handling. It describes
-how and why the elaboration of requirements
-cannot be a linear process by which the analyst
-simply transcribes and reformulates requirements
-elicited from the customer. The role of scenarios
-is described in a way that helps to define their use
-in discovering and describing requirements.
-−
-A. van Lamsweerde, ''Requirements
-Engineering: From System Goals to UML
-Models to Software Specifications'' [7].
-−
-Serves as a good introduction to requirements
-engineering but its unique value is as a reference
-book for the KAOS goal-oriented requirements
-modelling language. Explains why goal modelling
-is useful and shows how it can integrate with
-mainstream modelling techniques using UML.
-−
-O. Gotel and A. Finkelstein, “An Analysis of the
-Requirements Traceability Problem” [8].
-−
-This paper is a classic reference work on a key
-element of requirements management. Based on
-empirical studies, it sets out the reasons for and
-the barriers to the effective tracing of requirements.
-It is essential reading for an understanding
-of why requirements tracing is an essential element
-of an effective software process.
-−
-N. Maiden and C. Ncube, “Acquiring COTS Software Selection Requirements” [9].
-−
-This paper is significant because it recognises
-explicitly that software products often integrate
-third-party components. It offers insights into the
-problems of selecting off-the-shelf software to
-satisfy requirements: there is usually a mismatch.
-This challenges some of the assumptions underpinning
-much of traditional requirements handling,
-which tends to assume custom software.
 }}

@@ Line 281: / Line 281: @@
 ===Unit Testing Tools===
-[1*] [2*]
+{{RightSection|{{referenceLink|number=1}} {{referenceLink|number=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

@@ Line 271: / Line 271: @@
 ==Software Construction Tools==
 ===Development Environments===
-[1*]
+{{RightSection|{{referenceLink|number=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*]
+{{RightSection|{{referenceLink|number=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.
@@ Line 287: / Line 287: @@
 ===Profiling, Performance Analysis, and Slicing Tools===
-[1*]
+{{RightSection|{{referenceLink|number=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.

@@ Line 233: / Line 233: @@
 To  achieve  more  flexibility,  a  program  is  often constructed to support late binding time of its variables.  Runtime  configuration  is  a  technique  that binds variable values and program settings when the program is running, usually by updating and reading configuration files in a just-in-time mode. Internationalization  is  the  technical  activity of preparing a program, usually interactive software, to support multiple locales. The corresponding activity, localization, is the activity of modifying a program to support a specific local language. Interactive software may contain dozens or hundreds of prompts, status displays, help messages, error messages, and so on. The design and construction processes should accommodate string  and  character-set  issues  including  which character set is to be used, what kinds of strings are used, how to maintain the strings without changing the code, and translating the strings into different languages with minimal impact on the processing code and the user interface.
 ===Grammar-Based Input Processing===
-{{RightSection|{{referenceLink|number=1}} {{referenceLink|number=6}}}}[1*] [6*]
+{{RightSection|{{referenceLink|number=1}} {{referenceLink|number=6}}}}
 Grammar-based input processing involves syntax analysis, or parsing, of the input token stream. It involves the creation of a data structure (called a parse tree or syntax tree) representing the input data. The inorder traversal of the parse tree usually gives the expression just parsed. The parser checks the symbol table for the presence of programmer-defined variables that populate the tree. After building the parse tree, the program uses it as input to the computational processes.
 ===Concurrency Primitives===
-[7*]
+{{RightSection|{{referenceLink|number=7}}}}
 A synchronization primitive is a programming abstraction provided by a programming language or the operating system that facilitates concurrency and synchronization. Well-known concurrency primitives include semaphores, monitors,
@@ Line 244: / Line 244: @@
 shared resource by only one process or thread at a time.
 ===Middleware===
-[3*] [6*]
+{{RightSection|{{referenceLink|number=3}} {{referenceLink|number=6}}}}
 Middleware  is  a  broad  classification  for  software that provides services above the operating system layer yet below the application program layer. Middleware can provide runtime containers for software components to provide message passing, persistence, and a transparent location across a network. Middleware can be viewed as a connector between the components that use the middleware.  Modern  message-oriented  middleware usually provides an Enterprise Service Bus (ESB), which supports service-oriented interaction and communication between multiple software applications.
 ===Construction Methods for Distributed Software===
-[7*]
+{{RightSection|{{referenceLink|number=7}}}}
 A distributed system is a collection of physically separate, possibly heterogeneous computer systems that are networked to provide the users with access to the various resources that the system maintains. Construction of distributed software is distinguished from traditional software construction by issues such as parallelism, communication, and fault tolerance. Distributed programming typically falls into one of  several  basic  architectural  categories:  client-server, 3-tier architecture, n-tier architecture, distributed objects, loose coupling, or tight coupling (see section 14.3 of the Computing Foundations KA and section 3.2 of the Software Design KA).
 ===Constructing Heterogeneous Systems===
-[6*]
+{{RightSection|{{referenceLink|number=6}}}}
 Heterogeneous  systems  consist  of  a  variety  of specialized computational units of different types, such as Digital Signal Processors (DSPs), microcontrollers, and peripheral processors. These computational units are independently controlled and communicate with one another. Embedded systems are typically heterogeneous systems.
 The design of heterogeneous systems may require the combination of several specification languages in order to design different parts of the system—in other words, hardware/software codesign. The key issues include multilanguage validation, cosimulation, and interfacing. During the hardware/software codesign, software development and virtual hardware development proceed concurrently through stepwise decomposition. The hardware part is usually simulated in field  programmable gate arrays (FPGAs) or application-specific integrated circuits ASICs). The software part is translated into a low-level programming language.
 ===Performance Analysis and Tuning===
-[1*]
+{{RightSection|{{referenceLink|number=1}}}}
 Code efficiency—determined  by  architecture, detailed design decisions, and data-structure and algorithm selection influences an execution speed and size. Performance analysis is the investigation of a program’s behavior using information gathered as the program executes, with the goal of identifying possible hot spots in the program to be improved. Code tuning, which improves performance at the code level, is the practice of modifying correct code in ways that make it run more efficiently. Code tuning usually involves only small-scale changes that affect a single class, a single routine, or, more commonly, a few lines of code. A rich set of code tuning techniques is available, including those for tuning logic expressions, loops, data transformations, expressions, and routines. Using a low-level language is another common technique for improving some hot spots in a program.
 ===Platform Standards===
-[6*] [7*]
+{{RightSection|{{referenceLink|number=6}} {{referenceLink|number=7}}}}
 Platform standards enable programmers to develop portable applications that can be executed in compatible environments without changes. Platform standards usually involve a set of standard services and APIs that compatible platform implementations must implement. Typical examples of platform standards are Java 2 Platform Enterprise Edition (J2EE) and the POSIX standard for operating systems (Portable Operating  System  Interface),  which  represents a set of standards implemented primarily for UNIX-based operating systems.
 ===Test-First Programming===
-[1*]
+{{RightSection|{{referenceLink|number=1}}}}
 Test-first programming (also known as Test-Driven Development—TDD) is a popular development style in which test cases are written prior to writing any code. Test-first programming can usually detect defects earlier and correct them more easily than traditional programming styles. Furthermore, writing test cases first forces programmers to think about requirements and design before coding, thus exposing requirements and design problems sooner.

@@ Line 192: / Line 192: @@
 ==Construction Technologies==
 ===API Design and Use===
-[3*]
+{{RightSection|{{referenceLink|number=3}}}}
 An application programming interface (API) is the set of signatures that are exported and available to the users of a library or a framework to write their applications.  Besides  signatures,  an  API  should always include statements about the program’s effects and/or behaviors (i.e., its semantics). API design should try to make the API easy to learn and memorize, lead to readable code, be hard to misuse, be easy to extend, be complete, and maintain backward compatibility. As the APIs  usually  outlast  their  implementations  for a widely used library or framework, it is desired that the API be straightforward and kept stable to facilitate the development and maintenance of the client applications. API  use  involves  the  processes  of  selecting, learning, testing, integrating, and possibly extending APIs provided by a library or framework (see section 3.6, Construction with Reuse).
 ===Object-Oriented Runtime Issues===
-[1*]
+{{RightSection|{{referenceLink|number=1}}}}
 Object-oriented  languages  support  a  series  of runtime mechanisms including polymorphism and  reflection.  These  runtime  mechanisms increase the flexibility and adaptability of object-oriented programs. Polymorphism is the ability of a language to support general operations without knowing until runtime what kind of concrete objects the software will include. Because the program does not know the exact types of the objects in advance, the exact behaviour is determined at runtime (called dynamic binding). Reflection is the ability of a program to observe and modify its own structure and behavior at runtime.  Reflection  allows  inspection  of  classes, interfaces, fields, and methods at runtime without knowing their names at compile time. It also allows instantiation at runtime of new objects and invocation of methods using parameterized class and method names.
 ===Parameterization and Generics===
-[4*]
+{{RightSection|{{referenceLink|number=4}}}}
 Parameterized types, also known as generics (Ada,  Eiffel)  and  templates  (C++),  enable  the definition of a type or class without specifying all the other types it uses. The unspecified types are supplied as parameters at the point of use. Parameterized types provide a third way (in addition to class inheritance and object composition) to compose behaviors in object-oriented software
 ===Assertions, Design by Contract, and Defensive Programming===
-[1*]
+{{RightSection|{{referenceLink|number=1}}}}
 An assertion is an executable predicate that’s placed in a program—usually a routine or macro—that allows runtime checks of the program. Assertions are especially useful in high-reliability programs. They enable programmers to more quickly flush out mismatched interface assumptions, errors that creep in when code is modified, and so on.
 Assertions are normally compiled into the code at development time and are later compiled out of the code so that they don’t degrade the performance. Design by contract is a development approach in which preconditions and postconditions are included for each routine. When preconditions and postconditions are used, each routine or class is said to form a contract with the rest of the program. Furthermore, a contract provides a precise specification of the semantics of a routine, and thus helps the understanding of its behavior. Design by contract is thought to improve the quality of software construction. ''Defensive programming'' means to protect a routine from being broken by invalid inputs. Common ways to handle invalid inputs include checking the values of all the input parameters and deciding how to handle bad inputs. Assertions are often used in defensive programming to check input values.
 ===Error Handling, Exception Handling, and Fault Tolerance===
-[1*]
+{{RightSection|{{referenceLink|number=1}}}}
 The way that errors are handled affects software’s ability to meet requirements related to correctness, robustness, and other nonfunctional attributes. Assertions are sometimes used to check for errors. Other error handling techniques—such as returning a neutral value, substituting the next piece of valid data, logging a warning message,
@@ Line 218: / Line 219: @@
 ===Executable Models===
-[5*]
+{{RightSection|{{referenceLink|number=5}}}}
 Executable models abstract away the details of specific  programming  languages  and  decisions about the organization of the software. Different from traditional software models, a specification built in an executable modeling language like xUML  (executable  UML)  can  be  deployed  in various software environments without change.
 An executable-model compiler (transformer) can turn an executable model into an implementation using a set of decisions about the target hardware and software environment. Thus, constructing executable models can be regarded as a way of constructing executable software. Executable models are one foundation supporting the Model-Driven Architecture (MDA) initiative of the Object Management Group (OMG). An executable model is a way to completely specify a Platform Independent Model (PIM); a PIM is a model of a solution to a problem that does not rely on any implementation technologies. Then a  Platform  Specific  Model  (PSM),  which  is  a model that contains the details of the implementation, can be produced by weaving together the PIM and the platform on which it relies.
 ===State-Based and Table-Driven Construction Techniques===
-[1*]
+{{RightSection|{{referenceLink|number=1}}}}
 State-based  programming,  or  automata-based programming, is a programming technology using finite state machines to describe program behaviours. The transition graphs of a state machine are used in all stages of software development  (specification,  implementation, debugging, and documentation). The main idea is to construct computer programs the same way the automation of technological processes is done. State-based  programming  is  usually  combined with  object-oriented  programming,  forming a new composite approach called state-based, object-oriented
 programming. A table-driven method is a schema that uses tables to look up information rather than using logic statements (such as if and case). Used in appropriate  circumstances,  table-driven  code is simpler than complicated logic and easier to modify.  When  using  table-driven  methods,  the programmer addresses two issues: what information to store in the table or tables, and how to efficiently access information in the table.
 ===Runtime Configuration and Internationalization===
-[1*]
+{{RightSection|{{referenceLink|number=1}}}}
 To  achieve  more  flexibility,  a  program  is  often constructed to support late binding time of its variables.  Runtime  configuration  is  a  technique  that binds variable values and program settings when the program is running, usually by updating and reading configuration files in a just-in-time mode. Internationalization  is  the  technical  activity of preparing a program, usually interactive software, to support multiple locales. The corresponding activity, localization, is the activity of modifying a program to support a specific local language. Interactive software may contain dozens or hundreds of prompts, status displays, help messages, error messages, and so on. The design and construction processes should accommodate string  and  character-set  issues  including  which character set is to be used, what kinds of strings are used, how to maintain the strings without changing the code, and translating the strings into different languages with minimal impact on the processing code and the user interface.
 ===Grammar-Based Input Processing===
-[1*] [6*]
+{{RightSection|{{referenceLink|number=1}} {{referenceLink|number=6}}[1*] [6*]
 Grammar-based input processing involves syntax analysis, or parsing, of the input token stream. It involves the creation of a data structure (called a parse tree or syntax tree) representing the input data. The inorder traversal of the parse tree usually gives the expression just parsed. The parser checks the symbol table for the presence of programmer-defined variables that populate the tree. After building the parse tree, the program uses it as input to the computational processes.

@@ Line 96: / Line 96: @@
 ===Construction Design===
-[1*]
+{{RightSection|{{referenceLink|number=1}}}}
 Some projects allocate considerable design activity to construction, while others allocate design to a phase explicitly focused on design. Regardless 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 physical  structure  must  make  small-scale  modifications to account for unanticipated gaps in the builder’s plans, software construction workers
@@ Line 103: / Line 103: @@
 ===Construction Languages===
-[1*]
+{{RightSection|{{referenceLink|number=1}}}}
 Construction languages include all forms of communication by which a human can specify an executable problem solution to a problem. Construction languages and their implementations (for example, compilers) can affect software quality attributes of performance, reliability, portability, and so forth. They can be serious contributors to security vulnerabilities.
@@ Line 124: / Line 124: @@
 ===Coding===
-[1*]
+{{RightSection|{{referenceLink|number=1}}}}
 The following considerations apply to the software construction coding activity:
@@ Line 138: / Line 138: @@
 ===Construction Testing===
-[1*]
+{{RightSection|{{referenceLink|number=1}}}}
 Construction involves two forms of testing, which are often performed by the software engineer who wrote the code:
@@ Line 149: / Line 149: @@
 ===Construction for Reuse===
-[2*]
+{{RightSection|{{referenceLink|number=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 broadbased, 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:
@@ Line 158: / Line 158: @@
 ===Construction with Reuse===
-[2*]
+{{RightSection|{{referenceLink|number=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 language, platform, tools being used, or an organizational repository. Asides from these, the applications 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:
@@ Line 167: / Line 167: @@
 ===Construction Quality===
-[1*]
+{{RightSection|{{referenceLink|number=1}}}}
 In addition to faults resulting from requirements and design, faults introduced during construction can result in serious quality problems—for example, security vulnerabilities. This includes not only faults in security functionality but also faults elsewhere that allow bypassing of this functionality and other security weaknesses or violations. Numerous techniques exist to ensure the quality of code as it is constructed. The primary techniques used for construction quality include
@@ Line 183: / Line 183: @@
 ===Integration===
-[1*]
+{{RightSection|{{referenceLink|number=1}}}}
 A key activity during construction is the integration of individually constructed routines, classes, components, and subsystems into a single system.  In  addition,  a  particular  software  system may need to be integrated with other software or hardware systems.