B. Computer Sci. (SE) (Hons.)

CSEB233: Fundamentals of Software EngineeringSoftware Implementation

& Coding

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

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

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

What is Software Construction? According to McConnell (1993), construction may

involve: 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

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)

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)

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

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

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

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

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

Good Programming Practices

Start with a good design. Update the design documents regularly Create additional design documents before adding new major features

or functionality The program under development should be functioning at all times

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

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)

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 )

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 )

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.”

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)

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

Software Inspections

Sometime also known as peer reviews or program /code inspections

Inspections can check conformance with a specifi-cation but not conformance with the customer’s real requirements

But, inspections cannot check non-functional cha-racteristics such as performance, usability, etc.

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

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)

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)

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

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)

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 well-defined function may be reused

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.

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

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

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

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

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

THE ENDCopyright © 2013 Mohd. Sharifuddin Ahmad,

PhD

College of Information Technology