CSEB233 Software Engineering Fundamentals Construction Coding Principles
1. B. Computer Sci. (SE) (Hons.)
CSEB233: Fundamentals of
Software Engineering
Software Implementation
& Coding
2. Objectives
Explain
what is software construction and why it is
important
Describe good programming principles/practices
Explain the concept of ‗defensive programming‘
Describe software inspection as a static method to
discover defects, errors or problems
Explain the concepts, benefits and problems of
software reuse
3. What is Software Construction?
‗Construction‘ refers
to the hands-on part of creating
something
Include implementation/coding and debugging; and
verification and validation
Generally focus at coding, debugging, some
detailed design and some testing (esp. unit testing)
Quality of construction substantially affects the
quality of the software
4. What is Software Construction?
According to McConnell (1993), construction may
involve:
Verifying that the groundwork has been laid so that
construction can proceed successfully
Designing and writing routines and modules
Selecting and creating data types and naming identifiers
Selecting control structures and organizing blocks of
statements
Finding and fixing errors
5. What is Software Construction?
According
involve:
to McConnell (1993), construction may
Reviewing other team members‘ design and code and
having them review yours
Polishing the code – formatting and writing comments
(i.e. internal documentation)
Integrating software components (if built separately)
Tuning the code – make it more efficient, smaller and
faster
6. Why is Software Construction
Important?
Depending on the size of project, construction may take
30% - 80% of the total project time
The larger the time spent, the bigger the work affect the
success of the project
Construction is the pivotal activity in software
development
With a focus on construction, there is a great potential
for the average programmer‘s productivity to improve
(McConnel, 1993)
7. Why is Software Construction
Important?
Requirements document and design documents can go
out of date, but construction‘s by product, the source
code, is always up to date
Ideally software project goes through requirements
engineering and modeling activities before construction
begins
Construction is the only activity that‘s guaranteed to be done!
(McConnel, 1993)
8. Coding Principles
Coding
principles and concepts are closely aligned
programming style, programming languages, and
programming methods
Before you write one line of code, be sure you:
Understand of the problem you‘re trying to solve
Understand basic design principles and concepts
9. Coding Principles
Before
you write one line of code, be sure you:
Pick a programming language that meets the needs of
the software to be built and the environment in which it
will operate
Select a programming environment that provides tools
that will make your work easier
Create a set of unit tests that will be applied once the
component you code is completed
10. Coding Principles
As
you begin writing code, be sure you:
Constrain your algorithms by following structured
programming practice
Consider the use of pair programming
Select data structures that will meet the needs of the
design
Understand the software architecture and create
interfaces that are consistent with it
Keep conditional logic as simple as possible
11. Coding Principles
As
you begin writing code, be sure you:
Create nested loops in a way that makes them easily
testable
Select meaningful variable names and follow other local
coding standards
Write code that is self-documenting
Create a visual layout (e.g., indentation and blank lines)
that aids understanding
12. Coding Principles
After
you‘ve completed your first coding pass, be
sure to:
Conduct a code walkthrough when appropriate
Perform unit tests and correct errors you‘ve uncovered
Refactor the code
■
reorganization technique that simplifies the code without
changing its function or behaviour
13. Good Programming Practices
Start with a good design.
The program under development should be functioning at all
times
Update the design documents regularly
Create additional design documents before adding new major
features or functionality
The development process consists of adding new functionality
without breaking existing functionality
Work has to be divided into small incremental steps that can
be typically accomplished and code-reviewed in one day.
Even large-scale rewrites should be made incremental
14. Good Programming Practices
Every line of code written or modified undergoes peer review
The smallest team must contain at least two programmers so that
they can code-review each other's changes
Always attempt to work top-down in:
Design—start with high level objects
Implementation—create top-level objects using low-level stubs
Modification—change the top-level objects and the overall flow of
control first. If necessary, use stubs, or fake new functionality
using old implementation
(Source: http://relisoft.com/practice.html)
15. Good Programming Practices
Be
consistent with formatting
Be consistent with naming conventions
Use global [identifiers] sparingly
Don‘t assume output formats
Add comment to your code – explain what and why
(Source: Kim Moser at http://relisoft.com/practice.html )
16. Good Programming Practices
Provide
useful error messages
Recover (or fail) gracefully
Push interface up and implementation down
Know what you don't know – prepare for changes
(Source: Kim Moser at http://relisoft.com/practice.html )
17. Defensive Progamming
Defensive
programming is when the programmer
makes necessary assumptions and creates code
that anticipates potential problems and specification
changes
A good defensive programmer is sufficiently
confident in his/her abilities to ignore the traditional
belief that ―If it isn‘t broke, don‘t fix it.‖
18. Defensive Progamming
Defensive programming involves:
finding problems in the existing code by identifying code
inconsistencies and understanding typical uses of the
software
anticipating – and preempting – both potential problems with
the existing specifications as well as likely changes in user
behavior and design specifications, and
streamlining the code to aid readability and simplify
maintainability
(Mehta, 2009)
19. Software Inspections
An
‗old school‘ approach
A process to review, analyze and check static
system representations such as requirements
document, design document, and program source
code to look for errors and problems
Static – need not run the software on a computer
Generally,
focus at source code
20. Software Inspections
Sometime
also known as peer reviews or program
/code inspections
Inspections can check conformance with a specification but not conformance with the customer‘s real
requirements
But, inspections cannot check non-functional characteristics such as performance, usability, etc.
21. Program/Code Inspection Process
Focus
at detecting defects - logical errors and
anomalies in the code
Program inspections are very effective in
discovering defects
A formal process that involve team of several
members
Fagan originally developed this method at IBM in the
1970s with four suggested roles – author, reader, tester
and moderator
22. Advantages of Inspection over
Testing
A
single inspection session can discover many
errors
During program testing, errors can mask (hide) other
errors
Incomplete
versions of a software can be inspected
without additional costs
To test an incomplete program, specialized test is
needed to test the parts that are available
(Sommerville, 2004)
23. Advantages of Inspection over
Testing
Inspections
can search for program defects and
other quality attributes of a program
e.g., compliance to standard, maintainability, portability,
efficiency, etc.
(Sommerville, 2004)
24. Drawbacks/Issues related to
Inspections
Difficult to introduce formal inspections into software
development organizations
Software engineers (programmers) with experience are
sometimes reluctant to accept that inspections can be
more effective for detecting defects (errors) than testing
Managers may be sceptical as inspections require
extra costs during modelling and construction
Inspections may take time to arrange and appear to
slow down the development process
25. Software Reuse
In most engineering disciplines, systems are designed
by composing existing components that have been
used in other systems
Software engineering has been more focused on
original development
It is now recognised that to achieve better software
quickly at lower cost, we need to adopt a design
process that is based on systematic reuse rather than
ad-hoc reuse
(Sommerville, 2004)
26. Reuse-based Software Engineering
Application system reuse
Component reuse
The whole of an application system may be reused either by
incorporating it without change into other systems (COTS
reuse) or by developing application families
Components of an application from sub-systems to single
objects may be reused
Object and function reuse
Software components that implement a single well-defined
function may be reused
27. Requirements for Reuse
It
must be possible to find appropriate reusable
components
The reuser of the component must be confident that
the components will be reliable and will behave as
specified
The components must be documented so that they
can be understood and, where appropriate,
modified.
28. Benefits of Reuse
Increased dependability
Software/components/functions have been tried and tested
in working systems
They should be more dependable than new software
Reduced process risk
Less uncertainty in development costs especially if large
software components are reused
Effective use of specialists
Reuse components instead of people
The specialist can create reusable components
29. Benefits of Reuse
Standards
compliance
Standards such as UI standard (e.g., drop-down menu)
can be implemented as reusable components to
improve dependability as users are less likely to make
mistake
Accelerated
development
Avoid original development, speed-up production and
hence able to market product early
30. Reuse Problems
Increased
costs
in understanding whether the application/component/
function is suitable for reuse
in testing it to ensure its dependability and in maintaining
the reused item
Lack
of CASE tool support
Maintaining a component library can be expensive
31. Reuse Problems
Not-invented-here
syndrome
Some software engineers may think that writing original
software is seen as more challenging than reusing other
people‘s software.
Finding
and adapting reusable components
32. Summary
You
have been introduced to:
good programming principles/practices
the concept of ‗defensive programming‘
software inspection as a static method to discover
defects, errors or problems
the concepts, benefits and problems of software reuse