Software Construction (1)

1

• Software Construction (1)
• Dr. Pedro Mejia Alvarez
• CINVESTAV-IPN

2
Main Contents

• Construction Activities
• Software Reuse
• Construction Ideas
• By Steve McConnell

3
1. Construction Activities---what is software
construction

• More than just programming

4
1. Construction Activities---Construction is not
Implementation

• Distinction Between Activities and Phases
• Activity ! Phase
• Talking about Construction as an activity does
  not imply a distinct phase
• Differentiating between kinds of activities is
  extremely helpful

5
1. Construction Activities

• Construction Activities
• Design in Construction
• Select Construction Environments
• Programming Practices

6
1. Construction Activities--- Design in
Construction

• Key Design Concepts
• Softwares Primary Technical Imperative Managing
  Complexity
• Construction Design Heuristics and Practices
• Broad practical knowledge
• Some typical examples later

7
1. Construction Activities--- Managing Complexity

• Complexity
• Organize into modules
• Abstract at all levels
• Keep code simple and readable
• Coupling
• Minimize Coupling
• Use interfaces, Law of Demeter
• Cohesion
• Maximize Cohesion
• Keep methods short
• Dont let classes get too big

8
1. Construction Activities--- Managing Complexity

• Law of Demeter
• Any method of an object should call only methods
  belonging to
• Itself
• Any parameters that were passed in to the
  method
• Any objects it created
• Any directly held component objects
• i.e. dont use objects to get other objects

9
1. Construction Activities--- Examples of
Construction Design Practices

• Defensive Programming
• Assertive programming
• Test-driven development
• Design-by-Contract
• Refactoring
• Communication
• Reviews, pair-programming, stand-up meetings
• etc.

10
1. Construction Activities--- Select
Construction Environments

• Construction Environments
• Programming Language
• Construction Platforms
• OS, DBMS, Network, Middleware, Etc.
• Standards
• Code standards
• Technology standards
• Component model, etc.
• Tools
• Coding environments
• Debug and testing environments
• Sourcing managing environments

11
1. Construction Activities--- Programming
Practices

• Many Heuristics
• Example How To Write Unmaintainable Code

12
2. Software Reuse---Introduction

• What is Reuse?
• "...the use of existing software artifacts or
  knowledge to create new software..." FraTer96
• This includes all types of artifacts created.
• Why Reuse?
• Because we (the CS people) are inventing the
  wheel over and over again and wasting enormous
  resources doing so.
• We hope that there is a way to make integration
  and design of the reusable component cheaper than
  redevelopment.

13
2. Software Reuse--- Practices about Reuse

• Studies Only 15 of new code serves an original
  purpose
• i.e. Theoretical reuse rate of 85
• Studies Software Reuse is the most beneficial
  silver bullet (30-35)
• There is no other way to build large applications.

14
2. Software Reuse--- Chaos 2000, Standish Group
15
2. Software Reuse--- Types of Reuse

• Opportunistic reuse This is possible during
  programming when components are discovered that
  happened to fit a requirement.
• Systematic reuse This require a design process
  that consider how exciting designs may be reused
  and that explicitly organized the design around
  available software components.

16
2. Software Reuse--- The Reuse Landscape
17
2. Software Reuse--- Types of Implementation
Reuse
18
3. Construction Ideas

• A Decade of Advances in Software Construction
• Ten Realities of Modern Software Construction
• Some of the Worst Construction Ideas of 1990s and
  2000s

19
3. Construction Ideas

• A Decade of Advances in Software construction

20
1. Design has Been Raised a Level

• Programming has advanced through ability to
  create larger code aggregations
• Statements
• Routines
• Classes
• Packages
• Real legacy of OO might well be larger
  aggregations

21
2. Daily Build and Smoke Test

• Institutionalizes incremental integration
• Minimizes serious integration problems that used
  to be common
• Lots of other benefits, too

22
3. Standard Libraries

• Good programmers have always used libraries
• Now provided with languages (Java, C, .NET)

23
4. Visual Basic

• Visual programming innovation
• The first development environment to make
  widespread use of COTS components
• Only language to learn Adas syntax lessons (case
  statements, control statements, etc.)
• Highly integrated environment

24
5. Open Source Software

• Great aid to programmers during development
• Reduced barriers to making code available
• Opportunity to learn from available code
• Improved ability to read code
• Nice community of programmers

25
6. The Web, for Research

• FAQs
• Discussion groups
• Searchability in general

26
7. Widespread Use of Incremental Development

• Concepts were well known in 1990s
• Practice is well established in 2000s

27
8. Test-First Development

• Shortens time to defect detection
• Increases personal discipline
• Complements daily build smoke test

28
9. Refactoring as a Discipline

• Provides a discipline for making changes
• Not so good as a total design strategy
• Good example of incrementalism

29
10. Faster Computers

• Implications for optimization
• Implications for programming languages
• Implications for development

30
3. Construction Ideas

• Ten Realities of Modern Software Construction

31
-1-Construction is a Legitimate Topic

• Software Construction Now Looks Like This

32
-2- Individual Variation Is Significant

• Where do Variations Exist?
• Researchers have found variations ranging from
  10x to 28x in
• Coding speed
• Debugging speed
• Defect-finding speed
• Percentage of defects found
• Bad-fix injection rate
• Design quality
• Amount of code generated from a design
• Etc.

33
-3- Personal Discipline Matters

• Why Personal Discipline Matters
• Being realistic about predicting the future
• Areas where discipline matters
• Refactoring
• Prototyping
• Optimization
• Minimal-complexity designs specifically
• Managing complexity generally
• EndpointsDiscipline and Courage
• Humphrey on PSP
• Beck on Extreme Programming

34
-4- A Focus on Simplicity Works Better than a
Focus on Complexity

• Focus on read-time convenience, not write-time
  convenience

35
-5- Defect-Cost Increase is Alive and Well
36
-6- Importance of Design

• There are lots of valid points on the no
  designall design continuum
• General Point Extremes are Usually Not
  Productive
• All design up front vs. no design up front
• Entirely planned vs. entirely improvised
• Pure iterative vs. straight sequential
• All structure vs. all creative
• Document everything vs. document nothing

37
-7- Technology Waves Affect Construction Practices

• Effect of Technology Waves on Construction
• Definition of technology wave
• Early-wave characteristics
• Mature-wave characteristics
• Late-wave characteristics
• Construction is affected by technologymore than
  I thought (doh!)
• Technology can be addressed in terms of general
  principles

38
-8-Incremental Approaches Work Best

• Perspective on Incrementalism
• The pure waterfall model is not at all
  incremental or iterativewhich is why it hasnt
  worked very well
• Spiral development is highly incremental and
  iterative, which is part of why it does work well
• All projects will experience iteration at some
  point
• Think about where and when in your project you
  will get your incrementalismcheaply, or
  expensively?

39
-9- The Toolbox Metaphor Continues to be
Illuminating

• Toolbox Metaphor
• Whats best? Agile? XP? Scrum? CMM?
• Toolbox explains theres no one right tool for
  every job
• Different industry segments will have different
  tools and even different toolboxes
• Whats in the Software Engineering Toolbox?
• Best practices
• Lifecycle models
• Templates, checklists, patterns, examples
• Software tools

40
-10- Softwares Essential Tensions

• Softwares essential tensions have remained
  unchanged for years
• Rigid plans vs. Improvisation
• Planning vs. Fortune Telling
• Creativity vs. Structure
• Discipline vs. Flexibility
• Quantitative vs. Qualitative
• Process vs. Product
• Optimizing vs. Satisficing
• Balance wavers, but basic tensions are constants

41
3. Construction Ideas

• Some of the Worst Construction Ideas of 1990s and
  2000s

42
Some of the WorstConstruction Ideas of 1990s

• Code fix
• All design up front programming
• Design for speculative requirements
• Components will solve all our construction
  problems
• Automatic programming
• Uninformed use of the waterfall model
• Calling everything object oriented

43
Some of the WorstConstruction Ideas of 2000s

• Code fix
• No design up front programming
• Planning to refactor later
• Offshore outsourcing will solve all our
  construction problems
• Automatic programming
• Uninformed use of Extreme Programming
• Calling everything agile

44
Worst Ideas, 1990s vs. 2000s
45
The End

• Recommend book
• (Code Complete),2ed,Steve McConnell