Chapter 7

Constructing DigitalHome

Note: The Preface includes the statement “It is assumed the audience has some basic understanding of the nature of computing, and can use fundamental program constructs (sequence, selection, and repetition) and write simple programs in a high-level object-oriented programming language (such as Java)”. So, in this Chapter, basic programming concepts and techniques are not covered, and certain construction principles are illustrated using the Java programming language.

Build/Integration Plan

In Chapter 2, the DigitalHome Development Process was introduced (now reproduced in Table 7.1). The process includes the development of a Build/Integration Plan. The plan would detail an incremental development approach, which would include the activities specified in the “Construction Increment 1, 2,...” section. These construction activities make up what is often referred to as Software Construction, as described in Chapter 3 of the SWEBOK [Bourque 2014]: “The term software construction refers to the detailed creation of working software through a combination of coding, verification, unit testing, integration testing, and debugging”.

Table 7.1 *DigitalHome* Development Process Script
Purpose	Guide the development of the DigitalHome software system
Entry Criteria	Identification of a problem or opportunity, which may need a software solution
Phase	Activity
Project Inception	Establish the business case and feasibility for the project. Determine the scope of the project. Develop a customer Need Statement. Develop a High-Level Requirements Document
Project Launch	Establish development team, and their roles, responsibilities, and goals. Analyze Need StatementEstablish a Development Process Identify External Interfaces and create a Context Diagram Create a Conceptual Design Determine a Development Strategy Research and study of possible project technology
Planning	Develop Task, Schedule, and Resource Plans Develop a Risk Plan Develop a Quality Plan Develop a Configuration Management (CM) Plan Determine project standards and tools Perform project planning/tracking
Analysis	Review the Need Statement and prepare for requirements elicitation Elicit requirements from potential customers and users Analyze requirements and build object-oriented analysis models Specify and document requirements in a Software Requirements Specification (SRS) Inspect and revise the SRS Obtain customer agreement to requirements Develop a System Test Plan Develop a Requirements Traceability Matrix (RTM) Develop a User Manual Track, monitor, and update plans (Task/Schedule/Quality/CM/Risk) & RTM
Architectural Design	Develop an Object-Oriented (OO) high-level design model Refine the OO analysis model Develop additional design models Specify and document design in an Software Design Specification (SDS) Develop a Build/Integration Plan Review and revise the SDS Consult with customer, and revise SRS and SDS, as appropriate Track, monitor, and update plans (Task/Schedule/Quality/CM/Risk) & RTM
Construction Increment 1, 2,...	Complete Class Specifications (data types and operation logic) Develop incremental Integration Test Plan (Class/Integration) Set up an appropriate test environment (e. g., test harness, stubs/drivers)
Construction Increment 1, 2,...	Review the Class Specifications Write source code Review and test the source code Integrate code with previous increments Perform Increment (Class/Integration) Test Consult with customer, and revise SRS, SDS, and code, as appropriate Track, monitor, and update plans (Task/Schedule/Quality/CM/Risk) & RTM
System Test	Update test environment Update System Test Plan Perform the System Test Consult with customer, and revise requirements, design and code as appropriate Track, monitor, and update plans (Task/Schedule/Quality/CM/Risk) & RTM
Acceptance Test	Prepare Acceptance Test materials (including a user’s manual) Set up customer test environment Customer performs Acceptance Test Revise SRS, SDS, code, and User Manual as appropriate Track, monitor, and update plans (Task/Schedule/Quality/CM/Risk) & RTM
Postmortem	Perform postmortem analysis of project process and product quality
Exit Criteria	Completed SRS, SDS, RTM, User Manual, System Test Plan Source code for a thoroughly reviewed and tested program Completed plan documentation Project postmortem report

In a team meeting following the specification of the DH Architecture, Disha Chandra asked Massood Zewail to lead the effort to develop a Digital Home Build/Integration Plan. Massood presented a high-level diagram (see Figure 7.1) and led a discussion of how to break the software construction into increments and develop a Build/Integration Plan.

Construction Fundamentals

After the team completed a DH Build/Development Plan, Disha Chandra said to the team “I know you are all have experience constructing and testing software modules, but I think it would be good for us to review some fundamentals of software construction”. Disha asked Georgia Magee to prepare and deliver a tutorial on Software Construction.

MiniTutorial 7.1: Software Construction Fundamentals

Georgia began with a discussion of how to construct the software for the example ATM system depicted in Figure 7.2. For example, suppose one wanted to construct the class BankAccount. Here are some of the activities, which would need to be carried out:

Figure 7.2 ATM class diagram.

■ Plan for testing and integration of the class with the rest of the ATM system. If a Build/Integration Plan has been developed, this provides the appropriate foundation for this step.
■ Complete Class Specifications (data types and method specification) for Customer, Money, BankAccount, and the other classes in Figure 7.2. This might include the addition of new fields and methods.

For example, in Figure 7.2 the Customer class would need the specification of the data types for the attributes name, address, and SSN. Also, the methods in the class would need to be determined (e.g., a changeAddress method).

■ Develop the detailed design and write the source code for each method.

A first step might be the specification of pre-conditions and post-conditions (covered later in this Chapter).

The use of pseudocode for detailed design of the method (especially for complicated methods) would describe the method logic without concern about language syntax. (The approach of test-driven design is covered later in this Chapter).

■ Review and test the source code for each method. A rigorous review will reduce overall development time and improve system quality. (See Chapter 3 for more detail.)
■ Set up an appropriate test environment (e. g., test harness, stubs/drivers). (See Chapter 3 for more detail.)
■ Integrate the code with previous increments of the system. For example, a Build/Integration Plan for the ATM would specify the order of construction and integration.
■ Perform an Increment (Class/Integration) Test. (This is discussed later in this chapter.)

Exercise 7.2: Specifying a DH Class

After Georgia’s tutorial on software construction, the team reviewed the Design Diagram in Figure 7.1, the team began a discussion of a more detailed specification of the MonthPlan class. The exercise, described at the end of this chapter, deals with how the MonthPlan class would be specified with more detail.

Unit Construction

The DigitalHome team decided to use an object-oriented methodology for design and construction, with Java as the implementation language. A Java method is the fundamental implementation unit. Team Leader Disha Chandra asked Georgia Magee to continue her tutorial on software construction by addressing issues specifically related to constructions of a Java method.

MiniTutorial 7.2: Method Construction

Pre-conditions and Post-conditions

A pre-condition is a condition that must be true before a method is called. For example, in the ATM system (Figure 7.2), consider the BankAccount method withdraw (amount: Money). A pre-condition for withdraw would be “amount <= balance”.

A post-condition is a condition that must be true after a method is executed. Consider the BankAccount method deposit (amount: Money) would be new balance = old balance + amount.

Unit Testing

Unit testing is used to determine defects when executing code for a software unit. A test plan for unit testing would consist a set of test cases, where a test case tests a single feature of the unit. There is more information about Unit Testing in Chapter 3.

In Chapter 2, we discuss the eXtreme Programming (XP) process [Beck 2000]. One of XP’s features is Test-Driven Development (TDD). TDD is a development process for a software unit (e.g., a class method) that consists of several very short development cycles, where each cycle consists of the following steps:

■ Create a unit test case, testing a single feature of the unit (not yet in the unit).
■ Run the test, which should fail because the program lacks that feature.
■ Modify the unit code just to make the test run correctly.
■ “refactor” the code (clean it up), so that it is manageable (it may need new variable names, additional documentation, or be divided into multiple units).
■ Repeat the above steps and aggregate the test cases in a single test plan.

A similar but less comprehensive approach is to write the entire unit test plan before one begins writing any code. This has the following advantages:

■ It motivates the developer to carefully review the requirements for the unit.
■ Test planning for possible execution errors early-on prompts the developer to write code for exception handling.
■ Since a test plan has to be created at some point, doing this before unit coding is no costlier than waiting until after the code is written.

For example, suppose a developer was writing the code for the withdraw (amount: Money) method in Figure 7.2. She could create a test plan like the one in Figure 7.3.

Figure 7.3 BankAccount test plan.

Algorithm Description Using Pseudocode

Pseudocode is a notation resembling a simplified programming language, which is used to depict the logic and structure of a program’s design. Some of the advantages of using pseudocode are as follows:

■ The program designer can concentrate on the algorithm for the program, and not be distracted by programming style and syntax.
■ The pseudocode can be translated in different programming languages without modification.
■ The pseudocode can be reviewed for requirements and logic errors.

Figure 7.4 shows a pseudocode for a program than that computes the greatest common divisor for two integers.

Figure 7.4 GCD algorithm.

Figure 7.5 shows the Java method based on the GCD pseudocode.

Figure 7.5 GCD java code.

Coding Standards

Code documentation is an important element of unit construction. Good documentation, using a coding standard, can have the following advantages:

■ Provide the developer with structure and layout, which eases the code developing and organizing efforts.
■ Improve the readability of the code by those other than the developer.
■ Makes maintenance of the unit easier.
■ Improves tracing and correcting execution.

Although there are a number of coding standards for Java, one of the first and most widely used is Java Code Conventions [Sun 1997]. It provides information on the following:

■ Declaration format for classes, methods, and variables.
■ Comment advice and style.
■ Statement format and naming conventions.
■ Use of indentation, white space, and line length to improve readability.

Code Review

As we discussed in Chapter 3, software quality is difficult and expensive to achieve when developers depend solely on software testing. Software inspection and reviews are cost-effective ways to detect and correct defects. This includes unit development; unit testing is essential, but review of the unit code will produce a higher quality product and reduce testing time.

Table 7.2 provides a checklist of activities to be performed in a code review of unit code. The checklist is based on ideas presented in [Humphrey 1995].

Table 7.2 *DigitalHome* Code Review Guide
Purpose		Guide the review of DigitalHome Software Unit Code
Entry Criteria		Completion of the code for software unit, such as for a class method
Step	Activities	Description
1	Completeness	Check the program against the requirements specification (SRS) to ensure that it includes all required functionality. Check the program against the design specification (SDS) to ensure that all required unit interfaces and functionality are implemented.
2	Checklist	Use the following code review checklist to find all the defects in the program: Verify that the program flow and all function logic are consistent with the detailed design. Trace through all loops and recursive operations. Ensure that every loop is properly initiated and terminated. Check that every loop is executed the correct number of times. Check every method call to ensure that it exactly matches the definition for formats and types. Verify that each variable and parameter has exactly one declaration and is only used within its declared scope. Check all variables, arrays, and indexes to ensure that their use does not exceed declared limits. Check all begin-end pairs, including cases where nested ifs could be misinterpreted. Check Boolean conditions. Check every statement for instruction format, spelling, and punctuation. Check that all pointers are properly referenced. Check all input-output formats. Check that every variable, parameter, and key word is properly spelled. Ensure that all commenting is accurate and according to standard. Check that unit structure is comprehensible with appropriate use of indentation and white space.
3	Corrections	Keep a log of the defects found; and following the code review, correct all the defects.
4	Final check	All the defects found have been corrected. The corrections have been checked for correctness.

Exercise 7.3: Pre-conditions and Post-conditions of a DH Class

After Georgia’s tutorial on Method Construction, the team discussed and determined the pre-conditions and post-conditions for a DH class. The exercise, described at the end of this chapter, deals with how the DH Team decided on these conditions.

Exercise 7.4: Test Planning for a DH Unit

After Georgia’s tutorial on Method Construction, the team discussed and agreed on their test planning strategy. The exercise, described at the end of this chapter, deals with how the DH Team creates a test plan for a class method.

Exercise 7.5: Developing a DH Unit

After Georgia’s tutorial on Method Construction, the team discussed development of DH class methods. The exercise, described at the end of this chapter, deals with how the DH Team members would develop a class method.

Disha Chandra asked Georgia Magee to continue her tutorial on software construction by addressing issues related to writing code that does have security weaknesses.

MiniTutorial 7.3: Secure Coding

Secure coding is the practice of developing program code so that it protects against the introduction of security weaknesses into the software. Defects and logic flaws are typically the cause of common software vulnerabilities.

The SEI CERT (Software Engineering Institute Computer Emergency Response Team) partners with government, industry, law enforcement, and academia to improve the security and resilience of computer systems and networks. On the website (https://wiki.sei.cmu.edu/confluence/display/seccode/) there are coding standards for commonly used programming languages such as C, C++, Java, and Perl, and the Android™ platform. The site also discusses the Top 10 Secure Coding Practices, listed in Table 7.3.

Table 7.3 Top Ten Secure Coding Practices
Validate input. Validate input from all untrusted data sources.
Heed compiler warnings. Compile code using the highest warning level available for your compiler and eliminate warnings by modifying the code.
Architect and design for security policies. Create a software architecture and design your software to implement and enforce security policies.
Keep it simple. Keep the design as simple and small as possible. Complex designs increase the likelihood that errors will be made in their implementation, configuration, and use.
Default deny. Base access decisions on permission rather than exclusion. This means that, by default, access is denied and the protection scheme identifies conditions under which access is permitted.
Adhere to the principle of least privilege. Every process should execute with the least set of privileges necessary to complete the job. Any elevated permission should only be accessed for the least amount of time required to complete the privileged task.
Sanitize data sent to other systems. Sanitize all data passed to complex subsystems such as command shells, relational databases, and commercial off-the-shelf (COTS) components.
Practice defense in depth. Manage risk with multiple defensive strategies, so that if one layer of defense turns out to be inadequate, another layer of defense can prevent a security flaw from becoming a vulnerability.
Use effective quality assurance techniques. Good quality assurance techniques can be effective. Adopt a secure coding standard. Develop and/or apply a secure coding standard for your target development language and platform.

A classic example of a a secure coding problem is the buffer overflow problem. Buffer overflow occurs when data is input or written beyond the allocated bounds of an object causing a program crash or creating a vulnerability that attackers might exploit.

Exercise 7.6: Buffer Overflow Problem

After Georgia’s tutorial on Secure coding, the team discussed the buffer overflow problem development. The exercise, described at the end of this chapter, deals with how the DH Team members created code that exhibited the buffer overflow problem.

Case Study Exercises

Exercise 7.1: Developing Build/Integration Plan

Scenario

After the team reviewed the Design Diagram in Figure 7.1, the team discussed development of a DH Build/Development Plan. This exercise deals with how the DH Team developed the plan.

Learning Objectives

Upon completion of this module, students will have increased ability to:

Describe and discuss a Build/Development Plan.
Separate design and development features into increments.
Create a plan for design, construction, and integration of a software system.

Exercise Description

This exercise follows a lecture on the Digital Home Build/Integration Plan.
As preparation for this exercise students are required to read the following:
- DH Beginning Scenario
- DigitalHome Need Statement
- DigitalHome Software Requirements Specification

Students are grouped into teams of 3–4.

Each team reviews and discusses the Architectural Design and Construction portions of Table 7.1 and Figure 7.1.
Each team decides on the number of construction increments and selects which elements of Figure 7.1 will be assigned to each increment.
Each team creates a DH Build/Design Plan with a schedule for order of development and integration of each increment (including the estimated duration for construction of each increment).
The team presents its findings to the rest of the class.

Exercise 7.2: Specifying a DH Class

Scenario

After the team reviewed the Design Diagram in Figure 7.1, the team began a discussion of a more detailed specification of the MonthPlan class.

Learning Objectives

Upon completion of this module, students will have increased ability to:

Describe and discuss how a Java class should be specified.
Better understand DigitalHome specification and implementation.
Create a plan for design and development of a software system.

Exercise Description

As preparation for this exercise students are required to read the following:
- DH Beginning Scenario
- DigitalHome Need Statement
- DigitalHome Software Requirements Specification (with special attention to Section 4.6)

Students are grouped into teams of 3–4.

Each team reviews and discusses the Architectural Design and Construction portions of Table 7.1 and Figure 7.1.
Each team reviews and discusses the MonthPlan class in of Figure 7.1 using the below questions:
- Why are year and month specified as type int?
- How should an attribute like thermostatSettings be specified?
- How should the method setYear() be specified (i.e., the specification of the method header)?
- What attributes or methods should be added to MonthPlan?
Each team creates a report about its findings.
The team presents its findings to the rest of the class.

Exercise 7.3: Pre-conditions and Post-conditions of a DH Class

Scenario

After the team reviewed the Design Diagram in Figure 7.1, the team began a discussion of pre-conditions and post-conditions of the class ContactSensorsControl.

Learning Objectives

Upon completion of this module, students will have increased ability to:

Describe and discuss pre-conditions and post-conditions.
Identify DigitalHome pre-conditions and post-conditions.
Develop error-free methods.

Exercise Description

As preparation for this exercise students are required to read the following:
- DH Beginning Scenario
- DigitalHome Need Statement
- DigitalHome Software Requirements Specification (with special attention to Section 4.4)
Students are grouped into teams of 3–4.
Each team reviews and discusses the ContactSensorsControl class in of Figure 7.1, and identifies appropriate pre-conditions and post-conditions for the methods.
Each team creates a report about its findings and presents it to the rest of the class.

Exercise 7.4: Test Planning for a DH Unit

Scenario

After the team reviewed the Design Diagram in Figure 7.1, they discussed and agreed on their test planning strategy. This exercise deals with how each DH Team member would create a test plan for the numMonthDays method in the MonthPlan class. The following is a brief specification for the method:

/**********************************************************************

Name: numMonthDays

Purpose: sets the values of the Year and Month fields and returns the

number of days in that Year and Month *

****************************************************** *****************/

public static int numMonthDays() throws IOException {

Note: the setMonth and setYear methods zin MonthPLan are used in this method.

Learning Objectives

Upon completion of this module, students will have increased ability to:

Plan tests for units of code.
Develop error-free methods.
Understand DigitalHome functionality.

Exercise Description

As preparation for this exercise students are required to read the following:
- DH Beginning Scenario
- DigitalHome Need Statement
- DigitalHome Software Requirements Specification (with special attention to Section 4.6)
Teams of 3–4 are formed and members work individually on a test plan.
Each team reviews and discusses the numMonthDays method in the MonthPlan class, in Figure 7.1, and individuals develop test plans for the method.
When test plans are completed, the team compares and contrasts their plans.
The team reports on their test planning to the rest of the class.

Exercise 7.5: Developing a DH Unit

Scenario

After the team reviewed the Design Diagram in Figure 7.1, they discussed class method development. This exercise deals with how each DH Team member would develop the numMonthDays method in the MonthPlan class. The following is a brief specification for the method:

/**********************************************************************

Name: numMonthDays

Purpose: sets the values of the Year and Month fields and returns the

number of days in that Year and Month *

****************************************************** *****************/

public static int numMonthDays() throws IOException {

Note: the setMonth and setYear methods in MonthPLan can be used in this method.

Learning Objectives

Upon completion of this module, students will have increased ability to:

Develop units of code.
Develop error-free methods.
Understand DigitalHome functionality.
Perform a code review of a unit of code.

Exercise Description

As preparation for this exercise students are required to read the following:

DH Beginning Scenario
DigitalHome Need Statement
DigitalHome Software Requirements Specification (with special attention to Section 4.6)

Teams of 3–4 are formed and members work individually on method development.

Each team reviews and discusses the numMonthDays method in the MonthPlan class, in Figure 7.1, and individuals develop the following:
- A pseudocode algorithm for the numMonthDays method.
- The source code for the numMonthDays method. Use Java or some other object-oriented programming language.
When code reviews are completed, the team compares and contrasts their reviews.
The team reports on their code development activities to the rest of the class.

Exercise 7.6: Buffer Overflow Problem

Scenario

After Georgia’s tutorial on Secure coding, the team discussed the buffer overflow problem. Each DH Team member was asked to create code that exhibited the buffer overflow problem.

Learning Objectives

Upon completion of this module, students will have increased ability to:

Understand the buffer overflow problem.
Develop error-free code.
Understand the importance of secure coding.
Perform a code review of a unit of code.

Exercise Description

Teams of 3–4 are formed and members work individually on developing an example method that has a buffer overflow problem.
Each team reviews and discusses the examples of buffer overflow code.
The team reports on their code development activities to the rest of the class.