Upload
mohesh-chandran
View
142
Download
0
Tags:
Embed Size (px)
Citation preview
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