1 implementation. 2 figure 3: kruchten’s “4 + 1”model for developing software architecture + 1...

1

Implementation

2

Figure 3: Kruchten’s “4 + 1”Model for Developing Software Architecture

+ 1 Business Scenario

+ 1 BusinessScenario

+ 1 Business Scenario

View 1

Logical--

End Users

View 2

Process--

System Integrators

View 3

Physical--

Engineers

View 4

Development--

Programmers

This is an innovative andcomprehensive integrationof the abstractions needed to design the structure for writingsystem requirements.

3

Development View -Tools

• Coding Tools- map problem to solution domain; Concurrency

• Testing tools- assures quality• Production tools- translates code into product.• System Management tools-OAM&P• Open Source• Documentation tools -record decisions and system changes.

4

Code Review

#include <stdio.h>#include <string.h> void foo(const char* input){

char buf[10];  printf(“My stack looks like: \n%p\n%p\n%p\n%p\n%p\n%p\n\n”);  strcpy(buf, input);

printf(“%s\n”, buf);  printf(“Now the stack looks like: \n%p\n%p\n%p\n%p\n%p\n%p\n\n”);}

5

Exercise

Can you show how a static buffer overrun can be used to execute arbitrary code in this program? The objective is to find a flaw that has allows an input string that to execute a hack and insert a virus.

6

Can you find the flaw

• Detailed Design leads to fragile software or to robust software.

• How could you prevent the ‘hack’ that can execute a virus?

7

How could you prevent the hack?

• Check to make sure the input string does not exceed the buffer.

• Add this code:

if input > buffer exit, else

strcpy(buf, input)

8

Implementation Processes• Incremental Development

• Component-based design.

• Agile Methods.

• Model Driven Development- maintains architectural integrity

• Autonomic Computing — deals with system operation complexity.

9

Open Source Code

• The developer must be a user and there are:

– No royalties– Accessible source code – Modifications and derivations are encouraged– No person, group or field of endeavor can be denied

access to the program – The rights attached to the program must not depend on

the program's being part of a particular software distribution

– The licensed software cannot place restrictions on other software that is distributed with it.

10

Free Open Source Software (FOSS)

1. The freedom to run the program, for any purpose

2. The freedom to study how the program works, and adapt it to your needs. Access to the source code is a must.

3. The freedom to redistribute copies so you can help others.

4. The freedom to improve the program, and release your improvements to the public, so that the whole community benefit. Access to the source code is again a must.

11

FOSS Development Processes

• Requirements as informal web notes - no apriori spec• Version Control and incremental releases-

‘committer’• Zero Maintenance- evolutionary redevelopment• Layered Meritocracy with virtual project manager

having source control and assignments• Explicit Software Technology Transfer

as reported by Walt Scacchi UCSB

12

A brief aside on measurement

• A fault leads to a failure. It is essential to count everything, not just serious ones, (25:1 spread has been observed between all faults and serious ones).

• Systems are often compared in fault density, (faults per KLOC). This is a function of time. It only makes sense when comparing mature systems, (the asymptotic value).

• Definitions of a line of code can vary considerably, (range of 2:1 in C).

• Definitions of time also vary. For mean time to fail, it is the time of use !

13

Categories of post-delivery failures in 1997 Study

Pe

rce

nt

of

po

st-

de

liv

ery

fa

ilu

res

0

5

10

15

20

25

30

35

Majo

r

Mediu

m

Min

or

Test

ing

Docu

menta

tion

Unass

igned

This data suggests that major / minor failure ratio is somewherebetween 5% and 10%.

CAA Canadian Aviation Authority

14

The NASA data

Errors per 1000 lines at NASA Goddard 1978-1990

Err

ors

pe

r 1

00

0 l

ine

s

0

2

4

6

8

10

12

1976

1978

1980

1982

1984

1986

1988

1990

Low

Average

High

15

16

Strategic importance of reliability

Reliability is of strategic importance to companies. Why ?

17

The growth in maintenance costs

Maintenance

as a % of

typical

Software

Department

Budget

0

10

20

30

40

50

60

70

80

90

100

1960

1965

1970

1975

1980

1985

1990

Source: US Quality Assurance Institute

18

Software maintenance costs

The Microsoft Help Desk costs were reported by Bender (1996) at Star’96 as follows:-

• Cost prior to Window’s 95 was 25,000 calls per day at an estimated $50-100 per call.

Assuming $75 average, this gives $684 million per year.

• It is estimated to have jumped to 100,000 calls per day since Window’s 95, giving an overhead of approximately $2.5 billion per year.

19

The distribution of Life-Cycle Costs

0

5

10

15

20

25

30

35

40

45

Development CorrectiveMaintenance

AdaptiveMaintenance

Perfectivemaintenance

Per

cent of to

tal life

-cyc

le c

ost

Source: NASA, Arnold (1983), Boehm and others

20

Programming Language Complexity

• Fortran 77 ~ 150 pages• Ada83 ~ 280 pages• C90 ~ 190 pages

• FORTRAN 90 ~ 400 pages• Ada95 ~ 600 pages• C++, (1998?) ~ 800 pages (and growing)

21

Development Processes

• Incremental Development:

– Using incremental development, the functionality of the system is produced and delivered to our customer in increments.

– Redirecting the project becomes far easier since one can incorporate changes quickly.

– The incremental approach has allowed us to firstly focus on the essential features of the system.

– Also, additional features can easily be implemented if time allows.

22

Development Processes

• Regression Testing:

– It is a quality control measure to ensure that the newly modified code still complies with its specified requirements and that unmodified code has not been affected by the maintenance activity.

– Regression testing is the selective retesting of a software system that has been modified to ensure that any bugs have been fixed and that no other previously working functions have failed as a result of newly added features.

23

Release Plan

• The game will be posted on the internet through our website for interested users to download and play.

• The installation file will be posted along with our electronic user manual for our game.

24

Coding Standards• Indentation

– Tabs must be exactly 4 spaces– Long lines can be broken at coder’s prerogative.

• Comments – Commenting should be used at a minimum; it should be used to explain the purpose of potentially confusing

areas.– The “/* */” comments will be used to comment out blocks of code, rather than for descriptions, unless

absolutely necessary.• Declarations

– Variables will be defined at the beginning of functions.– Variables must be initialized before use; no initial values will be assumed.

• Global variables– Globals should be used only when other methods will cause performance issues.– Major data variables will be shared among most modules.

• Statements – Multiple statements per line are encouraged where code readability will profit.

• Braces– When using braces “{ }” for blocks of code, they will occupy their own line.

• Naming conventions– Names will use underscores to separate names (e.g., init_models())– Constants will be defined in all capitals (e.g., TERRAIN_MAX_HEIGHT).– Capitals will not be used, except for in constants or where absolutely necessary.

• File organization– Class definitions will be stored in separate header (.h) files.

25

Lessons Learned

• Other responsibilities– Classes: TCP/IP– Work

• Communication• Start coding earlier• Start testing earlier• Slippage• Were too ambitious (caught up in the moment)• More design details• Lack of resources

26

Ethics• Analyze safety and risks

• Read the literature

• Humanize tasks

• Understand the problem, don’t just accepting the customer’s solution

• Respect property rights and privacy

• Ship systems that work

• Advocate ethical behavior

• Stand up and be counted.