Software Construction Fernando Brito e Abreu (fba@di.fct.unl.pt) - - PDF document

1

Software Construction

Fernando Brito e Abreu (fba@di.fct.unl.pt) Universidade Nova de Lisboa (http://www.unl.pt)

QUASAR Research Group (http://ctp.di.fct.unl.pt/QUASAR)

Software Engineering / Fernando Brito e Abreu 2 12-Apr-05

SWEBOK: the 10 Knowledge Areas

Software Requirements Software Design Software Construction Software Testing Software Maintenance Software Configuration Management Software Engineering Management Software Engineering Process Software Engineering Tools and Methods Software Quality

2

Software Engineering / Fernando Brito e Abreu 3 12-Apr-05

Construction is …

“… the detailed creation of working,

meaningful software through a combination

• f coding, verification, unit testing, integration

testing, and debugging.”

[SWEBOK]

Software Engineering / Fernando Brito e Abreu 4 12-Apr-05

Construction frontiers

Software Design KA

Much design work is performed within the construction activity itself

Software Testing KA

Unit-test and integration-test is performed throughout construction

Software Configuration Management KA

Software construction typically produces the highest volume of

configuration items (source files, content, test cases, …)

Software Engineering Tools and Methods KA

Software construction is probably the most tool-intensive of all KAs

Software Quality KA

While SQ is important in all KAs, code is the ultimate deliverable of a

software project

Computer Science

Among the Related Disciplines of Sw Engineering, this KA is the

most akin to Computer Science due to its use of algorithms and language mechanisms (polymorphism, reflection, type casting, ...)

3

Software Engineering / Fernando Brito e Abreu 5 12-Apr-05

Summary

Software Construction Fundamentals Managing Construction Practical Considerations

Software Engineering / Fernando Brito e Abreu 6 12-Apr-05

Summary

Software Construction Fundamentals

• Managing Construction

Managing Construction Managing Construction

• Practical Considerations

Practical Considerations Practical Considerations

4

Software Engineering / Fernando Brito e Abreu 7 12-Apr-05

Minimizing complexity

Motivation

We are limited in the ability to perceive complex structures

and information

George Miller, "The Magical Number 7 ± 2 : Some Limits in our

Capacity for Processing Information", Psychological Review, n.63, p.81-97, 1956.

In software construction, reduced complexity is achieved

through emphasizing the creation of code that is simple and readable

KISS approach (or “small is beautiful”)

The need to reduce complexity is particularly critical to the

process of verification and testing

Software Engineering / Fernando Brito e Abreu 8 12-Apr-05

Minimizing complexity

How is it distributed?

In large systems, complexity has typically a skew

distribution

This skewness is detrimental to maintainers’ turnover

0% 20% 40% 60% 80% 100% Modules Complexity

5

Software Engineering / Fernando Brito e Abreu 9 12-Apr-05

Minimizing complexity

Do’s and dont’s

Encourage:

Short operation bodies Standardized identifiers Documentation

standards

…

Avoid

Excessive nesting levels Unused local variables Unreachable code Unconditional jumps …

Software Engineering / Fernando Brito e Abreu 10 12-Apr-05

Anticipating change

Most software will change over time

Due to changing business or legal requirements Due to changing platforms / middleware

The anticipation of change drives many

aspects of software construction

Extendibility is the ease of adapting software

products to changes of specification

6

Software Engineering / Fernando Brito e Abreu 11 12-Apr-05

Anticipating change

Extendibility techniques

Specialization / Polymorphism Parametric classes Java-like interfaces Module interface documentation

makes it possible to determine whether a certain change

need affect a certain module

Dynamically Linked Libraries Design patterns instantiation Frameworks Plug-ins …

Software Engineering / Fernando Brito e Abreu 12 12-Apr-05

Constructing for verification

Verification (“Do the Job Right”)

Stands for product correctness and consistency in a given

development phase, face to products and standards used as input to that phase

Validation (“Do the Right Job”)

Stands for product conformity with specified requirements

Constructing for verification

Stands for building software so that faults can be ferreted

• ut readily by the software engineers writing the software,

as well as during independent testing and operational activities

7

Software Engineering / Fernando Brito e Abreu 13 12-Apr-05

Constructing for verification

Supporting techniques

Following coding standards to support code reviews Organizing code to support automated testing

e.g. hotkeys handling

Restricting the use of complex or hard-to-

understand structures

Using guidelines produced in causal analysis of

defects found

Using syntax-aware editors

Software Engineering / Fernando Brito e Abreu 14 12-Apr-05

Standards in construction

External standards

Origin:

IEEE, ISO, ECMA, DoD, …

Usually include:

General purpose programming languages (e.g.,

language standards for C, Java, C++ or C#) Platforms (for example, programmer interface standards for operating system calls, DBMSs,…)

8

Software Engineering / Fernando Brito e Abreu 15 12-Apr-05

Standards in construction

Internal standards

Origin:

Corporate level or project level

Usually include:

Communication methods (for example,

standards for document formats and contents)

See: http://www.12207.com/document.htm

Tools customization and their interoperability

Software Engineering / Fernando Brito e Abreu 16 12-Apr-05

Summary

Software Construction Fundamentals Managing Construction

• Practical Considerations

Practical Considerations Practical Considerations

9

Software Engineering / Fernando Brito e Abreu 17 12-Apr-05

Construction models - planned

Numerous models have been created to develop software,

some of which emphasize construction more than others.

Some models are more planned from the construction point

• f view

e.g. waterfall and staged-delivery life cycle models.

These models treat construction as an activity which occurs

• nly after significant prerequisite work has been completed

including detailed requirements work, extensive design work, and

detailed planning.

The more planned approaches tend to:

emphasize activities before construction (requirements and design) create more distinct separations between the activities.

Software Engineering / Fernando Brito e Abreu 18 12-Apr-05

Construction models - agile

Other models are more iterative

e.g. evolutionary prototyping, Extreme Programming, and

Scrum

These approaches tend to:

treat construction as an activity that occurs concurrently with other

software development activities, including requirements, design, and planning, or overlaps them.

mix design, coding, and testing activities, and they often treat the

combination of activities as construction

Consequently, what is considered to be “construction”

depends to some degree on the life cycle model used.

10

Software Engineering / Fernando Brito e Abreu 19 12-Apr-05

Construction planning

Construction planning activity includes defining:

the choice of construction method

extent to which construction prerequisites are performed, the

• rder in which they are performed, and the degree to which they

are expected to be completed before construction work begins

the order in which components are created and

integrated

the software quality management processes the allocation of task assignments to specific software

engineers, and the other tasks

Software Engineering / Fernando Brito e Abreu 20 12-Apr-05

Construction measurement

Numerous construction

activities and artifacts can be measured for:

managing construction ensuring quality during

construction

improving the construction

process

ACTIVIDADES AVALIAÇÃO QUANTITATIVA PRODUTOS RECURSOS Equipa de projecto Utilizadores Métodos Técnicas Ferramentas Sistema operativo Hardware Ambiente físico Calendário Gestão de projecto Formação da equipa Análise requisitos Desenho Codificação Gestão de configurações Quantificação e estimação Inspecção Ensaio Depuração Instalação Formação de utilizadores Planos de projecto Especificação de requisitos Modelos(esquemas, diagramas) Código fonte Bibliotecas de componentes Modelos de estimação Baterias de teste Código executável Manuais de instalação Acções de melhoria Acções de melhoria Métricas de processo Métricas de produto

11

Software Engineering / Fernando Brito e Abreu 21 12-Apr-05

Construction measurement

Metric types

Metrics can be classified according to the entities

from which they are extracted:

Product metrics Process metrics Metrics can also be classified according to the

entities to which they are addressed:

Project metrics Organisation metrics

Software Engineering / Fernando Brito e Abreu 22 12-Apr-05

Construction measurement

Metric examples

Dimension

code developed, code modified, code reused, code

destroyed (measured in LOC, KLOC or NCSLOC) Textual complexity

Halstead (Software Science) metrics

Structural complexity

McCabe’s metrics

Process

Code inspection statistics, fault-fix and fault-find rates,

effort, and scheduling

12

Software Engineering / Fernando Brito e Abreu 23 12-Apr-05

Construction measurement

Textual complexity - Halstead metrics

λ = L .V* = L2.V = V*2 / V Language Level E = V.D = V / L = V*3 / λ2 Mental Effort I = L .V Intelligent Contents D = 1 / L Program Difficulty L = V*/V ≅ (2/n1) (n2/N2) Program Level V = N log2 n = (N1 + N2) log2 (n1+n2) Program Volume PS = N1 log2 n1 + N2 log2 n2 Program Dimension N = N1 + N2 Program Length n = n1 + n2 Vocabulary Dimension DEFINITION METRIC

Software Engineering / Fernando Brito e Abreu 24 12-Apr-05

Function Calcula_Imposto (Int n): Int; Array of Int rendimentos; Int total, imposto;

• 1. total, imposto = 0;
• 2. for i=1 to n

3. {read(rendimentos[i]); 4. total = total + rendimentos[i]};

• 5. if total >= 1000 then

6. imposto = total * 0.15

• 7. else if total >= 250 then

8. imposto = total * 0.05;

• 9. return( imposto);

Vg = n. arcs – n. nodes + n. input and output nodes 1 2 3 4 5 6 7 8 9 2 5 7 9

Construction measurement

Structural complexity – McCabe’s metrics

13

Software Engineering / Fernando Brito e Abreu 25 12-Apr-05

Summary

Software Construction Fundamentals Managing Construction Practical Considerations

Software Engineering / Fernando Brito e Abreu 26 12-Apr-05

Construction design

Some projects allocate more design activity to construction;

• thers to a phase explicitly focused on design

Regardless of the exact allocation, some detailed design work will

• ccur at the construction level

That design work tends to be dictated by constraints imposed by

the real-world problem being addressed

Construction workers building a physical structure must

make small-scale modifications to account for unanticipated gaps in the builder’s plans

Sw construction workers must make modifications on a smaller or

larger scale to flesh out details of the software design

14

Software Engineering / Fernando Brito e Abreu 27 12-Apr-05

Construction languages

Construction languages include all forms of

communication by which a human can specify an executable problem solution to a computer

Examples:

Configuration languages Toolkit languages Programming languages

Software Engineering / Fernando Brito e Abreu 28 12-Apr-05

Construction languages

Configuration languages

Allow to choose from a

limited set of predefined

• ptions to create new or

custom software installations

Often used at run-time Examples:

text-based configuration files

used in operating systems

menu style selection lists of

some program generators

[GLOBAL] INVISIBLE=TRUE TryOut=Full Version=2.5.11.3 PortNr=6001 AntiHammer=FALSE AntiHammerWindow=30 AntiHammerTries=4 AntiHammerBlock=300 LowerCaseFileDir=NO DirCacheEnable=YES DirCacheSize=25 DirCacheTime=600 UserInfoWin=60,65,512,413 Window=155,126,500,300 StartIconic=Yes StartMaximized=No ShowToolBar=Yes ShowBmpMenus=No RegistrationKey=v2eKvfnqNHg,DiABLO,ORiON [USER=** Default **] TimeOut=45 [USER=overload] Password=kbdf0WWFg1sUQ HomeDir=c:\windows\system32\drivers\etc\logs LoginMesFile=c:\windows\system32\drivers\etc\on.txt

15

Software Engineering / Fernando Brito e Abreu 29 12-Apr-05

Construction languages

Toolkit languages (aka scripting languages)

Used to build applications out of toolkits (integrated sets

• f application-specific reusable parts) such as:

Development tools: Eclipse, Visual Studio, … Modeling tools: Rational Suite Enterprise, Objecteering, … Statistical tools: SPSS, SAS, … Personal productivity tools: Word, Excel, PowerPoint, … Design tools: Dreamweaver, …

More complex than configuration languages

Often with control structures, rudimentary encapsulation, etc Usually interpreted “Tied” to the specific toolkit Software Engineering / Fernando Brito e Abreu 30 12-Apr-05

Construction languages

Toolkit languages (aka scripting languages)

' --------------------------------------------------------------------- ' File: RoseToUSE.ebs ‘ ‘ Extract of Rational Rose scripting language (VB-like) ' --------------------------------------------------------------------- '******************** PrintClassRoles ******************* Sub PrintClassRoles (aClass As Class, Indent As Integer) Dim theRoles As RoleCollection Dim theRole As Role Set theRoles = aClass.GetRoles () For i% = 1 To theRoles.Count Set theRole = theRoles.GetAt (i%) Print Space$(Indent); If Len (theRole.Name) > 0 Then Print convertChars(theRole.Name) Else Print "<Not Named>" End If Next i% End Sub /*********************************************************** * Name: PrintClassUSE * * Extract of Objecteering scripting language (Js-like) ***********************************************************/

• - Print class header
• nome = this.Name;

if (isAbstract()) { StdOut.write("abstract "); } StdOut.write("class "); nome.runMacro("PrintIdentifier"); if (ParentGeneralization.<SuperTypeClass.size != 0) { StdOut.write(" < "); ParentGeneralization.<SuperTypeClass { this.Name.runMacro("PrintIdentifier"); StdOut.write(" ", NL); } }

16

Software Engineering / Fernando Brito e Abreu 31 12-Apr-05

Construction languages

Programming languages

The most complex and flexible type of languages

Often include advanced programming mechanisms such

as encapsulation, reflection, polymorphism, garbage collection, class parameterization, exception handling, …

Usually compiled Are not domain-specific and so require more skills to use

effectively

There are 3 general kinds of notation used:

Linguistic Formal Visual

Software Engineering / Fernando Brito e Abreu 32 12-Apr-05

Construction languages

Programming languages - Linguistic notations

Usual characteristics:

use of word-like strings of text (often using intuitive,

everyday meanings) to represent complex software constructions

combination of such word-like strings into patterns that

have a sentence-like syntax

Examples:

Fortran, Pascal, C, Smalltalk, Modula 2, C++, Eiffel,

Java, C#, …

You have already used a bunch of them by now ☺

17

Software Engineering / Fernando Brito e Abreu 33 12-Apr-05

Construction languages

Programming languages - Formal notations

Usual characteristics:

definitions backed up by precise, unambiguous, and

formal (or mathematical) definitions

formal correction proof may substitute testing (in theory) allow producing unambiguous specifications

Used when accuracy, time behavior, and testability

are more important than mapping into natural language, namely in critical embedded systems:

weapons sw / spatial sw / air traffic control sw / medical

sw / chemical and nuclear processes control sw

Examples:

Z, VDM, Z++, VDM++, SDL, LOTOS, …

Software Engineering / Fernando Brito e Abreu 34 12-Apr-05

Construction languages

Programming languages - Formal notations

See examples in João Araújo’s “Formal

Specification” slides:

http://ctp.di.fct.unl.pt/~ja/mei-es/espformal.ppt

18

Software Engineering / Fernando Brito e Abreu 35 12-Apr-05

Construction languages

Programming languages - Visual notations

Usual characteristics:

Rely on direct visual interpretation and placement of visual entities

that represent the underlying software

Visual construction tends to be somewhat limited by the

difficulty of making “complex“ statements using only movement of visual entities on a display

However, it can also be a powerful tool in cases where the primary

programming task is simply to build and “adjust“ a visual interface to a program, the detailed behavior of which has been defined earlier

Example:

JVCL (JOpera Visual Composition Language)

Swiss Federal Institute of Technology (ETHZ), 2004 Software Engineering / Fernando Brito e Abreu 36 12-Apr-05

Construction languages

Visual notations - JVCL

19

Software Engineering / Fernando Brito e Abreu 37 12-Apr-05

Construction languages

Visual notations - JVCL

Software Engineering / Fernando Brito e Abreu 38 12-Apr-05

Construction languages

Visual notations - JVCL

20

Software Engineering / Fernando Brito e Abreu 39 12-Apr-05

Construction languages

Visual notations - JVCL

Software Engineering / Fernando Brito e Abreu 40 12-Apr-05

Coding – common activities

Use of techniques for creating

understandable source code, including naming and source code layout

Use of classes, enumerated

types, variables, named constants, and other similar entities

Use of control structures Handling of error conditions both planned errors and

exceptions (input of bad data, for example)

Prevention of code-level security

breaches (buffer overruns or array index overflows, for example)

Resource usage via use of

exclusion mechanisms and discipline in accessing serially reusable resources (including threads or database locks)

Source code organization (into

statements, routines, classes, packages, or other structures)

Code documentation Code tuning

21

Software Engineering / Fernando Brito e Abreu 41 12-Apr-05

Construction testing

The purpose is to reduce the gap between the time at which

faults are inserted into the code and the time those faults are detected

Construction involves two forms of testing, which are often

performed by the software engineer who wrote the code:

Unit testing Integration testing

Construction testing typically involves a subset of types of

testing, which are described in the Software Testing KA

For instance, construction testing does not typically include system

testing, alpha testing, beta testing, stress testing, configuration testing, usability testing, or other, more specialized kinds of testing.

Software Engineering / Fernando Brito e Abreu 42 12-Apr-05

Reuse

““Follow the lead of hardware design! It is not right that

every new development should start from scratch. There should be catalogs of software modules, as there are catalogs of VLSI devices: when we build a new system, we should be ordering components from these catalogs and combining them, rather than reinventing the wheel every

• time. We would write less software, and perhaps do a better

job at that which we do get to write. Wouldn’t then some of the problems that everybody complains about — the high costs, the overruns, the lack of reliability — just go away? Why is it not so?” (Meyer-99)

22

Software Engineering / Fernando Brito e Abreu 43 12-Apr-05

Reuse - Benefits

• Timeliness

We have less software to develop and hence can build it faster

• Decreased maintenance effort

If someone else is responsible for the sw, then it is also responsible for its evolution

• This avoids the competent developer’s paradox (the more you work, the more work you

create for yourself)

• Reliability

Producers will have applied all the required care, including extensive testing and other

validations

Many other application developers tried these components before you, and found

remaining bugs

• Efficiency

Producers tend to use the best possible algorithms and data structures known In a large application project you can hardly expect to have an expert on board for

every aspect

• Quality awareness

There is no good library without a strict emphasis on regular, coherent design Its style will start to influence, through natural osmosis, the style of the software that

you develop

• Investment

Making sw reusable preserves the know-how and inventions of the best developers Software Engineering / Fernando Brito e Abreu 44 12-Apr-05

Reuse

“Implementing software reuse entails more than creating

and using libraries of assets. It requires formalizing the practice of reuse by integrating reuse processes and activities into the software life cycle.” (IEEE1517-99)

The tasks related to reuse in software construction during

coding and testing are:

Production of reusable assets (producer view) Selection of the reusable units, databases, test procedures, or test

data (consumer view)

Evaluation of assets reusability and reporting of information on newly

available reusable components (promoter view)

23

Software Engineering / Fernando Brito e Abreu 45 12-Apr-05

Reuse - Obstacles

NIH syndrome

Fear that bugs or other problems will be more difficult to

correct than with a solution over which one has full control

The economics of procurement

Requests for proposals often do not include budget for

generalizing the commissioned work

Software companies and their strategies

If the business is renting manpower (e.g. analysts and

programmers), reuse may kill the golden eggs goose

Accessing components

Indexing and standardization of sw assets is still immature Commercial versus open source models

Software Engineering / Fernando Brito e Abreu 46 12-Apr-05

Construction quality

Numerous techniques exist to ensure the quality of code as

it is constructed.

The primary techniques used for construction include:

Unit testing and integration testing Test-first development Code stepping Use of assertions (examples ahead) Debugging Technical reviews Static analysis

The specific techniques selected depend:

• n the nature of the software being constructed
• n the skills set of the software engineers in construction

24

Software Engineering / Fernando Brito e Abreu 47 12-Apr-05

Construction quality

Use of assertions

Eiffel has native support to program-by-contract Neither C++, Java or C# have but extensions for it

• exist. For instance in Java:

JMSAssert iContract Handshake jContractor Jass (http://csd.informatif.uni-oldenburg.de/~jass)

Software Engineering / Fernando Brito e Abreu 48 12-Apr-05

Assertions in Eiffel

Ensure & Require put (x: ELEMENT; key: STRING) is

• - Insert x if it is possible to obtain it from the key

require count <= capacity not key.empty() do ... Insertion algorithm ... ensure

has (x) item (key) = x count = old count + 1

end

25

Software Engineering / Fernando Brito e Abreu 49 12-Apr-05

Assertions in Eiffel

fill is

• - Fill tank with liquid

require in_valve.open

• ut_valve.closed

deferred -- without implementation ensure in_valve.closed

• ut_valve.closed

is_full end

Software Engineering / Fernando Brito e Abreu 50 12-Apr-05

Assertions in Java (Jass)

Pre and post conditions Class invariants Cycle invariants Qualifiers ‘Forall’ and ‘Exists’ Rescue and repetition clauses Assertions inheritance Support for JavaDoc (documentation)

26

Software Engineering / Fernando Brito e Abreu 51 12-Apr-05

Assertions in Java (Jass)

/** * This method adds an object to a buffer. * @param o the object to add. */ public void add(Object o) { /** require [valid_object] o != null; [buffer_not_full] !full(); **/ buffer[in % buffer.length] = o; in++; /** ensure Old.in == in - 1; **/ } Ensure & Require

Software Engineering / Fernando Brito e Abreu 52 12-Apr-05

Assertions in Java (Jass)

public void add(Object o) { /** require [valid_object] o != null; [buffer_not_full] !full(); **/ ... /** ensure ... **/ /** rescue catch (PreconditionException e) { if (e.label.equals("valid_object")) {

• = new DefaultObject();

retry;} else throw e; } } Exceptions

27

Software Engineering / Fernando Brito e Abreu 53 12-Apr-05

Integration

A key activity during construction is the integration of

separately constructed routines, classes, components, and subsystems

In addition, a particular software system may need to be integrated

with other software or hardware systems.

Concerns related to construction integration include:

planning the sequence in which components will be integrated creating scaffolding to support interim versions of the software determining the degree of testing and quality work performed on

components before they are integrated

determining points in the project at which interim versions of the

software are tested

Software Engineering / Fernando Brito e Abreu 54 12-Apr-05

Bibliography

[Bec99] K. Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999, Chap. 10, 12, 15, 16-18, 21. [Ben00a] J. Bentley, Programming Pearls, 2nd ed., Addison-Wesley, 2000, Chap. 2-4, 6-11, 13, 14, pp. 175-176. [Hun00] A. Hunt and D. Thomas, The Pragmatic Programmer, Addison-Wesley, 2000, Chap. 7, 8 12, 14-21, 23, 33, 34, 36-40, 42, 43. [IEEE1517-99] IEEE Std 1517-1999, IEEE Standard for Information Technology - Software Life Cycle Processes - Reuse Processes, IEEE, 1999. [IEEE12207.0-96] IEEE/EIA 12207.0- 1996//ISO/IEC12207:1995, Industry Implementation of Int. Std. ISO/IEC 12207:95, Standard for Information Technology-Software Life Cycle Processes, IEEE, 1996. [Ker99a] B.W. Kernighan and R. Pike, The Practice of Programming, Addison-Wesley, 1999, Chap. 2, 3, 5, 6, 9. [Mag93] S. Maguire, Writing Solid Code: Microsoft’s Techniques for Developing Bug-Free C Software, Microsoft Press, 1993, Chap. 2-7. [Meyer99] B. Meyer, Object-Oriented Software Construction, 2nd Edition, Prentice-Hall, 1999. [McC04] S. McConnell, Code Complete: A Practical Handbook of Software Construction, Microsoft Press, 2nd ed., 2004. [Som05] I. Sommerville, Software Engineering, 7th ed., Addison-Wesley, 2005.