Transcript CSEB233 Fundamentals of Software Engineering Module 5: Software Implementation/Coding Badariah Solemon 2010 Objectives • To explain what is software construction and why it is important • To.

CSEB233 Fundamentals of Software
Engineering
Module 5: Software
Implementation/Coding
Badariah Solemon 2010
Objectives
• To explain what is software
construction and why it is important
• To describe good programming
principles/practices
• To introduce the concept of
‘defensive programming’.
• To describe software inspection as a
static method to discover defects,
errors or problems .
• To explain the concepts, benefits and
problems of software reuse.
Badariah Solemon 2010
What is software construction?
• ‘Construction’ refers to the hands-on part of
creating something.
• Also known as implementation / coding and
debugging & verification and validation (testing).
• Generally focus at coding, debugging, some
detailed design and some testing (esp. unit
testing).
• Quality of construction substantially affects the
quality of the software.
Badariah Solemon 2010
What is software construction? (cnt’d)
• According to McConnell (1993), construction may involves:
– 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.
– Reviewing other team members’ design and code and having
them review yours.
– Polishing code – formatting and writing comments (i.e. internal
documentation).
– Integrating software components (if built separately).
– Tuning code – make it more efficient, smaller and faster.
Badariah Solemon 2010
Why is software construction
important?
• Depending on the size of the project, construction may takes 30%
to 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.
• 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. In reality,
construction is the only activity that’s guaranteed to be done!
(Source: McConnel, 1993, pp. 5)
Badariah Solemon 2010
Coding principles
(recap – chap 4)
• 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.
– 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.
Badariah Solemon 2010
Coding principles
(recap – chap 4)
• As you begin writing code, be sure you:
– Constrain your algorithms by following structured
programming [Boh00] 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.
– 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.
Badariah Solemon 2010
Coding principles
(recap – chap 4)
• After you’ve completed your first
coding pass, be sure you:
– 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.
Badariah Solemon 2010
Good programming practices
Generic practices:
1. Start with a good design. Update the design documents regularly. Create
additional design documents before adding major new features or functionality.
2. The program under development should be at all times functioning. The
development process consists of adding new functionality without breaking
existing functionality.
3. 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.
4. 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.
5. 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)
Badariah Solemon 2010
Good programming practices (cnt’d)
1.
2.
3.
4.
5.
6.
7.
8.
9.
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
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 )
Badariah Solemon 2010
Defensive Progamming
• Defensive programming is when the programmer makes
necessary assumptions and creates code that anticipates
potential problems and specification changes.
– According to Tushar Mehta (2009), defensive programming
involves:
a)
b)
c)
–
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.
A good defensive programmer is sufficiently confident in her
abilities to ignore the traditional belief that “If it isn’t broke,
don’t fix it.”
Badariah Solemon 2010
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.
• 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.
Badariah Solemon 2010
Program/code Inspection Process
• Focus at detecting defects (i.e. logical errors &
anomalies in the code).
• Program inspections are very effective in
discovering defects.
• A formal process that involve a team of
several members
– Fagan originally developed this method at IBM in
the 1970s with four suggested roles – author,
reader, tester & moderator
Badariah Solemon 2010
Advantages of Inspection over Testing
• According to Sommerville (2004):
1. A single inspection session can discover many errors in a
software/system.
•
During program testing, errors can mask (hide) other errors.
2. Incomplete versions of a software/system can be
inspected without additional costs.
•
To test an incomplete program, need to develop specialized test
to test the parts that are available.
3. Inspections can search for program defects and other
quality attributes of a program
•
E.g., compliance with standard, portability, maintainability,
efficiency, and etc.
Badariah Solemon 2010
Drawbacks/Issues related to
Inspections
1. Difficult to introduce formal inspections into software
development organizations.
2. Software engineers (programmers) with experience
are sometimes reluctant to accept that inspections
can be more effective for detecting defects (errors)
than testing.
3. Managers may be sceptical as inspections require
extra costs during modelling and construction.
4. Inspections may take time to arrange and appear to
slow down the development process.
Badariah Solemon 2010
Software reuse
• According to Sommerville (2004):
– 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 but it is now recognised that to
achieve better software, more quickly and at lower
cost, we need to adopt a design process that is based
on systematic reuse rather than ad-hoc reuse
• Systematic reuse -?
Badariah Solemon 2010
Reuse-based software engineering
• Application system 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
• Component reuse
– Components of an application from sub-systems to
single objects may be reused
• Object and function reuse
– Software components that implement a single welldefined function may be reused
Badariah Solemon 2010
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.
Badariah Solemon 2010
Benefits of reuse
• Increased dependability
– Software/components/function has been tried and tested in working systems,
so should be more dependable than new software.
• Reduced process risk
– Less uncertainty in development costs especially if a large software
components are reused.
• Effective use of specialists
– Reuse components instead of people. The specialist can create reusable
components
• 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
Badariah Solemon 2010
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
• Not-invented-here syndrome
– Some software engineers may think that writing original
software is seen as more challenging than reusing other
people’s software.
• Maintaining a component library can be expensive
• Finding and adapting reusable components
Badariah Solemon 2010
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
Badariah Solemon 2010
References
• Tushar Mehta (http://www.tushar-mehta.com/excel/vba/vbadefensive_programming.htm)
• Sommerville, I. 2004. Software Engineering, 7th Ed. Addison
Wesley: Boston.
• McConnell, S. 1993. Code Complete. Microsoft Press:
Bangalore, India.
• http://relisoft.com/practice.html
• R.S. Pressman, Software Engineering: A Practitioner’s
Approach, 7th. Edition, McGraw Hill, 2009.
Badariah Solemon 2010