Lecture 1: Software Construction Fundamentals

1. Definition

Software construction refers to the detailed creation of working software through a

combination of coding, verification, unit testing, integration testing, and debugging. It is
the phase where actual software is built, and it sits between design and testing.

[View Diagram — Design → Construction → Testing flow]

2. Core Concepts and Principles

Course Objectives

● Provide knowledge of different concepts required to create a software system.

● Cover design, coding, and testing together.
● Expose students to tools used in software development.

Why Construction Matters

● It is tool-intensive — IDEs, compilers, debuggers, and testing tools are all heavily
used.
● Quality (or the lack of it) is very visible in construction products.
● It is closely linked to Computer Science because it relies on algorithms and
detailed coding practices.
● Software construction generates the highest number of configuration items in a
project — source files, documentation, test cases, etc.
● Because of this, construction is closely linked to Software Configuration
Management (SCM).

3. The Five Fundamentals of Software Construction

1. Minimizing Complexity
 ● Humans have limited working memory and cannot hold large amounts of
complex information at once.
● As functionality increases, so does complexity — it must be actively reduced
throughout the project lifecycle.
● Achieved through the use of standards such as:
○ J2EE for distributed Java applications.
○ UML for system modeling.
○ High-order languages like C++ and Java.
○ Source code formatting rules for readability.

2. Anticipating Change

● Software changes over time — good construction must account for future
modifications.
● Anticipating change affects:
○ Use of control structures.
○ Handling of errors.
○ Source code organization.
○ Code documentation.
○ Coding standards.

Control Structures — Extra Note

● Control structures specify the flow of control in a program.

● They make algorithms clearer by organizing logic into self-contained modules.
● The program decides which direction to follow based on conditions.
● Example: If (Condition), then: [Module A] Else: [Module B]
[End if structure]

3. Constructing for Verification

● Build software so that bugs can be found and fixed easily.

 ● Techniques include:
○ Enforcing coding standards (helps support code reviews).
○ Writing unit tests.
○ Organizing code to support automated testing.
○ Restricting use of complex or hard-to-understand language structures.

4. Reuse

● Reuse means using existing assets to solve new problems.

● In construction, reusable assets include libraries, modules, components, source
code, and commercial off-the-shelf (COTS) software.
● Best practiced systematically with a well-defined, repeatable process.
● Benefits: improved productivity, better quality, reduced cost.

5. Standards in Software Construction

● Standards directly affecting construction include:

○ Programming language standards — e.g., Java, C++.
○ Communication methods — e.g., document format and content
standards.
○ Platform standards — e.g., operating system interface standards, J2EE.
○ Tool standards — e.g., UML notation standards.

5. Real-World Examples

● Minimizing Complexity: A developer using Java naming conventions

(camelCase) and proper indentation so that teammates can read and maintain
the code easily.
● Anticipating Change: Writing a payment module using an interface so that
switching from one payment gateway to another only requires a new
implementation, not a rewrite.
● Constructing for Verification: Writing JUnit tests for every method in a banking
application so that any regression is caught immediately.
 ● Reuse: Using Apache Commons library for string manipulation instead of writing
utility functions from scratch.
● Standards: A team that follows UML diagrams to ensure all developers
understand the system design the same way.

Lecture 2: Managing Construction

1. Definition

Managing construction involves decisions about how software will be built, in what
order, and how quality and progress will be measured. It includes choosing a lifecycle
model, planning the construction activities, and tracking what gets built.

2. Construction in Life Cycle Models

Two broad categories of lifecycle models exist:

Linear Models [View Diagram — Waterfall Model]

● Examples: Waterfall Model, Staged-Delivery Model.

● Construction occurs only after significant prerequisite work is done —
requirements, design, and planning must be largely complete first.
● Clear separation between phases.
● The main emphasis of construction in these models is coding.
● Advantage: well-documented, predictable.
● Disadvantage: inflexible — late discovery of problems is expensive.

Waterfall Model Phases: Requirements Analysis → Design → Development →

Testing → Maintenance.

Staged-Delivery Model [View Diagram — Staged Delivery]

● Based on the Waterfall Model but delivers the software in stages.

 ● Each stage goes through: Detailed Design → Code → Debug → Test →
Delivery.
● More practical than pure waterfall as it delivers working software incrementally.

Iterative Models [View Diagram — Iterative Process Cycle]

● Examples: Evolutionary Prototyping, Agile Development.

● Construction happens concurrently with requirements, design, and planning.
● Design, coding, and testing are often mixed together.
● More flexible and responsive to change.
● Advantage: early feedback, faster delivery of working software.
● Disadvantage: requires strong team discipline and communication.

Key Point: What counts as "construction" depends on which lifecycle model is used. In
iterative models, construction may include design activities too.

In general, software construction involves:

● Coding and debugging (primary activities).

● Construction planning.
● Detailed design.
● Unit testing.
● Integration testing.
● Other supporting activities.

● 3. Construction Planning

● Choice of construction method — which lifecycle model and approach to use.

● The extent to which prerequisites (requirements, design) must be completed
before coding begins.
● The order in which prerequisites are performed.
● The degree of completion required before construction starts.

The approach to construction affects:

 ● The team's ability to reduce complexity.
● The ability to anticipate change.
● The ability to construct for verification.

Construction planning also defines:

● The order in which components are created and integrated.

● The integration strategy — phased or incremental.
● The software quality management processes.
● Task assignments to specific software engineers.
● Other tasks based on the chosen method.

4. Construction Measurement

Measuring construction activities helps manage the project, maintain quality, and
improve future processes.

Measurable items include:

● Code developed.
● Code modified.
● Code reused.
● Code destroyed.
● Code complexity.
● Code inspection statistics.
● Fault-fix rates and fault-find rates.
● Effort spent.
● Scheduling accuracy.

These measurements are useful for:

● Managing the construction process.

● Ensuring quality during construction.
 ● Improving the construction process over time.

6. Real-World Examples

● Waterfall: A government contract project where all requirements must be

documented and approved before any code is written.
● Staged Delivery: A payroll system where payslip generation is delivered first,
then tax computation, then leave management.
● Iterative/Agile: A mobile app startup building a minimum viable product first,
then adding features every two weeks based on user feedback.

7. Class Tasks from Slides

● Task 1: For a first-time, unique project — choose between linear and iterative
SDLC (answer: iterative, because requirements are unknown and need to
evolve).
● Task 2: For a project developed over five years with known requirements —
choose between linear and iterative (answer: linear, because requirements are
stable and well-understood).
● Task 3: Compare and contrast multiple SDLCs studied in Software Engineering.
Lecture 3: Practical Considerations — Construction
Design and Languages

1. Definition

Practical considerations in construction deal with the real-world constraints that shape
how software is actually built. Construction is more craft-like than other knowledge
areas because it must respond to real, often unpredictable constraints precisely.

2. Construction Design

Key Idea:

● Some projects allocate heavy design activity to the construction phase itself,
while others complete design in a separate dedicated phase.
● Regardless of the approach, some detailed design always happens during
construction.
● This design is dictated by real-world constraints encountered while coding.
● It is applied at a smaller scale: algorithms, data structures, and interfaces.

Analogy: Just as a construction worker building a house may need to make small
adjustments when materials do not match the blueprint, software developers must make
small design decisions while coding to address unexpected gaps.

3. Construction Languages

Definition: Construction languages are all forms of communication by which a human

can specify an executable solution to a problem.

Impact of Language Choice:

● Language and its compiler/interpreter affect performance, reliability, portability,

and security.
 ● Poor language choices (e.g., unchecked use of C or C++) can be a significant
source of security vulnerabilities.

Four Types of Construction Languages:

1. Configuration Languages

● The simplest type.

● Developers select from a limited set of predefined options to create or customize
software.
● Examples: Windows .ini files, Unix configuration files, XML configuration files
(e.g., [Link]).
● [View Diagram — XML Configuration Language Example]
● No deep programming knowledge required.
● Limited flexibility.

2. Toolkit Languages

● More complex than configuration languages.

● Used to build applications from reusable elements in a toolkit (integrated sets of
application-specific reusable parts).
● May be explicitly defined as application programming languages or implied by the
toolkit's interfaces.
● Example: Android SDK provides a toolkit for building mobile applications.

3. Scripting Languages

● Commonly used application programming languages.

● Scripts may be called batch files or macros in some contexts.
● Examples: PHP, Python, [Link], Perl, Ruby.
● Generally interpreted rather than compiled — faster to write but may be slower to
execute.
● Widely used in web development, automation, and system administration.
4. Programming Languages

● The most flexible type.

● Contain the least built-in domain knowledge — require the most training and skill.
● Language choice significantly affects the likelihood of security vulnerabilities.
● Three general notation types used in programming languages:
a. Linguistic Notations
○ Use textual strings to represent complex software constructions.
○ Strings are combined in sentence-like patterns with strong semantic
meaning.
○ Example: Java, C++, Python source code reads almost like English
instructions.
● b. Formal Notations
○ Based on precise, mathematical definitions.
○ Rely less on intuitive everyday language.
○ More important where accuracy, timing, and testability matter over
readability.
○ Use precisely defined symbol combinations to avoid ambiguity.
○ Example: Z notation, mathematical specifications in safety-critical
systems.
● c. Visual Notations
○ Rely on direct visual interpretation — icons and graphical elements
represent the software.
○ Limited by the difficulty of making complex statements using only icons.
○ Powerful for building and adjusting visual interfaces.
○ Example: UML diagrams, drag-and-drop UI builders like Android Studio's
layout editor.

4. Comparison of Construction Language Types

6. Real-World Examples

● Configuration Languages: WordPress [Link] file to configure

multilingual settings.
● Toolkit Languages: Building an Android app using the Android toolkit libraries.
● Scripting Languages: A Python script to automate daily database backups.
● Programming Languages: Writing a banking core system in Java with full OOP
principles.

Lecture 4: Practical Considerations — Coding and

Construction Testing

1. Coding

Key Considerations in the Coding Activity:

● Techniques for understandable source code: Naming conventions and source

code layout rules.
● Use of proper language entities: Classes, enumerated types, variables, named
constants.
● Use of control structures: Blocks that analyze variables and choose execution
paths based on conditions (conditionals/selection, loops, sequence).
● Handling error conditions: Both anticipated errors (e.g., wrong input) and
exceptional errors (e.g., null pointer exceptions, buffer overflows, array index out
of bounds).
● Prevention of security breaches at the code level: Avoiding buffer overflows
and array index violations.
○ [View Diagram — Array index bounds example with double num[10]
and valid index range 0–9]
● Resource usage: Using exclusion mechanisms and discipline when accessing
serially reusable resources like threads and database locks.
 ● Source code organization: Organizing code into statements, routines, classes,
packages, or other meaningful structures.
● Code documentation: Inline comments and documentation that explain the
intent of code.

Code Tuning

● Code tuning is the practice of modifying correct code to make it run more
efficiently.
● It involves small-scale changes — a single class, a single routine, or a few lines
of code.
● Categories of tuning:
○ Logical approaches.
○ Tuning loops.
○ Transforming data.
○ Tuning expressions.
○ Others.

2. Construction Testing

Definition: Testing done by the developer as part of construction to catch bugs early.

Construction involves two forms of testing performed by the software engineer who
wrote the code:

1. Unit Testing

● Testing a single subsystem (class or object) in isolation.

● Goal: find errors in individual components before integration.
● In Java, the JUnit library is commonly used.
● JUnit uses "assert" commands to validate expected behavior.

2. Integration Testing

● Testing individual software modules combined together as a group.

 ● Conducted to evaluate compliance with specified functional requirements.
● Occurs after unit testing and before system testing.

3. Purpose and Scope of Construction Testing

● Purpose: Reduce the gap between when a fault is introduced and when it is
detected — this reduces the cost to fix it.
● Test cases may be written before or after the code (test-first development writes
tests first).
● What construction testing does NOT include: system testing, alpha testing,
beta testing, stress testing, configuration testing, usability testing, and other
specialized forms.
● Two IEEE standards cover construction testing:
○ IEEE Standard 829-1998: Software Test Documentation.
○ IEEE Standard 1008-1987: Software Unit Testing.

4. Important Testing Definitions

Alpha Testing

● First end-to-end testing of a product to verify it meets business requirements.

● Performed by internal employees in a lab or staging environment.
● An initial opportunity to evaluate overall performance and functionality.

Beta Testing

● A type of user acceptance testing.

● A nearly finished product is given to target users to evaluate real-world
performance.

Stress Testing

● Testing pushed to the extreme to find the failure point.

 ● Example: flooding a web application with connections until it crashes.
● The consequences of the crash (what data is corrupted, what else fails) are what
matter.

Configuration Testing

● Testing the software application with multiple combinations of hardware and

software.
● Goal: find the optimal configuration under which the application works without
defects.

Usability Testing

● Also known as User Experience (UX) Testing.

● Measures how easy and user-friendly the software application is.

6. Real-World Examples

● Unit Testing: A developer writes a JUnit test to verify that a calculateTax()

method returns the correct result for various inputs before merging the code.
● Integration Testing: After testing each module of an e-commerce system
separately, the payment module and cart module are tested together to verify
they communicate correctly.
● Alpha Testing: A software company internally tests a new payroll system by
running it with sample employee data before releasing it to clients.
● Beta Testing: A mobile app company releases a pre-launch version of their app
to 500 selected users to gather real feedback.
● Stress Testing: A ticket-booking system is flooded with millions of simultaneous
requests to see at what load it fails.
● Usability Testing: Real users are asked to complete tasks on a banking app
while observers note where they struggle or get confused.
Lecture 5: Practical Considerations — Reuse, Quality,
and Integration

1. Construction for Reuse

Definition: Creating software with the intention that it can be reused in the current or
future projects.

Key Points:

● Takes a broad, multi-system perspective.

● Usually based on variability analysis and design.
● To avoid code clones (duplicate code in multiple places), reusable code should
be encapsulated into well-structured libraries or components.

Tasks Related to Construction for Reuse:

1. Variability Implementation — using mechanisms such as:

○ Parameterization: Taking hardcoded values within a function and turning

them into parameters to generalize the code (also called "extract
parameter" refactoring).
○ Conditional Compilation: Selectively compiling blocks of code based on
conditions (used extensively in C/C++ with #ifdef directives).
○ Design Patterns: General, reusable solutions to commonly occurring
problems in software design (e.g., Singleton, Factory, Observer patterns).
2. Variability Encapsulation — making software assets easy to configure and
customize.

○ Variable factors of a system should be found and encapsulated.

○ A kind of variability should not be scattered across the code but
encapsulated in an object.
 ○ Inheritance is one mechanism for encapsulating change.
3. Testing the variability provided by reusable software assets.

4. Description and publication of reusable software assets so others can find and
use them.

2. Construction with Reuse

Definition: Creating new software by reusing existing software assets rather than
building everything from scratch.

Key Points:

● The most common method is reusing code from language libraries, platform
libraries, or an organizational code repository.
● Applications widely make use of open-source libraries.
● Reused and off-the-shelf software must meet the same — or better — quality
requirements as newly developed software (including security requirements).

Tasks Related to Construction with Reuse:

● Selection of reusable units, databases, test procedures, or test data.

● Evaluation of code or test reusability.
● Integration of reusable software assets into the current software.
● Reporting reuse information about new code, test procedures, or test data.

4. Construction Quality

Key Idea:
 ● Faults introduced during construction (not just design) can cause serious quality
problems — especially security vulnerabilities.
● This includes faults in security functionality AND faults elsewhere that allow
bypassing security.

Primary Techniques for Construction Quality:

● Unit testing and integration testing.

● Test-first development: Writing automated unit tests before writing the
production code itself.
○ Always begin with a unit test.
○ Write a focused test that specifies what the code will do.
○ The test may fail to compile initially — that is acceptable.
○ Write the minimum code needed to make the test pass.
● Use of assertions and defensive programming: Validate assumptions in the
code at runtime.
● Debugging: Finding and fixing bugs after they are detected.
● Inspections: Formal, structured examination of code by peers.
● Technical reviews: Including security-oriented reviews.
● Static analysis: Automated analysis of code without executing it — available for
many languages; especially useful in security-critical projects.

5. Integration
Definition: The process of combining individually built routines, classes, components,
and subsystems into a single working system.

Key Concerns in Integration:

● Planning the sequence in which components will be integrated.

● Identifying what hardware is needed.
● Creating scaffolding (stubs, drivers, mock objects) to support interim versions.
● Determining how much testing and quality work must be done on components
before integration.
● Identifying at what points in the project interim versions of the software should be
tested.

Two Means of Integration:

1. Phased Integration (Big Bang Integration)

● All components are developed separately and then integrated all at once when
all parts are complete.
● Simple to plan.
● Disadvantage: When something fails, it is very difficult to locate the source of the
error because everything was integrated at once.

2. Incremental Integration

● Components are written, tested, and combined one unit at a time.

● Requires additional test infrastructure: stubs (placeholder for missing modules),
drivers (code that calls a module under test), and mock objects (fake objects that
simulate real ones).
● Advantages:
○ Easier error location.
○ Improved progress monitoring.
○ Earlier product delivery.
○ Improved customer relations.
 ○ More fully tested units.
○ Early feedback to both developers and customers.

7. Real-World Examples

● Construction for Reuse: A developer at a software house builds a validation

library (email format, phone number format) that can be reused across all
company projects.
● Construction with Reuse: A new web application uses the Hibernate ORM
library instead of writing raw SQL queries from scratch.
● Test-first Development: A developer writing an authentication module writes the
test for login() before writing the actual login code, ensuring the code always
satisfies its specification.
● Static Analysis: A security team runs SonarQube on a banking application's
codebase to detect potential SQL injection vulnerabilities before deployment.
● Incremental Integration: A team building an online shopping system integrates
the product catalog first, then adds the cart, then the payment module — testing
after each addition.
● Big Bang Integration: A small team building a simple academic project
completes all modules separately and then combines them all at the end for final
testing.