SE 324 - Software Construction

SOFTWARE CONSTRUCTION
FUNDAMENTALS

Originally prepared by Dr. Ftoon Kedwan, and Adapted by Dr. Khaled Khankan

1
 Objectives

After completing this module, you should be able to…

• Define the “software construction”.
• Discuss how to plan for software construction.
• Discuss the code design important factors that effect the
size, cost, and schedule for software construction.

2
 Software Processes
A Software Process is:
A set of activities (e.g., requirements, analysis, design, coding, testing)
combined & sequenced in a particular fashion to produce software.

Are you are of the Agile Software Development methods?

3
 Software Construction - Overview

Detailed creation of working meaningful software through a combination

of coding, verification, unit testing, integration testing, & debugging.

Software construction closely tied to:

• Software Design
• Software Testing

Design

Construction

Testing

4
 Overview, Cont.
During construction:
• Detailed design might occur.
• Low-level (e.g., unit & module integration)
• Unit testing occurs

Construction Activity Affiliations:

While detailed design happens prior to construction, additional design work might be also
performed within the construction activity itself. Thus, the software construction activity is
closely linked to the software design activity.

5
 Software Construction Fundamentals

The Fundamentals of Software Construction include:

1. Minimizing complexity *
2. Anticipating change *
3. Constructing for verification
4. Standards in construction

* Apply to design as well as to construction.

6
 1- Minimizing Complexity
• As functionality increases, so does complexity.

• Minimizing complexity is a strong driver in software construction. This is

accomplished through use of standards, & through numerous specific coding
techniques. It is also supported by the construction-focused quality techniques.

• The need to reduce complexity applies to essentially every aspect of

software construction and is particularly critical to the process of
verification & testing of software constructions.

• In software construction, reduced complexity is achieved through

emphasizing the creation of code that is simple & readable rather than
clever.

• Are you familiar with the following?

o UML for modeling all aspects of complex systems.
o High-level programming languages, such as C++ & Java.
o Source code formatting rules to aid readability.
o J2EE for complex distributed Java applications. 7
 2- Anticipating Change

Anticipating change is supported by many specific techniques such as:

o Source code organization (into statements, routines, classes, packages, or
other structures).
o Handling of error conditions, both planned errors & exceptions (i.e., input of
bad data).
o Code documentation, techniques for creating understandable source code,
including naming & source code layout.
o Coding standards, use of classes, enumerated types, variables, named
constants, & other similar entities.
o Prevention of code-level security breaches (e.g., buffer overruns or array
index overflows).
o Code tuning.
o Use of control structures.

8
 3- Constructing for Verification

• Construct software that allows bugs to be easily found & fixed.

• Constructing for verification means building software in such a way

that faults can be hunted out readily by the software engineers writing the
software, as well as during independent testing & operational activities.

• Specific techniques which support constructing for verification include:

o Enforce coding standards. This helps/ support code reviews.
o Unit testing.
o Organizing code to support automated testing.
o Restricted use of complex or hard-to-understand language structures.

9
 4- Standards in Construction

• Standards in software development are important because they bring

consistency for the process & product.

• Standards which directly affect construction issues include internal &

external standards.

• Use of Internal Standards:

Standards may also be created on an organizational basis at the corporate
level or for use on specific projects.

• Use of External Standards:

o Construction Programming languages E.g., standards for languages like Java & C++.
o Communication methods E.g., standards for document formats & contents.
o Technical Interfaces’ Platforms E.g., programmer interface standards for operating system calls, J2EE.
o Construction Tools

10
Construction Planning

11
 Construction Planning

• What is Construction Planning?

Laying out the work plan (i.e., schedule) to design, implement, debug, &
unit test the software.

• Planning for software construction is important, and a schedule must be in

place in order to guide design, implementation, unit test/debug, &
integration & make mid-course corrections if necessary.

• Reduce the development costs by planning to:

1. Reduce the size &/or complexity.
2. Improve the development process.
3. Use more highly skilled people & build better teams.
4. Use better tools.
5. Reduce quality thresholds.

12
 Construction Planning, Cont.
Improving Software Economics:
1. Size/Complexity
o Use an object-oriented approach.
o Focus on reuse.
o Look for opportunities to use commercial off-the-shelf (COTS) components.

2. Development Process
o Use an iterative approach.
o Improve the process maturity.
o Focus on architecture early in the life cycle.

3. People/Teams
o Provide appropriate training for development teams.
o Encourage teamwork.
o Create a win-win culture.

13
 Construction Planning, Cont.

Problem Definition Prerequisite

The first prerequisite before beginning construction is a clear defined
statement of the problem that the system is supposed to solve.

• A problem definition defines what the problem is without any reference

to possible solutions.
o Helps avoid solving the wrong problem!
o Without a good problem definition, you might put effort into solving the
wrong problem.

• The problem definition should be in user language and should be

described from a user's point of view.

14
 Construction Planning, Cont.
Choose Construction Practices
• Part of preparing for construction is deciding which of the available
practices will be emphasized.

• The right choice is guided by the specific circumstances of the project.

• Questions regarding practices before any code construction:

o How detailed will the design be?
o What are the coding conventions for names, comments, layout, etc.?
o How will the architecture be enforced?
o Is the project’s use of technology ahead of or behind the power curve, & is
this appropriate given the circumstances?
o What is the integration procedure, how often is it done, & who participates?
o Will developers program individually, in pairs, test-first development, solo
development with formal inspections, or some combination of this?
o Where & when will builds occur?
15
 Construction Planning, Cont.

More Questions:
o Have you defined how much design will be done up front & how much will
be done at the keyboard while code is being written?

o Have you defined specific coding practices that are implied by the
architecture, such as:
▪ How error conditions will be handled?
▪ How security will be addressed?
▪ What conventions will be used for class interfaces?
▪ What standards will apply to reused code?
▪ How much to consider performance while coding?

o Have you identified your location on the technology wave &

adjusted your approach to match?
o Have you defined the specific steps a programmer must go
through before checking code into the master repository?
16
 Construction Planning, Cont.

Choosing Tools
• Modern programming tools:
o Are essential to maintain programmer productivity.
o Reduce tedious & redundant tasks.
o Must be appropriate for the task at hand.
o Decrease the amount of time required for construction.

• Tools preparation checklist:

o Are all product licenses current?
o Are all products at current, supported revision level?
o Have all programmers received proper training on the tools?
o Does the project have a configuration management tool?
o Does the project have a tool to track change requests?
o Do project team members have sufficient workstations?
o Does the project have sufficient test environments?
o Does the project have sufficient build environments?
o Is there an available integrated development environment (IDE) that is appropriate for the
project?
o Does the project have appropriate third-party code libraries to reduce custom-written code?

• Use of appropriate toolset (with the appropriate training) can increase productivity by
17
50% or more.
Code Design

18
 Desirable Code Design Characteristics
• The following are desirable code design characteristics:
o Minimal complexity
o Ease of maintenance
o Loose coupling
o Extensibility
o Portability
o Standard techniques

• The more characteristics the detailed design team can employ, the better
the design will be.

19
 Desirable Code Design Characteristics, Cont.
How to Overcome Complexity:
• “Separation of concerns” allows developers to focus on 1 bit of
complexity at a time.

• Humans can much more easily comprehend several small pieces

compared to 1 big piece.

• Ineffective designs come from 3 sources:

o A complex solution to a simple problem.
o A Simple, incorrect solution to a complex problem.
o An inappropriate, complex solution to a complex problem.

20
 Desirable Code Design Characteristics, Cont.

• Minimal Complexity:
o The primary goal of design should be to minimize complexity for all the reasons
provided earlier.
o Avoid making "clever" designs because they are usually hard to understand.
o Instead make "simple" & "easy-to-understand" designs.
o If your design doesn't let you safely ignore most other parts of the program
when you're immersed in 1 specific part, the design isn't doing its job.

• Ease of Maintenance:
o This means designing for the maintenance programmer.
o Use common programming constructs & consistent naming conventions.
o Continually imagine the questions a maintenance programmer would ask about
the code you're writing.
o Think of the maintenance programmer as your audience, & then design the
system to be self-explanatory.

21
 Desirable Code Design Characteristics, Cont.
• Loose Coupling:
o Reduce interdependencies within the code.
o This means designing so that you hold connections among different parts of a
program to a minimum.
o Use the principles of good abstractions in class interfaces, encapsulation, &
information hiding to design classes with as few interconnections as possible.
o Minimal connectedness minimizes work during integration, testing, &
maintenance.

• Extensibility:
o Minimal ripple effect when changes are made.
o Extensibility means that you can enhance a system without causing violence to
the underlying structure.
o You can change a piece of a system without affecting other pieces.
o The most likely changes cause the system the least trauma.
o Ideally, changes will have minimal ripple effect & certainly won’t have tidal
wave effect.
22
 Desirable Code Design Characteristics, Cont.

• Standard Techniques
o Stay with the “tried & true”.
o The more a system relies on exotic pieces, the more intimidating it is for
someone trying to understand it the first time.
o Try to give the whole system a familiar feeling by using standardized, common
approaches.

23
 Levels of Code Design

As you know from SE 323, there are five levels of abstraction in software
design:
1. Level 1 – Software System*
2. Level 2 – Subsystems*
3. Level 3 – Classes**
4. Level 4 – Routines
5. Level 5 – Internal Routine Design

* A concern of the architect, not object designer, unless system is

extremely small & not overly complex.
** Design at this level includes identifying all classes in the system,
relationships between classes, and finally, the interface for each class.

24
 Code Design Techniques

The design techniques (heuristics) that can improve any software

design, include:

• Find Real-World Objects

• Form Consistent Abstractions
• Encapsulate Implementation Details
• Apply Inheritance
• Hide Internal Information
• Identify Areas Likely to Change
• Ensure Loose Coupling
• Apply Design Patterns

25
SOFTWARE CONSTRUCTION
FUNDAMENTALS
Part II
 Outline

• Data Design and Management

• Stages of Data Modeling
• Error Processing
• Source Code Organization
• Construction Quality Assurance
• System Integration & Deployment
• Code Tuning
• Code Documentation
• Approaches to Software Development
27
 Data Design and Management

What is Data Design?

• A method used to define & analyze data requirements needed to
support the business functions of an enterprise.
• These data requirements are recorded as a conceptual data model
with associated data definitions.
• Data Design & modeling defines the relationships between data
elements & structures.

What is Data Management?

The act of ensuring DataBase (DB) integrity, security, performance, and
recovery of data.

28
 Data Design and Management, Cont.

Stages of Data Modeling:

The data model evolves through 3 stages:

1. Conceptual
2. Logical
3. Physical

29
 Debugging

Debugging:
The process of identifying the root cause of an error & correcting it.

How to debug?
o Learn in-depth how the program you are working on operates.
o Learn the kinds of mistakes you typically make.
o Learn how to solve software problems.
o Steps of code debugging are:
1. Gather data through repeatable experiments.
2. Form a hypothesis that accounts for as much of the relevant data as possible.
3. Design an experiment to prove or disprove the hypothesis.
4. Prove or disprove the hypothesis.
5. Repeat as needed.

30
 Construction Quality Assurance (QA)

• Software Quality Assurance:

A planned & systematic pattern of all actions necessary to provide adequate
confidence that the software & the delivered documentation conforms to
established technical requirements. e.g., ANSI/IEEE Standard.

• Construction Quality Assurance (QA) :

Those QA techniques necessary to assure that coding is being done according to
coding standards.

• Quality Attributes:
A requirement that specifies the degree of an attribute affecting qualities that the
software must possess. e.g., correctness, reliability, maintainability, portability.

31
 Techniques for Improving Code Quality

• To improve the quality of the product you must improve the quality of the
process. Although it might seem that the best way to develop a high-quality
product would be to focus on the product itself, in software quality assurance the
best place to focus is on the process.

• Institute a set of coding guidelines/standards for the development of

code.

• Institute code walkthroughs or inspections.

• Institute a verification & validation (V&V) process to verify code.

32
 Construction Techniques

• The Primary techniques used for construction include:

a) Unit testing & integration testing
b) Test-first development
c) Code stepping
d) Use of assertions
e) Debugging
f) Technical reviews
g) Static analysis

• The specific techniques selected depend on the nature of the software being
constructed, as well as on the skills set of the software engineers performing the
construction.

• Construction quality activities are differentiated from other quality activities by

their focus on code & on artifacts that are closely related to code. Small scale
designs, as opposed to other artifacts which are less directly connected to the code, such
as requirements, high-level designs, & plans.
33
 System Integration & Deployment

System Integration:
• The act of merging a software element or elements with another element.
• The act of merging a hardware component or components with another
hardware component.
• The act of merging software configuration items with hardware configuration
items in order to produce a total system which satisfies customer
requirements.

Types of Integration Techniques:

• All in one integration (a.k.a. the “big bang” integration)
• Incremental integration
• Top-down integration
• Bottom-up integration
• Sandwich integration

34
 1. Big Bang Integration

• All components, modules, & subsystems are combined & integrated at

one time.

• This is called the “big bang” because it frequently blows up.

• If (and when) the system fails to integrate, it is next to impossible to

determine the cause.

• This is called the “smoke test” in the hardware world.

“Let’s put the power to it & see where the smoke rises”.

• Unfortunately, there is no smoke to indicate a fault in software.

35
 2. Incremental Integration

1. Develop a small core of the system.

2. Test & debug it.

3. Design, code, test, & debug another part (module, routine, etc.)

4. Integrate the new part with the core.

5. Ensure that the new partial system works.

6. Repeat steps 3 through 5 until finished.

36
 Software Deployment

• Software Deployment: is the delivery & implementation of a software

system, usually to the customer who purchased the system.

• Deployed systems have been factory (alpha) tested.

• Deployment may be on a “try it & see basis” (called a beta test) or for
permanent installation.

• Deployed systems are placed under external configuration management.

• Deployed systems may be maintained by either the original developer or

a third party.

37
 Code Tuning

• The practice of modifying correct code to make it run more efficiently.

• Code tuning is the enemy of code reliability.

• Code efficiency focuses on the following:

o Program design
o Module & routine design
o Operating-system interactions
o Code compilations
o Hardware
o Code tuning

38
 Code Tuning, Cont.

Elements of Code Tuning:

• Measures the performance or size to find the trouble (inefficient) areas.

• Measures must be precise.

• Small parts of the program can take a disproportionate share of the run
time (80-20 rule).

• Iteration: Repeat the optimization process to continue receiving efficiency

improvements.

• Some areas of inefficiency:

o Input/output operations
o Paging
o System calls

39
 Code Tuning, Cont.

In Summary:
1. Develop the software using a good design with highly modular code
that is easy to understand & modify.

2. If performance is poor, measure the system to find the trouble

spots.

3. Determine whether the real performance comes form: design, data

structures, or algorithms & whether code tuning is appropriate.

4. Tune the bottleneck identified.

5. Measure each improvement; remove it if it does not work.

6. Repeat steps 1-5.

40
 Code Documentation

Types of Documentation:
• Good documentation is a sign of professional pride put into a program by
the programmer (coder).

• Documentation might be inside or outside the source code.

• Outside (external) documentation is classically a:

o Users’ manual.
o Operator’s manual (most recently combined with User’s manuals).
o Maintenance manual.

41
Approaches to Software
Development
 Methodologies, Models, Tools, & Techniques
Methodologies
⚫ Provide guidelines for every facet of system development.
• What to do, when, why & how.
⚫ Specify a Software Development Life Cycle (SDLC) with activities & tasks.
• Specify project planning & project management models & reporting.
• Specify analysis & design models to create.
• Specify implementation & testing techniques.
• Specify deployment & support techniques.

A framework for the tasks that are required to build high-quality software:

Tools

Methods

Process Model
43
“Quality” Focus
Methodologies, Models, Tools, and Techniques
Model
⚫ An abstraction of an important aspect of the real world.
⚫ Makes it possible to understand a complex concept by focusing only
on a relevant part.
⚫ Each model shows a different aspect of the concept.
⚫ Crucial for communicating project information.

44
 Methodologies, Models, Tools, &
Techniques
Tools
⚫ Software applications that assist developers in creating models or other
components required for a project.

⚫ Provide automated or semi-automated support for the process and the

methods.

⚫ CASE: Computer-Aided Software Engineering is a system for the support of

software development.
⚫ Combines Software (SW), Hardware (HW), and a SE database.
• A repository containing important information about analysis, design, program
construction, and testing.
⚫ Tools Examples:

45
 Methodologies, Models, Tools, &
Techniques
Technique
⚫ A collection of guidelines that help an analyst complete an activity or task.
⚫ Learning techniques is the key to having expertise in a field.

Techniques Examples:

46
2 Approaches to Software Construction & Modeling

The Structured Approach

⚫ Earlier approach.
⚫ Assumes a system is a collection of processes that interact with data.
⚫ Structured analysis, structured design, & structured programming.

The Object-Oriented Approach

⚫ More recent approach.
⚫ Assumes a system is a collection of objects that interact to complete tasks.
⚫ OO analysis, OO design, & OO programming.
⚫ OO technologies provide the technical framework for a component-based
process model for SE.

47
 The Structured Approach

Structured Programming
➢ A program is called structured when it uses only the following types
of constructs:
⚫ Sequence: instructions are executed one after another.
⚫ Selection/decision: if-then-else
⚫ Iteration/repetition: do-while

Structured programs are:

⚫ Easier to read and understand.
⚫ Easier to maintain.
⚫ Require less effort and time for development.

Research experience shows that programmers commit less number of

errors while using structured if-then-else and do-while statements
compared to test-and-branch constructs.
 The Object-Oriented Approach

⚫ Object-Oriented Analysis (OOA)

⚫ The process of identifying & defining the use cases & sets of
objects (classes) in the new system.

⚫ Object-Oriented Design (OOD)

⚫ Defining all the types of objects necessary to communicate
with people & devices & showing how they interact to
complete tasks.

⚫ Object-Oriented Programming (OOP)

⚫ Writing statements that define the actual classes & what
each object of the class does.

49
 Support Activities

Maintaining the system

⚫ Fix problems/error.
⚫ Make minor adjustments.
⚫ Update for changes in operating systems or environments.

Enhancing the system

⚫ Add desired functionality.
⚫ Add or change functionality to comply with regulations or
legislation.

Supporting the users

⚫ Ongoing user training.
⚫ Help desk.

50