2026-2027 BEST option exam study guide for Rodrigo Morales SOEN 341 Software Process Peter Grogono C

2026-2027 BEST option exam study guide for Rodrigo Morales SOEN 341 Software Process Peter Grogono Concordia University Department of Computer Science and Software Engineering Concordia University

Contents 1

Introduction

4

2 Software Engineering

4

3 Software Process

8

4 Course Overview

13

5 Term Project

13

6 Early Process Models

18

7 Modern Process Models

24

8 Requirements

32

9 Domain Analysis

32

9.1

Scope ................................................................................................................................................. 34

9.2 Defining Requirements ................................................................................................................... 35 10 Domain Models

37

11 Use Cases

40

12 Precise Language

44

13 Architecture and Design

51

14 Class Diagrams

55

15 Recommended Architectures

77

16 Design

81

17 Design Principles

85

17.1 Divide and Conquer ........................................................................................................................ 85 17.2 High Cohesion .................................................................................................................................. 85 17.3 Low Coupling ................................................................................................................................... 87

1

17.4 High Level of Abstraction ............................................................................................................... 93 17.5 Reuse ................................................................................................................................................. 94 17.6 Flexibility .......................................................................................................................................... 95 17.7 Obsolescence .................................................................................................................................... 96 17.8 Portability ......................................................................................................................................... 97 17.9 Testability ......................................................................................................................................... 97 17.10 The Big Issues ................................................................................................................................. 98 18 Architecture and Design Principles

101

19 From Domain Model to Design

106

20 Design Documents

111

21 Case study: Therac–25

113

22 Static and Dynamic

119

23 Dynamic Modelling

120

24 User-Centered Design

132

25 Design Patterns

147

26 GRASP

149

27 Midterm 1

151

28 GoF Patterns

152

29 Implementation

161

29.0.1 Traceability ........................................................................................................................ 162 30 Quality Control

171

30.1 Testing Teams ................................................................................................................................. 176 30.2 Integration Testing ........................................................................................................................ 180 30.3 Testing Object Oriented Code...................................................................................................... 182 31 System Testing

190

31.1 Reliability, Availability, Maintainability ...................................................................................... 194 32 Software Reliability Modelling

195

33 Delivery

199

34 Maintenance

201

35 RADARSAT Payload Computer Software System

208

2

36 The Ariane 5 Rocket

219

37 Software Measurement

223

38 COCOMO

226

39 The Software Crisis

230

40 CMM

237

41 97 Things

243

42 Beautiful Architecture

251

42.1 A Tale of Two Systems .................................................................................................................. 251 42.2 Architecting for Scale .................................................................................................................... 260 42.3 Object-Oriented versus Functional.............................................................................................. 267

3

1

Introduction

Introduction • Instructor • Course • Assignments and Exams • Project • Infrastructure 2 The Course Outline contains most of the essential information about the course. Anything missing will be posted on the Moodle site.

2 Software Engineering Characteristics • lots of code • must not only work but also be: – reliable – efficient – cheap – maintainable – useful – desirable – secure • too big for one person • domain-specific knowledge • requires a process

3 Software engineering projects are large: 10 source lines of code (SLoC) up to 10 SLoC. 4

9

The problems of software engineering are both technical (“how do I compute a square root?”) and non-technical (“how do I get 47 modules tested by Tuesday?”) but non-technical problems usually dominate. There may also be technical problems that are not related to software (“what is an asset swapped convertible option transaction?”).

There are many possible criteria by which the success of a software engineering project may be judged.

Which criteria are the most important depends on the application.

4

Building Analogy • change a light-bulb • construct a built-in dresser • kitchen renovation • garden shed • country cottage • suburban house • apartment block • Hall building • Champlain Bridge 4 As the scale of a project grows, its nature does, too. One person with a small amount of technical knowledge can change a light-bulb. But constructing a large building or other structure involves not only many people but also different kinds of knowledge and expertise.

Software is Different • Intangible — hard to feel, judge, evaluate • Hard to make first version — trivial to make a million copies • Labour intensive — minimal automation • “Working” program may not be maintainable • Seems easy to modify — but actually too complex • Software deteriorates — but not like a machine 5 Analogies with other kinds of engineering and industry can be very misleading, because software differs in significant ways from other kinds of products.

Varieties of Engineered Software • Custom software is built for a particular task • Examples: aerospace, finance, web services • Generic software serves a common need • Also called Commercial Off-The-Shelf (COTS) software • Examples: office software, compilers, IDEs, games

5

• Embedded software is a component of a larger system • Examples: flight control, automotive, cell-phone 6 The list of varieties shows only some of the many possibilities.

Features of Engineered Software • Interactive: performs input and output with people or other devices • Batch processing: interacts only with computer peripherals • Distributed: runs on multiple computers on a network • Real-time: responds within specified time limits “soft” real-time: browser “hard real-time: fuelinjection • Certified: has guaranteed properties • Liability: failure may be costly • Generated: created by software rather than programmers 7 These features are not mutually exclusive. A particular software product might be interactive, realtime, and certified.

Why Software ‘Engineering”?

• NATO Software Engineering Conference • Title by Professor Friedrich (“Fritz”) Ludwig Bauer, Technical University of Munich • Definition: Establishment and use of sound engineering principles to obtain economically software that is reliable and works on real machines efficiently.

• Appropriate name ........... or big mistake?

• In some countries (e.g., Canada) “engineering” is a legal term • In 1999, the Canadian Council of Professional Engineers refused to allow graduates of Memorial University’s Software Engineering program to call themselves “engineers”.

• Since then .......... some improvement 8 The word engineering has turned out to be an unfortunate choice for countries in which “engineering” is a “reserved word”: Canada, USA, UK, and elsewhere. Software developers have been forced to adopt standards that are not necessarily appropriate. Software educators have had to choose between adding inappropriate material to curricula and fighting battles with regulating agencies.

In most administrations, fortunately, the established engineers have recognized the growing importance of software and the advantages of allowing software developers into the fold (“If you can’t beat’em, join’em”).

6

Being a Software Engineer A Software Engineer: • is a licensed professional • can “sign off” work completed • is legally responsible for meeting standards and completing contracts • has ethical and professional responsibilities • may achieve more rapid promotion and reach higher positions 9

Being a Software Engineer

10 For the purpose of getting your first job, there is not a lot of difference between a Computer Science degree and a Software Engineering degree. The choice of jobs may differ a bit: small start-ups want people who are smart and can work hard; large corporations with a hierarchical structure might be more interested in software engineers.

Software engineers have an advantage over computer scientists at promotion time. Software engineers have (or should have) received training in “soft” skills such as team work, management, and communication. They will be selected to lead teams, become departments heads, and to move on to higher management.

Example of Liability • ABC Software Inc implemented and marketed software for bridge design, Bridget, that included a stress analysis package • XYZ Contractors Inc bought Bridget, used it to design a bridge, and performed stress calculations • XYZ Contractors Inc contracted PQR Builders Inc to build the bridge • The bridge collapsed during construction, killing several workers • PQR sued XYZ • XYZ sued ABC

7

• ABC were not liable because their stress calculations were warranted for complete structures, not partially built structures

This story had a fortunate ending (for ABC, at least): others may not be not so lucky.

3 Software Process Software Process A software process is a procedure for developing software.

A software process defines: • tasks to be performed during development • sequences in which tasks are to be performed • dependencies between tasks • criteria for task completion 12 There is no particular sense of scale associated with a process. For example, you could define a process for doing your homework. In most cases, however, when people talk about a “software process”, they are thinking of methods for constructing large-scale software.

Tasks Involved in Software Development • Requirements • Design • Specification • Modelling • Implementation • Quality Assurance • Deployment • Maintenance • Documentation 13 A particular project may not involve all of these tasks. The relative importance of the tasks varies between projects.

For example, developing a website for a company is a well-understood problem for which there are many existing designs. After collecting requirements, the developers might choose an existing design and move straight onto implementation.

8

Requirements • Understand the problem • What do users want?

• What do users need?

• Describe in user-oriented language 14 Requirements are a form of contract between the client and the developer. In some cases, requirements documents may actually be the contract (or part of it). They are written in the client’s language (or jargon) because it is important that clients understand the requirements and agrees that a program satisfying them is indeed what they want.

For example, the requirements for a hospital management software must be understandable to doctors, nurses, and other medical professionals.

Design • How will the software work?

• How will users interact with the system?

• How will data be stored and managed?

• What parts (if any) should be done by hardware?

• What components (methods, classes, packages, etc.) will we need?

• How will the components be connected?

15 The design is a bridge between the requirements and the specification. On the on hand, it must be clear that an implementation based on the design will meet the requirements. On the other hand, it must be clear that the design is technically feasible.

If the design does not meet the requirements, the clients may get a system, but it won’t be the system that they wanted. If the design is not technically feasible, the clients may not get a system at all; at best, there will be time and budget overruns, and the final system may not meet all of the requirements.

Specification Precise description of: • what each component does • how each component communicates with other components 16 Specification allows many people to work cooperatively on a large project. The need for people working on different components is kept to a minimum.

Suppose that your job is to implement the database component of a software system. The allowed queries and the intended responses are specified precisely. Your job is to ensure that each query is processed correctly and provides the desired response. You do not have to ask why other components need this information or how they will use it.

9

Modelling • build detailed models of the system • each model addresses particular features: – use cases – structure – dynamic behaviour 17 Models are used in many engineering disciplines to avoid costly mistakes. Models are often small-scale replicas of the real thing. For example, models of buildings are used to give an impression of the appearance of the finished building. Models of aircraft may be placed in wind-tunnels to measure drag and lift.

A model does not necessarily look like the thing that it models. A circuit diagram is a model of an electronic appliance: it shows the components and their connections in an abstract form that can be used for computation.

Similarly, software models do not look like software. Typically, they are diagrams rather than lines of code. People can infer large-scale structure from diagrams more easily then from text.

Implementation • write the code!

18 In small-scale jobs, writing the code is the biggest part of the work. “Programming” is often equated with “coding”.

In a software engineering project, writing the code is usually only a small part of the total work — perhaps 10% or even less. If the preceding steps — requirements, design, and specification — have been done properly, coding should be straightforward. In some cases, coding may not even be necessary, because suitable code can be found in libraries or COTS (commercial, off-the-shelf software).

Quality Assurance • reviews • inspections • tests: – unit tests ensures that components work independently – integration tests ensure that components work together – system tests ensure that the whole system works correctly 19 Quality assurance is a very important part of software development and one that, in the past, has often been neglected. Serious software developers have come to recognize that quality assurance requires extensive resources and is not something that can be tacked onto the end of the development cycle — quality assessment must be performed throughout software development.

10

Deployment • move the software to client sites • upgrade from previous versions • populate databases, . . . .

• ensure that it works on site Stu Feldman: AT&T used over 1,000 makefiles to upgrade switching software.

20

The difficulty of deployment depends on the nature of the software. A customized application for a particular site must be made to work at that site. This should be fairly straightforward, especially if development has taken place st the site.

In most cases, however, the software will be deployed at more than one site. Retailing software, for example, would be installed at each store of a chain. Typically, the clients will have been told to install appropriate hardware, which simplifies deployment.

The most difficult kind of software to deploy is shrink-wrapped software which must run on the hardware of anyone who happens to buy it. The software must perform correctly on all of the millions of permutations of processors, input devices, monitors, etc., that people happen to have. Advances in operating systems have made this kind of deployment easier than it used to be, but it remains a formidable challenge.

Maintenance • correct errors • provide upgrades and enhancements • adapt to new hardware • improve quality without changing functionality 21 Maintenance is usually defined to mean changes made to the software after delivery. Software often has a long life-time: 2 years of development may be followed by 20 years of maintenance. It should not be surprising that the largest cost, over the entire life-time of the software, is maintenance. Early research estimated that 80% of the cost of software was in maintenance; more recent work has raised this to 90%.

The high cost of maintenance implies that developers should do everything possible to make maintenance easy. There are a number of ways to achieve this: one of the most important is good documentation.

Documentation Last but not least . . . .

• all tasks must be documented • documentation is – very important – very difficult

11

• Poor documentation may lead to failure!

22 If you have ever tried to read someone else’s code, you will appreciate the importance of good documentation. There are two possibilities. The most likely case is that the documentation is poor or non-existent, and you will not be able to understand the code. In rarer cases, the code will be well-documented and you will be able to understand it — with the help of the documentation.

Write documentation under the assumption that another person — who you will never meet and has no idea who you are — will be reading it in five years’ time, and trying to reconstruct your thought processes.

Management All of these tasks must be managed: • planning • coordination • scheduling • cost estimation • measurement • reviews 23 All of the foregoing activities must be coordinated and controlled. Good management is essential for successful software development. Dilbert cartoons highlight many of the common errors of management in software and other projects.

Many jokes and horror stories are based on the assumption that managers do not understand what programmers are doing. This problem was actually quite common in the early days of computing, when managers learned their skills before the company obtained computers. It is less common today, because many managers started their careers with technical responsibilities.

MBAs can still cause problems, though: . . . . based on a 2006 study from BusinessWeek, shareholder returns of companies led by CEOs with MBAs were significantly worse than of those led by non-MBA CEOs. www.fool.com/investing/general/2010/03/11/the-problem-with-americas-mba-programs.aspx

Management

24

12

Why is software engineering difficult?

• complexity • many independent details Uncertainty about: – technology – requirements – personnel ability – scheduling • constant change • structure deteriorates during maintenance • political problems 25 There are many ways in which a software project may fail, and many do fail. The best we can do is to learn and follow good practices, recognize risks, and take appropriate measures to avoid them.

4 Course Overview Course versus Book

1 2 3 4 5 6 7 8 9 10 10 11

Theme Understanding customers and users Principles and technology Object orientation Visual modelling Evaluating alternatives Quantitative and logical thinking Iterative and agile development Effective communication Risk management Working in a team Software processes Re-engineering

Book C C C C C C C C C

Course 4 5 1 4 3 5 5 5 4 5 3 3 26

5 Term Project Term Project The project is a Personal Academic Schedule Designer.

13

• The user (student) inputs constraints and preferences.

E.g.: prefer Mon/Wed/Fri; no evenings.

• The software constructs a schedule that: 1. conforms to the Software Engineering program 2. attempts to satisfy constraints and preferences 27 The project was chosen because it addresses a problem that all students have: how to find the best schedule that both meets the requirements of the program and satisfies individual preferences. This means that domain analysis should be trivial: you already understand the problem!

General Requirements 1 • The program uses data provided in the files described below: 1. A file containing descriptions of all software engineering and computer science course and lab sections offered in the academic year 2010–11. You can construct this file by downloading data from http://regsis.concordia.ca/class_schedule/ww701.html. You may also include a small file of approved elective courses from outside ENCS. 2. A file containing all courses required for the program and its options, with their prerequisites.

This file should be created by the team using information from the Undergraduate Calendar for 2010–11. You may choose to download some of this data from http://registrar. concordia.ca/calendar/71/sec71.html.

3. A file containing a subset of the students enrolled in the program. This file should be created by the team using, for example, garbled versions of the names and IDs of teamn members.

Do not use real data for this file.

General Requirements 2 • The program will establish the set of courses to be taken in either or both semesters according to constraints specified by user (day, evening, number of courses, excluded days or times, etc).

• The display should respond interactively to changes in the constraints as they are entered.

• The software package should offer an attractive graphical interface.

29 The project has a number of components. The data must be extracted from various sources and stored somehow, either in a database or in files. Allowed user inputs must be defined and, for each input, an appropriate response must be computed. Users interact via an interface that should be easy and intuitive to sue, as well as looking attractive.

14

Deliverables Deliverables are submitted by teams, not individuals.

0 1 2 3 4

Team members and system overview description Requirements, scope, and plan Architecture and design Implementation and test results Final submission

Jan Feb Mar Apr Apr

14 4 11 1 8

( 2) ( 5) ( 9) (12) (13)

For deliverables 1, 2,and 3, we have provided a skeleton document, with headings and text that describes the material that should appear under each heading. You should replace this text with material about your team’s project.

Deliverables • Deliverables consist of software and documents • All materials must be submitted on the due dates • Instructor and tutor will review submissions and provide feedback • You get a small mark (max. 5) for each deliverable • You may make changes, based on the feedback you receive • You get a larger mark (total 25) for materials in the final submission 31 The marking system allows for the revision that is inevitable in software development. You are marked for your first attempt, but the mark is quite small (5/50 for each deliverable). We will give you feedback on the deliverable and, as a result of the feedback and future work, you may revise the deliverable before the final submission. The deliverable is marked again at the final submission, and so your improvements are taken into account.

Final Submission The final submission consists of the software and the following documents: • User Manual explains the operation of the program from a user’s perspective • Design Documents describe the design of the software • Implementation Notes describe key features of the code, problems encountered and their solutions, guidance for maintainers, . . .

• Test Report lists all tests and their results • Source code consists of all of the code that you have written • Individual Report describes your personal experience of working on the project 32 You can see examples of final submissions, written by previous SOEN 341 students, on the Moodle page.

15

Final Submission • All members of the team receive the same marks for the User Manual, Design Document, Implementation Notes, Test Report, and Source code • Each member of the team receives a mark for their Individual Report • The mark for the Individual Report is based on the quality of the report and your contribution to the project 33 Team work creates a problem for grading. Grades are usually based on individual performance during a course. Students who contribute more than others to a team project sometimes feel that it is unfair that they get the same marks as others, and other students enjoy a “free ride”, knowing that they will get a mark whether or not they do any work. The Individual Report overcomes this problem to a certain extent. A spread of 10 marks can translate into several grade steps.

Why teams?

• Software engineering projects are too large for individuals • Working in a team is different from working by yourself • SOEN 341 and other courses are designed to provide experience in team work • Companies want team workers, not prima donnas • The Accreditation Board encourages team work 34 For many students, the initial response to working on a team is negative. Schools encourage individual performance and collaboration is called “cheating”. (Team sports may be an exception to this generalization.) By the end of the term, however, most students agree that working with a team has been a very positive experience.

SOEN 341 Teams • Team size: 6 to 9 • Each team should elect a Team Leader whose roles are: 1. coordinate the team’s work (e.g., arrange meetings) 2. communicate with the instructor and tutor when necessary • Team work requires civility, cooperation, and collaboration • Disagreements and conflicts are quite likely; learn to handle them!

• Team leaders should report problems that they cannot easily handle to the tutor or instructor before the problem gets serious 35

16

Deliverable 0 • The first deliverable must be submitted on Friday, 14 January 2011 • It consists of: 1. the names and IDs of the team members 2. the name of the elected team leader 3. a brief description of the software that you will deliver • The description is your team’s understanding of the project outline that you have received.

• The outline is vague and ambiguous but your description should be clear and precise.

• You may need help from the tutor or instructor to complete it.

36

Hints for team work • start by getting to know each other • members explain their strengths and weaknesses • decide on procedures: meeting times, communication rules, role of leader, . . .

• expect some conflict and tension • try to discuss problems openly with the team • don’t form cliques • give everyone a chance to talk, even if they’re shy • divide tasks according to skills and interests 37 A team members’s weakness in an area does not imply that the member should not work in that area.

For example, you may be anxious about your coding abilities. You could volunteer to be the “lead writer” of the team to avoid having to do any coding, but a better approach would be to announce that you are not a strong coder but would like to improve; by partnering with another team member who is a good coder, you could learn a lot.

Personalities Myers-Briggs Type Indicator (MBTI) http://en.wikipedia.org/wiki/Myers-Briggs_Type_Indicator extroversion sensing thinking judgment

E — S — T — J —

I introversion N intuition F feeling P perception

People with different MBTI scores are not better or worse, but they are different. When you work with others, you learn to recognize and accept these differences.

38 We may have time to study personalities and their effects on teams later. For now, the important thing to remember is that there are many different kinds of people, and you should not assume that everyone thinks just like you do.

17

6 Early Process Models The Waterfall Model • “Managing the Development of Large Software Systems” Winston R. Royce, 1970 • First attempt at a systematic approach • Based on traditional engineering practices and standards • Rarely read • Attacked as a “straw man” for comparison with other methods

39 You can download Royce’s original paper from the course Moodle page.

The Waterfall Model — as typically quoted

40 The Waterfall Model is often denigrated because there is “no going back” — once a phase is completed, it cannot be revised in any way.

It is called “Waterfall” because that is what it looks like.

The Waterfall Model — with feedback

18

41 Some people acknowledge that the Waterfall Model allows for change, but only change to the previous phase.

The Waterfall Model — from Royce (1970)

42 All of these references underestimate Royce’s contribution, which is much larger than he is usually given credit for.

The Waterfall Model — from Royce (1970) Issues addressed by Royce include: • The basic approach is “risky and invites failure” • Five “additional features” are needed: 1. Construct a complete but flexible design that allows for modification 19

2. Document the design 3. Do it twice The first version delivered to the customer is actually the second implementation 4. Plan, control, and monitor testing 5. Involve the customer 43 People who have not read Royce’s paper assume that he was advocating the Waterfall Model for software development. In fact, Royce’s contribution was to take a process that had been used in other branches of engineering, explain why it was unsuitable for software development, and to suggest ways in which it could be adapted for software development.

The Waterfall Model — from Royce (1970) Royce’s summary: Fig 10 summarizes the five steps that I feel necessary to transform a risky development process into one that will provide the desired product. ........ In my experience, the simpler method has never worked on large software development efforts and the costs required to recover fare exceeded those required to finance the five-step process listed.

44 Royce’s failing was that he did not go far enough. The differences between conventional and software engineering are greater than anyone realized at that time (40 years ago!) and only became apparent as people gained experience with large software projects.

The Waterfall Model — document driven • The Waterfall Model is based on documents • Requirements Analysis yields a Requirements Document • Designers work from the Requirements Document to produce Design Documents • Etc. • Problem: by the time that the first line of code is written, a large amount of work has already been done!

• Mistakes made in early phases are very hard to correct 45

The Waterfall Model — specialities The Waterfall Model created specialized roles for software engineers: • Requirements analysis: analyst, systems analyst • Design: designer, architect • Implementation: programmer, development engineer • Testing: tester, test engineer • Maintenance: maintenance programmer, maintenance engineer 46

20

The Waterfall Model — advantages • managers like it: observable and measurable progress • documents provide a tangible record of accomplishment • fixed “milestones” (at the end of each phase) • budget estimation is feasible (but may be inaccurate) 47

The Waterfall Model — valid criticisms • too much “up front” — early decisions are hard to change • too much documentation • documents say what people want to hear, not what is actually happening • not enough allowance for failure • not enough iteration • does not allow for changing requirements 48 Taking “allowance for failure” to an extreme leads to “trial and error” programming: try something and, if it doesn’t work, try something else. Royce recognized that there effort should be directed towards getting thinsg right the first time, but under-estimated how hard that would be.

Rapid Prototyping “Prototyping as a tool in the specification of user requirements” Hassan Gomaa and Douglas Scott, 1981.

• Idea: build a simplified version of the system that users can evaluate • Analogy: prototypes are used in other engineering disciplines • Car manufacturers build clay models for appearance evaluation 49 The emphasis is on users. The idea is to build just enough to allow potential users to make judgments about the proposed product. For cars, the users can judge only the appearance of the product; you cannot test drive a clay model.

Gomaa and Scott’s original paper can be downloaded from the course Moodle page.

21

Prototyping the Aston-Martin Cygnet

Rapid Prototyping Problem: • Clients have difficulty understanding a design document • Design may overlook important features • Mistakes are found only when software is deployed — too late!

Solution: • Write a quick, cheap prototype early on • Allow clients to try the prototype • Catch mistakes early in the development process 51 A software prototype can offer somewhat more than a clay model. For example, it may be quick and cheap to construct a mock-up of the user interface that allows users to try out various actions, such as adding an entry to a database, even though there is actually no database and their actions have no effect.

Throw-away Prototypes • A throw-away prototype is discarded after evaluation • Alternative: the prototype evolves to become part of the product • Problem: prototype code is not production-quality • Managers do not like to throw out completed work!

52

22

Build one to throw away “Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. Hence plan to throw one away; you will, anyhow.” — Fred Brooks, The Mythical Man-Month “The old mantra build one to throw away is dangerous when applied to large scale commercial applications” — Joel Spolsky 53

Boehm’s Spiral Model “A spiral model of software development and enhancement” Barry W. Boehm, 1986 • Based on Boehm’s work at TRW (Thompson-Ramo-Wooldridge) • Four phases are repeated until product is complete: 1. Determine objectives, alternatives, and constraints 2. Evaluate alternatives, identify and resolve risks 3. Develop and verify the next level of the product 4. Plan next phases • Spiral is risk-driven — decide what is most likely to go wrong and address that first • Intermediate products are called prototypes 54 The Spiral Model is based on observation of how software was actually developed at a large aerospace company. Some projects were more successful than others. Boehm’s observation was that teams who considered risks at an early stage of the process were more likely to succeed than teams who did the easy parts first, putting off difficulties until they had no alternative but to address them — by which time it might be too late.

The spiral model combines the features of the prototyping model and the waterfall model. It is intended for large, expensive, and complicated projects.

Boehm’s Spiral Model

23

55

Spiral Model Each phase: • begins with a design goal • ends with a client review • addresses a significant risk (what might go wrong?)

• extends the code base in some way Risk factors: • cost overruns • operating cost miscalculation • technical prediction failure • market changes 56

7

Modern Process Models

Modern Process Models • Common feature: iteration • Recognition that different problems require different processes • Categories: heavy and light

24

57 Early software projects all looked pretty much the same: an off-line program running on a mainframe.

It was natural to look for a single process model that could be used for any application.

Nowadays, there are many different kinds of applications (as we noted on Slide 4) and different kinds of development process to match them.

Iteration Advantages of iterative development: • there is a working system at all times • clients can try the system and provide feedback • progress is visible, not hidden in documents • mistakes can be identified early on and corrected 58

Iteration Disadvantages of iterative development: • unrecognized early errors may be hard to correct • clients see possibilities and change requirements 59 As an example of failing to recognize early errors, consider a system that depends on a database. In order to get anything working at all, a data model must be defined. The data model is created at an early stage, before all of the details of the problem are completely understood. If the data model is subsequently found to be inadequate, a large amount of work will have to be re-done.

In principle, the Waterfall Model would have avoided this problem, because the data model would not be coded until the requirements analysis and design were completed. In practice, such errors do occur, because analysts and designers are not able to foresee detailed implementation problems.

Modern Process Models “Heavy” processes: • Intended for large, complex projects • Many developers and stakeholders • Lifespan of many years =⇒ evolving developer population • Serious contractual obligations and liabilities • Emphasize formality 60 Heavy processes are appropriate for large companies producing critical software: telecommunications, medicine, aerospace, etc.

25

Modern Process Models “Light” processes: • Usually called agile processes • Small to medium projects • Small to medium size software companies • Emphasize quick results and informality 61 Light processes are appropriate for smaller organizations producing software that is not critical and may be speculative (in the sense that precise requirements may not be known up-front). Examples might include games, web services, etc.

Rational • 1981: Rational Machines founded by Paul Levy and Mike Devlin to develop tools for software engineering • 1985: Rational Environment for Ada development • 1990: Rational Rose introduced, but had poor performance • 1995: OO gurus (James Rumbaugh, Grady Booch, Ivar Jacobson) join Rational and develop UML 1 • 1998 (?): Ban Selic joins, develops UML 2 • 2000: Philippe Kruchten joined and worked on RUP • 2001: Rational has 4,000 employees and US$850 million revenue • 2003: IBM purchases Rational for US$2 billion 62 Rational Software has played a major role in determining how modern software is developed. Their process model (RUP — next slide) and their design notation (UML) are quite widely used in industry.

This does not mean that RUP and UML are the best choice for all projects.

Rational Unified Process • Developed by Rational Software (acquired by IBM in 2003) • Based on Best Practices: 1. Risk-based, iterative development 2. Manage requirements 3. Component-based architecture 4. Models are diagrams (UML) 5. Continuous quality management 6. Continuous change management 63

26

Rational Unified Process The RUP “tripod”: • processes that can be adapted to different projects • tools that support the application of the processes • services that enable people to learn and use the techniques http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process 64

Rational Unified Process

65

eXtreme Programming • Abbreviated to “XP” • Introduced by Kent Beck • Extreme Programming Explained: Embrace Change, Kent Beck, 1999 • Opposite of “heavy” process • Controversial!

66 Proponents of the “heavy” processes, such as RUP, sometimes argue that XP is not capable of producing quality software. In practice, different processes fit different applications. XP was designed for small software shops with a few dozen programmers; it was never intended for large-scale production.

27

eXtreme Programming

67

Basic Practices of eXtreme Programming Planning game Small releases System metaphor Simple design Continuous testing Refactoring

Pair programming Collective code ownership Continuous integration 40-hour work week On-site customer Coding standards

The 12 core practices of XP are: The Planning Game: Business and development cooperate to produce the maximum business value as rapidly as possible. The planning game happens at various scales, but the basic rules are always the same: 1. Business comes up with a list of desired features for the system. Each feature is written out as a User Story, which gives the feature a name, and describes in broad strokes what is required. User stories are typically written on 4x6 cards.

2. Development estimates how much effort each story will take, and how much effort the team can produce in a given time interval (the iteration).

3. Business then decides which stories to implement in what order, as well as when and how often to produce a production releases of the system.

Small Releases: Start with the smallest useful feature set. Release early and often, adding a few features each time.

System Metaphor: Each project has an organizing metaphor, which provides an easy to remember naming convention.

Simple Design: Always use the simplest possible design that gets the job done. The requirements will change tomorrow, so only do what’s needed to meet today’s requirements.

28

Continuous Testing: Before programmers add a feature, they write a test for it. When the suite runs, the job is done. Tests in XP come in two basic flavors.

1. Unit Tests are automated tests written by the developers to test functionality as they write it. Each unit test typically tests only a single class, or a small cluster of classes. Unit tests are typically written using a unit testing framework, such as JUnit.

2. Acceptance Tests (also known as Functional Tests) are specified by the customer to test that the overall system is functioning as specified. Acceptance tests typically test the entire system, or some large chunk of it. When all the acceptance tests pass for a given user story, that story is considered complete. At the very least, an acceptance test could consist of a script of user interface actions and expected results that a human can run. Ideally acceptance tests should be automated, either using the unit testing framework, or a separate acceptance testing framework.

Refactoring: Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn’t break anything because you have the tests.

Pair Programming: All production code is written by two programmers sitting at one machine.

Essentially, all code is reviewed as it is written.

Collective Code Ownership: No single person "owns" a module. Any developer is expect to be able to work on any part of the codebase at any time.

Continuous Integration: All changes are integrated into the codebase at least daily. The tests have to run 100 40-Hour Work Week: Programmers go home on time. In crunch mode, up to one week of overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process.

On-site Customer: Development team has continuous access to a real live customer, that is, someone who will actually be using the system. For commercial software with lots of customers, a customer proxy (usually the product manager) is used instead.

Coding Standards: Everyone codes to the same standards. Ideally, you shouldn’t be able to tell by looking at it who on the team has touched a specific piece of code.

From http://www.jera.com/techinfo/xpfaq.html.

Agile Techniques Manifesto for Agile Software Development http://agilemanifesto.org/principles.html “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions Working software Customer collaboration Responding to change

over over over over

processes and tools comprehensive documentation contract negotiation following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

69

29

12 Principles for Agile Manifesto 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

70

12 Principles for Agile Manifesto 7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity—the art of maximizing the amount of work not done—is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Dilbert does agile

72

30

Summary • Developing software is not like building bridges (50 years experience vs 5000 years experience) • Iteration required • Building software (plan precedes code) doesn’t work • Growing software is better • Many kinds of software; many kinds of process • “Experts” disagree! There is still a lot to learn

73

31

8 Requirements Requirements • The requirements are the things that the software product must do • Requirements are important for both the client and the developer: – Requirements tell the client exactly what they are paying for – Requirements tell the developer exactly what has to be done • Requirements can be seen as a contract between client and developer • Requirements must be understood by both client and developer

74

Clients and Users • Clients and users are not usually the same • Custom software: organization commissions software; employees use it • Retail software: software company performs market analysis; develops requirements; and implements software. Users buy the software.

75

9 Domain Analysis Domain Analysis • The domain refers to the application domain • Examples: medical imaging, finance, simulation, reservation systems, flight control, retail, . . .

• Developers are usually not experts in the application domain • Software engineers need communication skills in order to elicit useful information from domain experts • Domain Analysis is the process of obtaining general information about the application domain 76

Domain Analysis Assume that the developers have performed domain analysis. This will give the some advantages: • effective communication with clients • faster development — because fewer questions need to be asked • better system — avoid mistakes, discover best approaches • anticipation — ability to look ahead to future extensions and improvements 77

32

Domain Analysis Document After domain analysis, the developers should have a document with some or all of this information: • Introduction: name and general features of the domain • Glossary: technical terms and jargon used within the domain • General Knowledge: important facts, rules, conventions, etc., used by workers within the domain • Users: description of the people who will be using the software and their expected level of skill and knowledge • Environment: the equipment that will be needed and where it will be located • Tasks and procedures: the tasks currently performed by the people who will use the software • Existing software: other software products that perform similar tasks • Similarities and differences: compare this domain with others in which the developers already have experience 78 The people who work with developers may not be the people using the software. If you are working for a bank, you will discuss requirements with accountants and managers, but it is the tellers who will be using your software every day. It might be a good idea to interview tellers directly, to find out what they expect, what they do and do not like, etc.

Details of the hardware need not be known in detail at the requirements elicitation stage. However, it will be helpful to know whether the system is to be installed in an air-conditioned vault or on the back of a truck.

Existing software may be co-operative (e.g., part of the developer’s inventory of software from earlier products) or competitive (e.g., a similar package produced by a rival company).

Gas-station: domain analysis Questions to be answered include: • How many varieties of gas are sold?

• What products, other than gas, are sold?

• How frequent are gas sales, gas deliveries, etc.?

• Is there one supplier or many?

• How are taxes calculated and paid?

• What are the technical terms (if any) associated with storage tanks, pumps, quantities of gas, etc.?

• What information must be stored, and for how long?

79

33

9.1

Scope

Scope and Problem Definition • Scope determines what is included and what is excluded from the project • Problem Definition is a concise but complete statement fo the problem to be addressed

Gas-station: scope • Is the software internal to the gas-station, or does it have external responsibilities?

E.g., sending requests for gas to suppliers • Is the software for gas-related expenses and revenues only, or does it also have to handle payments to staff, benefits, etc.?

• Is the software required to make decisions?

E.g., order gas supplies from the cheapest supplier (which requires access to current process, etc.)

• Are auditing controls required?

81

Gas-station: problem definition The system shall: • record all purchases and sales • maintain inventory of products and amounts of gas • provide records in standard format for accountants • store critical data and records off-site • provide point-of-sale services to front-office employees • provide management services for back-office employees

But some people prefer a concise, one-sentence version.

Gas-station: alternative problem definition The system shall: maintain all accounts for the gas-station; store financial records at a secure site; and provide on-line access for management and retail users.

34

Negotiating the scope • The scope of the application is very important to the developers • An apparently small change in the scope may have significant consequences E.g., “The scope of the project includes the development and maintenance of off-site software”.

• “Negotiating the scope” means defining exactly what is, or is not, a part of the application • Consider listing all requirements, but flagging those in scope

Negotiating the scope Example (L&L, page 117): + + registering students − − applications for admission + + recording marks + + printing transcripts − − allocating courses to rooms 85

9.2

Defining Requirements

Requirements: definition A requirement is a statement describing either: 1. an aspect of what the proposed system must do, or 2. a constraint on the system’s development.

In either case, a requirement must contribute in some way towards adequately solving the customer’s problems.

The set of requirements as a whole represents a negotiated agreement amongst all stakeholders.

L&L, page 119

Requirements: varieties • Functional requirements describe the services provided by the system • Quality requirements ensure that the system is usable, efficient, maintainable, etc.

• Platform requirements constrain the hardware and environment of the system • Process requirements constrain the project development methods (i.e., the process) Quality, platform, and process requirements used to be known collectively as non-functional requirements.

87

35

Functional Requirements • inputs • outputs • stored data • computations performed For some systems: • timing • synchronization

Quality requirements • response time • throughput • resource usage • reliability E.g., crashes per month ≤ 1 • availability E.g., down time per month ≤ 5 minutes • recovery from failure E.g., maximum down time per incident ≤ 30 minutes • facilities for maintenance and enhancement • facilities for reuse

Platform requirements • minimum hardware required E.g., RAM, disk space, CPU speed • operating system required E.g., Linux, MacOS, Windows 7 • technologies E.g., must use Oracle database

36

Process requirements • Documentation must exist and be available to the user • Reference to a description of the process • Reference to Capability Maturity Model level E.g., CMM 4 91

10 Domain Models Domain Model • The results of domain analysis may be summarized in a Domain Model • A domain model is usually presented as a UML diagram • UML = Unified Modeling Language • The domain model has boxes and edges • Each box represents an important entity within the domain • Each edge represents a relationship between entities • UML Domain Models are a development of Entity-Relationship (ER) diagrams

92 The domain model diagram can be supplemented by explanatory text.

Domain Model • The term “domain model” is rather vague • Boxes in an early domain model represent entities in the application domain • Boxes in a late domain model represent classes of the system • As the model develops, the links between entities and classes become closer • Some entities may never become classes • Some classes are not derived from entities 93 Several domain models may be developed during the development of a product. The first models should be close to the application domain and should not contain any implementation details.

In many cases, entities in the application domain suggest classes. As the domain model evolves, entities are replaced by classes that represent them in the software. However, there is not a one-to-one relationship between entities and classes.

For example, a domain model might contain the entities Student and Grade. Later on, Student might become a class. But it is unlikely that Grade would become a class: a Grade is better represented as a numerical or string attribute of a Student.

37

Domain Model for a Delivery System

94 The domain includes trucks, packages, customers (who might be senders or receivers), and dispatchers.

Delivery System - detail

95 The notation “1 (link) 1∗” indicates a one-to-many relationship.

Domain Model for Class Projects

38

96

Class Projects - detail

97 In this domain model, edges are labelled with relationships.

Domain Model for Software Engineering

39

Software Engineering - detail

99 An arrow on an edge indicates an “is a” relationship.

11

Use Cases

Use Cases • A use case is a short scenario describing one use of the system • Example: a librarian performs a sequence of actions when lending a book

40

• A collection of use cases tells us a lot about the system • Use cases do not provide a complete set of requirements • Example: automatic back-up features might not be mentioned in use cases • Use cases are described in text and summarized in diagrams 100 Automatic back-up features might be omitted because no actor is involved.

Use case for a library

Borrow book User

Librarian 101

A use case consists of a single action with one or more actors. Actors are represented by stick figures, but are not necessarily people.

Use case model for a library

Borrow book

Renew book

User

Librarian Return book

Pay fine

102 A use case model is obtained by combining use cases. Several actions may be involved. This model is simplified: there are other actions and possibly other actors in a library (consider re-shelving books).

Use case model for a restaurant

41

103

Use case: components • Name: a descriptive identifier for the use case • Actors: list of the actor(s) who can perform the use case • Goals: what the actor is trying to achieve • Preconditions: logical statements that must be true before the use case can proceed • Summary: what happens when the actor performs the use case • Related use cases: other use cases associated with this one • Steps: precise description of each step involved in performing the use case • Postconditions: logical statements that will be true after the use case has been performed 104 A use case has a textual representation as well as a diagram representation.

Withdrawing money from an ATM

Withdrawal User

Bank 105

42

Withdrawing money from an ATM • Name: Withdrawal • Actors: User, Bank • Goals: User desires cash • Preconditions: User has account with Bank • Summary: User obtains cash; Bank provides cash • Related use cases: Deposit, GatBalance • Steps: next slide • Postconditions: User has cash 106

Use case: steps Withdrawal from an ATM: 1. The use case begins when Bank Customer inserts their Bank Card.

2. Use Case: Validate User is performed.

3. The ATM displays the different alternatives that are available.

4. The ATM prompts for an account.

5. Bank Customer selects an account.

6. ATM prompts for an amount.

7. Bank Customer enters an amount.

8. Card ID, PIN, amount and account is sent to Bank as a transaction. The Bank Consortium replies with a go/no go reply.

9. Cash is dispensed.

10. Bank Card is returned.

11. Receipt is printed.

12. The use case ends successfully.

107

Use cases: advantages Use cases: • clarify the scope of the project • guide development: implement important use cases first • validate requirements: a requirement is satisfied if there is a use case that satisfies it • basis for testing: a use case defines one or more tests • structure user manuals: use cases are things that users need to do 108

43

Use cases: potential problems • Use cases must be validated for consistency and completeness Consistency: do use cases contradict each other?

Completeness: are all required actions covered by use cases?

• Important actions may be overlooked if actors are not explicitly involved • If use cases are based on existing behaviours, potential for improved work flows may be missed 109

Summary • Most projects start with requirements analysis • Requirements analysis yields a Domain Model • Use cases provide an effective way of describing requirements • The set of use cases defines a Use Case Model • Use cases may not give complete coverage of requirements 110

12 Precise Language Precise Language Requirements are a form of communication between clients and developers • Requirements must be readable but precise • Careful use of language is essential • Colloquial English is irregular, vague, and ambiguous 111

Escalator signs Shoes must be worn ∀p • Person(p) ∧ onEscalator(p) =⇒ ∃s • Shoes(s) ∧ Wearing(p, s) Dogs must be carried ∀d • Dog(d) ∧ onEscalator(d) =⇒ ∃p • Person(p) ∧ Carries(p, d) 112

44

Pushing buttons Hit blue button

Hit red button • In the Stopped state, it is impossible to Hit red button • You can Hit red button in the Stopped state, but nothing happens • You can Hit red button in the Stopped state, but the effect is unspecified 113

Moving levers Move lever up

Move lever down • In the Lamp ofl state, it is impossible to Move lever down • You can Move lever down in the Lamp ofl state, but nothing happens • You can Move lever down in the Lamp ofl state, but the effect is unspecified 114

Implementation bias • Requirements should not suggest approaches to implementation • Requirements should be expressed in the language of the application domain • Example: “The user makes a choice from a drop-down menu” Problem: prevents the designer from using a possibly better method, such as a radio button • Example: “The system shall consist of these 17 modules: . . .”

Problem: prevents a possibly better structure • Slogan: requirements express “what to do”, not “how to do it” 115

45

Individuals and Collections In an airline reservation system, what is a flight ?

• AC 864, YUL to LHS, 7:40 p.m. daily • AC 864, YUL to LHS, 12 January 2011, 7:40 p.m.

116

Mood Do I drown?

• I shall drown. No one will save me.

• I will drown. No one shall save me.

117

Mood: a US Government requirement • Absolute tense “shall”: a binding, measurable requirement of the system • Future tense “will”: a reference to the future . . . describing something not under the control of the system • Present tense: use in all other cases Recipe for confusion!

118

Indicative and Optative 1. The elevator never goes from floor N to floor N + 2 without passing floor N + 1 2. The elevator never passes a floor for which the floor selection light is illuminated without stopping at that floor 3. When the elevator arrives at a floor, the elevator-present sensor is set to on 4. The doors are never open at a floor unless the elevator is stationary at that floor • Indicative properties are independent of the software.

• Optative properties are requirements of the software.

119

46

Indicative and Optative Not recommended: indicative and optative can be distinguished by “will” and “shall”.

1. The elevator will never go from floor N to floor N + 2 without passing floor N + 1 2. The elevator shall never pass a floor for which the floor selection light is illuminated without stopping at that floor 3. When the elevator arrives at a floor, the elevator-present sensor is set to on 4. The doors shall never open at a floor unless the elevator is stationary at that floor 120

Indicative and Optative Recommended: provide separate sections Intrinsic System Properties: 1. The elevator never passes a floor for which the floor selection light is illuminated without stopping at that floor 2. The doors are never open at a floor unless the elevator is stationary at that floor Required System/Software Interactions: 1. The elevator never passes a floor for which the floor selection light is illuminated without stopping at that floor 2. The doors are never open at a floor unless the elevator is stationary at that floor 121

Aircraft Accidents States of the application domain: • MOVING_ON_RUNWAY • WHEELS_TURNING States of the software system: • WHEEL_PULSES_ON • REVERSE_ENABLED 122

47

Aircraft Accident Requirement (application domain): REVERSE_ENABLED =⇒ MOVING_ON_RUNWAY Assumptions made by designers: MOVING_ON_RUNWAY =⇒ WHEELS_TURNING WHEELS_TURNING =⇒ WHEEL_PULSES_ON Specification (software system): REVERSE_ENABLED =⇒ WHEEL_PULSES_ON 123

Aircraft Accident Problem: MOVING_ON_RUNWAY =⇒ WHEELS_TURNING may not be true if the runway is wet!

124

Shooting yourself in the foot Brent Hoffman: How to Shoot Yourself in the Foot: 7 ways to do software requirements poorly to set your project up for failure and what to do instead. http://requirements.seilevel.com/blog/2010/11/how-to-shoot-yourself-in-the-foot-conclusion. html 1. Don’t do Them at All 2. Don’t Listen to Your Customer’s Needs 3. Don’t use models 4. Use weasel words 5. Don’t prioritize requirements 6. Don’t baseline and change control requirements 7. Don’t do requirements traceability 125

48

Weasel words (Brent Hoffman)

126

Words to avoid Karl Wiegers Describes 10 Requirements Traps to Avoid: http://www.processimpact.com/articles/reqtraps.html minimize maximize optimize rapid user-friendly easy simple often normal usual large intuitive robust state-of-the-art improved efficient flexible and/or etc.

127

Traceability It must be possible to trace every functional requirement back to its origin, which may be: • use case • high-level system requirement • business rule • industry standard • government regulation 128

Examples Bad The UI must use big letters and look nice The system must respond quickly Users with long names should be accommodated

Data entry must be intuitive

Better The UI must use 16pt Arial characters and contrasting background and foreground colours The system must respond within 250 milliseconds to 90% of queries The field for entering a user name must display at least 60 characters and must allow at least 120 characters to be scrolled [Give a list of field labels and describe corresponding entries]

49

129

Examples Bad Most actions can be performed with keyboard and/or mouse Equations of low degree should be solved quickly and accurately

Better The user can perform actions, other than those specified below, with either the keyboard or the mouse The system shall find a solution to a given equation with degree not greater than 3 accurate to 16 places of decimals, provided such a solution exists. The solution time shall not exceed 10 milliseconds.

50

130

13 Architecture and Design Architecture and Design • With requirements ready, we move on to architecture and design • Architecture describes the overall structure of the system • Design describes the detailed structure of the system • Designs can be at various levels: – High-level design – Low-level design – Detailed design 131

Architecture: examples Layered architecture User Interface General Functions Specialized Functions Memory | Input/Output | Network Operating System • Higher layers can call lower layers • Lower layers cannot call higher layers • Build bottom-up • Test one layer at a time 132 The layered architecture is one of the oldest architectures. It was introduced in 1968 by E.W. Dijkstra for the T.T.E. operating system.

We could add a hardware layer beneath the lowest, Operating System”, layer.

Each layer provides an Application Programmer’s Interface (API) to the layer above it.

Architecture: examples • Three-tier architecture • Top layer provides the user interface E.g., browser • Middle layer contains all code for the particular application 133 • Bottom layer provides database access • Provides separation of concern: Logic knows nothing about presentation; Database knows nothing about logic or presentation

51

Communication can go both up and down (in contrast with the layered architecture).

Layers can be changed independently of other layers. E.g., different presentation layers can be used for the same business logic.

The 3T architecture is often used for simple web applications.

Architecture: examples

Model • Model-View-Controller (MVC) Architecture • Model performs application computations • View presents information about the model to the user • Controller coordinates the Model and the View • Provides separation of concern between Model and View • E.g., text editor, simulation, games 134 There can be several views or, less commonly, several models.

The model does not know about the view but may be able to answer queries that are used by the view.

Architecture: examples who • Pipe-and-filter architecture • Pipes transfer data • Filters process data • Applications built as Unix commands use pipes and filters • How many times is Mary logged in? $ who | grep mary | wc -l 135

52

Architecture: examples Enterprise Service Layer Domain Service Layer Application Service Layer • Service-Oriented Architecture (SOA) • Provides a collection of services • Services implemented in different languages • Communication by XML 136 SOA is used to provide web services. It is a loosely-coupled architecture designed for flexibility.

Architecture: examples • Event-driven architecture • Based on events: keystrokes, mouse-clicks, mouse movements, network messages • System responds to each event as it occurs • Events may be queued • System is idle when there are no events to process • Puts user in control (any event at any time) 137

Architecture Architectures: • describe only very general features of the software • can be combined • can be implemented in different ways • provide a guide for the design stage • provide a “language” for designers 138

53

Design • Design follows architecture and adds detail • A design describes the precise structure of the software • The design is derived from the requirements • The designed is typically expressed as a model • For object-oriented programs, the model is a collection of classes • Unified Modeling Language (UML) is a standard notation for models 139

UML • Defines various diagrams: class diagram, object diagram, sequence diagram, etc.

• Use case diagrams are part of UML • UML is supported by many tools • Tools enable diagrams to be drawn, edited, and validated • ArgoUML: http://argouml.tigris.org/ – Java-based – Good, but slightly out of date 140

UML: precursors • 1967: Simula — extended Algol, first OOPL • 1976: Smalltalk — abstracted basic principles of OOP • 1989: Shlaer and Mellor — first attempt at object modelling • 1991: James Rumbaugh — Object Modelling Techniques (OMT) • 1992: Ivar Jacobson — use cases • 1994: Grady Booch — OO development 141 UML is the result of many years of experience with object-oriented programming. There were false starts, leading to techniques that are no longer used, but eventually the good ideas remained.

54

UML: Pros and cons Pros: • Diagrams aid understanding of large systems • Diagrams permit insights that might not come from text • A standard notation ensures that people interpret diagrams in the same way • Tools ensure that diagrams are correctly constructed • Tools can even check that diagrams make sense Cons: • UML is too complex to use for “back of the envelope” diagrams • The need for tools goes against the idea of diagrams — simplicity • Some people are not visual thinkers • UML allows you to write nonsense — but so does any other powerful notation!

142 If the number of classes is small, using UML is overkill. If the numebr fo classes is very large, UML may be inadequate. But we do not really have any good way of describing and modelling very large systems.

UML: basic features • classes represent data (as in OOP) • attributes are data members of classes • operations are methods of classes • associations are relationships between classes • generalizations are inheritance relation between classes 143 UML has many other features. It does not consist entirely of diagrams.

14 Class Diagrams Class Diagrams and Domain Models Similarities: • perform similar roles • define entities and relationships • use the same notation

55

Differences: • class diagram is more detailed than a domain model • entities in a class diagram correspond to classes in the software • entities in a domain model may not correspond to software classes 144 We have already seen domain models in previous classes.

Class Diagrams and Domain Models System

Domain

• The left ellipse (“Domain”) contains everything in the application domain, including entities that do not form part of the system, such as actors in use cases • The right ellipse (“System”) contains everything in the software system, including entities that are not part of the domain, such as remote back-up sites • The intersection contains all entities that belong to both the application domain and the software system 145

Class Diagrams and Domain Models System

Domain

Exploratory Domain Model • Includes all entities of the domain • Excludes entities needed for implementation 146

56

Class Diagrams and Domain Models System

Domain

System Domain Model • Includes domain entities that must be implemented • Excludes domain entities that are not implemented • Excludes entities needed only for implementation 147

Class Diagrams and Domain Models System

Domain

System Model • Excludes domain entities that are not implemented • Includes all entities needed for implementation 148

Drawing a class

Character

Character name model draw update

Character name: string model: Shape draw(): void update: void

• Classes can be drawn at different levels of detail • The simplest description of a class has just a class name • Complete class has three areas: name, attributes, methods 149

57

Drawing a class Character name model draw update

Character name: string model: Shape draw(): void update: void

Text representation — # +

Diagram representation closed padlock half-closed padlock padlock without closure

Character

Diagrams show visibility: Visibility Private Protected Public

150 In subsequent examples, we use the short form for a class, showing only the class name. Most actual class diagrams include at least methods, and often attributes, of classes.

Class names • A class stands for a number of objects (instances of the class) • Instances of the class are created at run-time • The name of a class should be a singular noun • Conventionally, the first letter of a class name is Upper Case • Good: Game, Board, Student, Flight, Address • Bad: pieces, dangerous, fight 151 Choosing good names is a very important part of software engineering.

Class descriptions • Class name only doesn’t say much • It is helpful to give the methods of a class • Attributes are less helpful: if private, they are not, part of the class’s interface 152

58

Class Diagrams • A Class Diagram consists of classes linked by associations • Associations define the relationships between classes • Good design minimizes the number of associations • Every association indicates a dependency — and a chance for something to go wrong!

• A class with many associations is hard to maintain 153

Associations Game 1 players: Vector(Player)

1..*

Player mygame: Game

• A line between classes shows an association • An association may be labelled with multiplicities • “1” means that there is one game • “1..*” means that there may be one or more players 154

Associations • UML does not specify how the classes are associated in the code • Attributes, if given, may show how the association is implemented • Usually, one class will contain a reference to the other class of the association • The references might go both ways, or one way only (more later) 155

Associations Game 1 players: Vector(Player)

1..*

Player mygame: Game

• The association might be represented in class Game as an attribute (vector of Players) • A Player might have an attribute referencing the Game 156

59

Multiplicity Player

1

1

Piece

• “1” at each end of an association indicates a one-to-one relationship • Each player has exactly one piece • Each piece is associated with exactly one player 157

Multiplicity Bridge

1

4

Player

• A fixed number can be used as a multiplicity • A game of Bridge requires exactly 4 Players • This usage is rare: the most common numbers are 0, 1, * 158

Multiplicity Game

1

0..1

Referee

• A multiplicity may be defined by a range • A Game requires either 0 or 1 Referee(s) (The Referee is optional) • 1..3 would mean r Referees where 1 ≤ r ≤ 3 • Lists are also allowed E.g.: 1,3..6,8 corresponds to {1, 3, 4, 5, 6, 8} 159

Multiplicity: summary

60

none one exactly n, where n > 0 n where a ≤ n ≤ b zero or one, aka “optional” n where n ∈ {a, b, c} n where n ∈ {a, d} or b ≤ n ≤ c n where 0 ≤ n n where 0 ≤ n n where a ≤ n

0 1 n a..b 0..1 a, b, c a, b..c, d ∗ 0..∗ a..∗

160

Multiplicity: dangers child

1

Person

2

parent

• Do not over specify multiplicity • Every person is the child of exactly two parents • Implies an infinite number of objects!

Multiplicity: dangers Player

1

1

Piece

One-to-one multiplicity: • Every Player owns exactly one Piece • Every Piece belongs to exactly one Player • Are two classes really necessary?

• Probably better to use one class with NameOfPlayer and NameOfPiece as attributes 162

Labelled associations Player

1..*

plays

An association may be labelled.

The label:

61

1

Game

• suggests the meaning of the association • indicates an action of one class on another • should usually be a verb or verb phrase 163

Labelled associations Player

Armour

• the intended direction of an association is usually obvious • if it isn’t obvious, use an arrow on the label 164

Roles Professor

1 coordinator

* section

Course

• Associations may be labelled with roles • Roles are written close to the class boxes • A Professor is the coordinator of several courses • Coordinated Courses are called sections • “coordinator” and “section” are role names • It is not usually necessary to provide both an association name and role names 165

Many-to-many associations Player

*

Battle

• The multiplicity indicates that: – a Player may fight in zero or more Battles – a Battle may involve zero or more Players • Note that Player and Battle are classes • The model does not say that many Players are engaged in many Battles 166

62

Many-to-many associations Player

*

Battle

Is many-to-many appropriate here? Consider changing * to 1: • If Player had multiplicity 1, then at most one Player could be involved in a Battle — wrong!

• If Battle had multiplicity 1, then a Player could be engaged in only one Battle at a time — questionable Possibility: change the multiplicity of Player to 2..∗ on the grounds that a Battle requires at least two Players 167

Association classes • A Player gets a score for engaging in a Battle • Where do we put Score?

– Score cannot be in Player, because a Player many fight many Battles – Score cannot be in Battle, because a Battle involves many Players • Score belongs to the association between Player and Battle 168

Association classes Player

*

Battle

Score • Score is called an Association Class • Link it to the association with a dashed line • Whenever there is a Player objected associated with a Battle object, there will be a Score object 169

63

Association classes Player

1

*

Score

*

1

Battle

• Alternative placement for an association class • Note the multiplicities: – A Player may be associated with zero or more Scores – A Battle may be associated with zero or more Scores • An association class contains information about the relationship • For each many-to-many association, consider the possibility of association classes 170

Reflexive associations wins

*

Weapon

*

loses

• An association may link a class to itself • This is a reflexive association • The diagram shows a wins/loses association between Weapons – Dagger loses to Axe – Bow-and-arrow wins over Axe – Bow-and-arrow loses to Bomb • It is an asymmetric reflexive association because the roles at the ends are different 171

Reflexive associations *

Weapon

*

mutually exclusive

• A symmetric reflexive association has a single label referring to both entities • Dagger and Bomb related by “mutually exclusive” means that you cannot own both a Dagger and a Bomb at the same time 172

64

Reflexive associations for families *

Person

*

Symmetric

cousin

uncle/aunt *

Person

*niece/nephew

Asymmetric 173 It may be helpful to think of associations as relations. Here is a basic association A

B

and here is the analogy, with UML notation on the left and set-theoretic notation on the right: class A class B Instance: A a Instance: B b Association a and b are associated by r

set A set B Member: a ∈ A Member: b ∈ B Relation: R ⊆ A × B r ∈A×B

A reflexive association corresponds to a relation on a set: R ⊆ A × A. If the association is symmetric, then (a1, a2) ∈ R ⇐⇒ (a2, a1) ∈ R. If it is asymmetric, then

(a1, a2) ∈ R =⇒ (a2, a1) ∈ / R.

Directional associations Player 1..* bd: Board

1

Board

• An association may have a direction • The direction is indicated by an arrow head • A Player must know about the Board • The Board does not know about the Player (possibly incorrect modelling) • If you are not sure about direction, leave it out for now 174

65

Checking associations • Just drawing an association doesn’t make it correct!

• Check each association carefully: – Do the classes have appropriate names?

– Is an association between these classes really necessary?

Think of some methods that might be used.

– Does the name of the association suggest its purpose?

– Do the role names suggest their purposes?

– Are the multiplicities correct?

175

Common problems • Unsuitable or misleading names • Unnecessary association • Two classes where one would do • One class where two are needed • Multiplicity: – ‘*’: are zero instances possible?

– ‘1..*’: are zero instances meaningful? multiplicity ≥ 1 =⇒ must create object – ‘3..5’: are these the only values possible/allowed?

176

Generalization Character

PlayerCharacter

NonPlayerCharacter

• Generalization (inheritance) is indicated by a solid triangle pointing towards the parent class • PlayerCharacters and NonPlayerCharacters are kinds of Player • Inheritance should be used for “is a” or “is a kind of” relationships 177

66

Generalization Bomb

Chemical Bomb power: int

Atomic Bomb power: int

Hydrogen Bomb power: int

• Avoid over generalization • Better model: one class (Bomb) with an attribute (power) • Don’t use generalization when an attribute suffices 178

Generalization Person

Assistant Professor

Associate Professor

Full Professor

• Avoid objects that change their classes • True that an Assistant Professor is a Person, etc.

• But an Assistant Professor x becomes an Associate Professor y • This involves: creating y, copying x’s fields to y; deleting x • Better: use one class Professor with an attribute Rank 179

Multiple Generalization • A generalization hierarchy can be constructed using different criteria • Consider class Animal • Food: HerbivorousAnimal, CarnivorAnimal, OmnivorAnimal • Habitat: LandAnimal, AquaticAnimal, FlyingAnimal

67

• Coat: FurryAnimal, FeatheredAnimal, ScaledAnimal • Avoid unless really necessary • Implementation languages may not support multiple inheritance E.g., Java • Use attributes or interfaces 180

Aggregation

Town

1

*

House

• An aggregation denotes a “part of” relationship • The diamond goes at the collection end • A House is “part of ” a Town • Multiplicity: one Town, many Houses • Town is an aggregate • House is a part or component • Ownership of the aggregate implies ownership of the part • Destruction of the aggregate does not imply destruction of the part 181

Composition Person

1

1

Address

1

1

Company

• A composition is also a “part of” relationship • A composition is a “strong” form of aggregation • When a composition is destroyed, its parts are also destroyed • When a Person or Company is destroyed, its Address is also destroyed • One-to-one relationship: why not make Address an attribute?

Both people and companies have addresses: create a class Address 182

68

Justifying composition Scene

1

*

DrawableObject

This is an appropriate use of composition because: • a Scene is composed of DrawableObjects • rendering a Scene requires rendering all of its DrawableObjects • a Scene should have complete control over its DrawableObjects • destroying a Scene involves destroying its DrawableObjects In all cases, consider the model. If you want to maintain a collection of DrawableObjects that are reused in different Scenes, use aggregation.

183

Justifying composition Car

1

2..6

Wheel

This is not an appropriate use of composition because: • Wheels may be moved from one Car to another • destroying a Car does not imply destroying the Wheels Use aggregation instead: Car

1

2..6

Wheel 184

Interfaces <<interface>>

Draw draw() Artist

Cowboy

draw() paint()

draw() shoot()

• An interface is a stereotype in UML • Stereotypes are written between «guillemets» above the class name • In Java terminology, classes Artist and Cowboy implement interface Draw because they provide the operation draw()

69

• The arrowhead is the same as for inheritance, but the edges are dashed • UML provides other notations for interfaces 185 Stereotypes are an extension mechanism of UML. There are a number of pre-defined stereotypes (including «guillemets»), but you can your own stereotypes if you need them. For the benefit of readers of your diagrams, however, you should define a new stereotype before you use it.

Notes Weapon

Weapons are to be used only in self-defence.

load() draw() shoot() • Diagrams can be annotated • Write the note in a box with a folded corner

• Attach the note to a box or edge with a dashed line • Use notes sparingly to clarify diagrams when needed • A diagram with many notes will be cluttered and hard to understand 186

Developing a class diagram • Domain analysis yields exploratory domain models • Entities in these models are candidate classes • Select classes that will actually be implemented • Use these classes in a system domain model • Add labelled associations to the system domain model • Iterate and refine!

187

Discovering classes • A class should have a name • If you can’t think of a good name, it’s probably not a class • A class should have responsibilities • A responsibility is a set of related tasks that instances of the class must be able to perform

70

• Choose some operations based on the responsibilities • Choose attributes that will be required to meet the responsibilities • Iterate!

188 If you cannot think of any non-trivial responsibilities, you probably don’t have a class.

If you can think of many responsibilities, you may have several classes.

You should be able to describe a class in one sentence.

Example: class Counter • Choose a name: Counter • Responsibilities: – store value of count (positive integer) – reset the counter (set to zero) – increment counter – yield value of counter • Result: Counter value: int reset(): void increment(): void getValue(): int 189 The Counter class is about as simple as it gets. Any simpler, and it would not deserve to be a class at all!

Designing a board game Use case:

Game

System boundary

User

• User initializes Game • User interacts with Game until the game is finished • The System boundary shows that the software includes the Game, but not the User 190

71

Designing a board game • There is a Board • There are some Pieces on the Board • There are one or more Players • A Player is implemented either as a HumanPlayer or as an AutoPlayer who uses artificial intelligence • There is a Referee who checks the legality of moves 191

Classes Referee

Board

Player

Piece

HumanPlayer

AutoPlayer 192

Responsibilities • The Board holds the positions of the pieces • A Player chooses moves • The Referee checks moves for legality and plays them • A Piece knows where it can legally move to 193

A better use case

Board

System boundary

Player

Referee

72

• Player and Referee are internal to the program • The System boundary shows that all of the components displayed are part of the software to be built 194

A better use case • Referee asks Player to move Player might be HumanPlayer or AutoPlayer • Player responds with move • Referee checks that move is legal • Referee implements move • Referee checks for end of game 195

Associations • Referee can see the Board • Pieces are owned by the Board • Player can see the Board • Player sends move to Referee for validation • Player generalizes HumanPlayer and AutoPlayer 196

Associations

HumanPlayer

Referee

Board

Player

Piece

AutoPlayer 197

73

Multiplicities • There is one Referee and one Board • Since Referee/Board is one-to-one, should these classes be combined? Probably not in this case — the result would be a very complex class!

• There are several Pieces on the Board • There are several Players in the game • Use ∗ or k..∗ for Players? ∗ provides full generality 198

Multiplicities Referee

1

1

Board

1

1

1

*

Player

HumanPlayer

* *

Piece

AutoPlayer 199

Association names Using the Design slide: • The Referee validates move of Player • The Referee controls the Board • The Board holds Pieces • The Player looks at the Board (but cannot move Pieces directly) 200

74

Association names Referee

1

controls

1

1 validatesMove

looksAt

*

Player

HumanPlayer

1

*

Board 1 holds *

Piece

AutoPlayer 201

Operations A Player must be able to: • move A Referee must be able to: • initialize a Board • validate a Player’s proposed move • make a Player’s move 202

Operations A Board must be able to: • report the position of a Piece • move a Piece A Piece must be able to: • report its position • move 203

75

Operations Referee

Board 1

initialize() validate() move()

controls

1

1 validatesMove

looksAt *

Player

1

report() move() 1 holds *

Piece *

report() move()

move()

HumanPlayer

AutoPlayer

move()

move() 204

Tracing Check that the operations support each step of the use case: • Referee asks Player to move: Player/move() • Player responds with move: Referee/move() • Referee checks that move is legal: Referee/validate() • Referee implements move: Board/move() • Referee checks for end of game: need to add that!

205

Review • The Referee must check legality and a Piece knows where it can move to, but how does a Referee find out what a Piece can do?

• Solutions 1. add an association between Referee and Piece 2. pass messages between Referee and Piece via Board 3. provide the Referee with information about Pieces • If we use #3, do we need Piece at all?

206

76

15 Recommended Architectures Architectures for Project Strongly recommended: • Model-View-Controller Architecture • Three Tier Architecture = Web Enterprise Architecture (WEA) 207 These architectures are the most suitable for the term project. Using them will help you to avoid serving up a dish of spaghetti at the end of the term.

Model-View-Controller Architecture

Model • Model contains the “domain logic” of the application • View updates the user interface • Controller listens to events and passes them to Model and View 208 We have seen this before; here are some more details. The important thing about MVC is that it separates concerns.

Model-View-Controller Architecture MVC in a web application: • Model manages and stores all the information (e.g., DB) • View generates HTML for the browser (e.g., JSP, ASP) • Controller accepts ’post HTML’ from the browser (e.g., CGI) 209

Model-View-Controller Architecture MVC in Java: • Swing provides many instances of MVC • Model is derived from class AbstractListModel

77

• View is realized as an instance of JList • Controller invokes fireIntervalAdded or fireIntervalRemoved More at:

http://en.wikipedia.org/wiki/Model-View-Controller 210

Model-View-Controller Architecture MVC sequence: • User interacts with User Interface (UI) • Controller receives an event • Controller sends a message to Model • If the event requires an update to the UI: – Controller sends a message to View – View sends a query to Model, asking for new information – Model replies with new data – View refreshes display • Variations exist 211 The above is a fairly strict interpretation of MVC. Other models allow the Model to inform the View that something has changed, rather than waiting for the View to send queries. However, it’s usually best if the Model does not know anything about the View(s).

Model-View-Controller Architecture MVC advantages: • Separation of concern: domain logic is separated from user interaction • Model and View can be developed and maintained independently • Multiple views can be provided 212

High coupling in MVC

78

Model

View

P

A

Q

B D

R C

S

Problem: too many associations between Model and View 213 “High coupling” means that there are too many associations between classes. High coupling suggests bad design. We will study coupling in detail later.

High coupling in MVC Model

A

View

P

B

Q X

D

Y R

C

S

Solution: introduce “interface” classes X and Y (Façade pattern) 214 “Design patterns” are intended to help designers by providing generic solutions to common problems.

Many patterns suggest ways of reducing coupling. The “Façade” pattern is a coupling-reducing pattern.

Web Enterprise Architecture

79

• Client-Server architecture derived from MVC and Three-Tier architectures • Presentation Layer interacts with the user • Business Logic Layer does the computations • Data Access Layer stores persistent information 215 Web Enterprise Architecture (WEA), like MVC, is based on separation of concern. Each layer performs a particular function with only minimal dependencies on the other layers. Ideally, layers are interchangeable. For example, the UI can be changed without changing the business logic.

Web Enterprise Architecture Advantages: • Any layer can be replaced without affecting the others • Presentation Layer: technology, platform, network changes • Business Logic: evolving functionality • Data Access: scalability, technology, network changes 216

Web Enterprise Architecture MVC triangular topology single-platform model and view interact

versus

WEA linear topology physically separate platforms presentation and data isolated 217

Web Enterprise Architecture WEA in practice: • Presentation Layer is often a browser • Business Logic typically implemented in Java EE, ASP.NET, PHP, etc.

• Data Access layer may use a DBMS such as MySQL, Access, Oracle, etc.

218

80

Web Enterprise Architecture Problems: • Inconsistent data representations • Custom transformations and mapping logic needed • Object model is inconsistent with relational database • Object collections may not match database queries • CRUD (Create, Update, Delete) complicated due to data transformations More

at:

http://www.dotnetfunda.com/articles/article207.aspx 219

16 Design Design is the second main phase of software development, following requirements analysis. As usual, this definition represents a simplified view of development because, in practice, design is interwoven with ongoing development in other phases.

Design • Design is the bridge between requirements and implementation • Use the design to: – check that requirements are satisfied – write the code • Design produces artifacts E.g., class diagrams 220 Design looks both ways in the development cycle: backwards, because the design must match the requirements; and forwards, because the design must be implementable.

Rationale • Designing requires many decisions • Decisions must be recorded • Record of decisions is the design rationale • Rationale answers: – Why did we do it this way?

– Why did we not do it that way?

• Rationale is essential for good maintenance

81

221 Rationale is important in many areas of software engineering, as well as in other disciplines.

H. L. Mencken: For every complex problem, there is a solution that is simple, neat, and wrong.

Albert Einstein: For every problem there is a solution which is simple, obvious, and wrong.

Whoever actually said it, he was right. We often pick the simple, obvious, and wrong solution first and do some work on it — design, code, whatever. Later on, we realize it is wrong, and correct it.

This step must be documented. If it isn’t documented, a maintenance programmer is going to look at the code, recognize the “simpler” solution, and make the same mistake all over again.

Definitions Component: software or hardware that has a well-defined function and can be replaced by an equivalent component.

E.g., monitor, database.

Module: component defined in software.

E.g., package, class, method, file.

System: logical entity consisting of hardware and software.

E.g., box game, bank.

Subsystem: a system that is part of a larger system.

222 The definitions are a bit fuzzy and the words are often used with different senses.

Strategies Top-down design: • start by designing the largest structures and progressively refine them, working towards smaller structures • Advantage: maintains “big picture” view • Disadvantage: testing is difficult because there is nothing to test until the final stages • Risk: bad decisions may lead to messy or even unimplementable components 223

82

Strategies Bottom-up design: • start by designing the “building blocks” and then link the designs to obtain larger structures • Advantage: everything “works” at each stage • Disadvantage: there is no “big picture” view • Risk: may design components that are unsuitable or even useless for the application 224

Strategies Mixed top-down and bottom-up: • combines the advantages of each approach • avoids the risks and disadvantages of both approaches 225

Varieties of design Architecture: • defines a software architecture • determines very general features of the software.

E.g., MVC or Three-Tier • also called “high-level design” • produces class diagram, etc.

226

Varieties of design Class design: • design of individual classes • follows architectural design • fills in details of attributes, methods, associations, states, . . . , of a class 227

83

Varieties of design User Interface (UI) design: • specifies what the user can see and do • very important and very difficult • major field of research: Human-Computer Interaction (HCI) • most common: “graphical” User Interface (GUI) 228

Varieties of design Database design: • decide how to model data for persistent storage • trade-offs between speed of access, volume stored, convenience, etc.

229

Varieties of design Algorithm design: • choose the most appropriate algorithms for the application • exceptionally, design an algorithm specially for the application • main concerns are time and space 230

Varieties of design Protocol design: • decide how components communicate • normally, choose a standard protocol (TCP/IP, UDP, FTP, HTTP, POP3, etc.)

• exceptionally, design a special purpose protocol • XML is a customizable standard protocol 231

84

17

Design Principles

Design Principles • There are no “formulas” for good design • Design principles are a guide to design • Usefulness of a principle depends on the application 232

17.1

Divide and Conquer

Divide and Conquer • split a large system into subsystems that can be designed separately • Advantages: – smaller systems are easier to understand – several people can work on different subsystems concurrently – make good use of specialists – independent subsystems allow efficient maintenance – potential for reuse • Risk: subsystems may not work together 233

17.2

High Cohesion

Increase Cohesion • Cohesion = if things belong together, keep them together 234

Increase Cohesion Functional Cohesion: a module performs a single well-defined task without side-effects E.g., obtain a list of courses offered Layer Cohesion: in a layered architecture, a layer uses the services provided by the layer below and provides services for the layer above E.g., domain logic layer in 3T Communication Cohesion: modules that access and manipulate a class of data are kept in a single subsystem E.g., access to course data

85

Sequential Cohesion: a set of modules that perform a sequence of operations on the same data should be kept in a single subsystem E.g., obtain image/filter noise/balance colours/render 235

Increase Cohesion Procedural Cohesion: a set of procedures that form closely-related tasks should be kept in a single subsystem E.g., procedures related to student records Temporal Cohesion: a set of procedures performed at the same time should be kept in a single subsystem E.g., initialization Utility Cohesion: a set of procedures that do not fit together in any logical way might be kept in a single subsystem E.g., math library 236

Increase Cohesion Cohesion: difficulties • Different kinds of cohesion conflict • Example: 1. initialization of student data 2. initialization of course data • According to procedural cohesion, #1 should go with other student procedures and #2 should go with other course procedures • According to temporal cohesion, #1 and #2 should go with other initialization procedures • Solution: cohesions are ranked 237

Increase Cohesion Cohesion ranking Strongest

Weakest

Functional Layer Communication Sequential Procedural Temporal Utility

one task, no side-effects related services in a hierarchy tasks related to one kind of data tasks that produce and consume data tasks that must be performed one after the other tasks performed at the same time collection of miscellaneous tasks 238

86

17.3

Low Coupling

Reduce Coupling • Coupling = interactions between components • Fewer interactions =⇒ less coupling =⇒ better 239

Reduce Coupling • Some coupling is inevitable • Association usually implies dependency • Several kinds of coupling • Goals sometimes conflict, as with cohesion • Coupling strength ranked, as with cohesion 240

Coupling A

B

C

D 5 classes At least 4 associations

E N classes At least N − 1 associations 241

Coupling A

B

C

D

E

87

5 classes At most 10 associations

N classes At most 21 N (N − 1) associations 242

Varieties of Coupling Content Coupling: a module secretly changes data in another module Common Coupling: global variables couple the modules that use them Control Coupling: the control flow of a method depends on the values of the arguments passed to the method Stamp Coupling: references to application classes are passed as arguments to methods 243

Varieties of Coupling Data Coupling: instances of primitive or simple classes (e.g., String) are passed as arguments Routine Call Coupling: a sequence of calls must occur in a particular order Type Use Coupling: a module uses a type that is defined in another module Inclusion/Import Coupling: a module imports a package (Java) or #includes a file (C) External Coupling: a module has a dependency on something that is not part of the system E.g., shared libraries, operating system, hardware 244

Examples of Coupling • Examples use C++ • Some forms of coupling cannot be expressed in Java • This is an advance in programming language design!

• Imagine that these snippets come from a very large code base • ’. . .’ indicates a possibly large gap (many pages of code, separate files, . . .)

245 C++ is an older language than Java. It is also a “wide-spectrum” language, meaning that it provides both high-level abstractions and low-level features for interacting with the hardware. Consequently, C++ provides many ways of creating a bad design.

Java, introduced in 1995, was able to avoid many of the mistakes made in earlier languages. Some forms of coupling are intentionally prevented by features of the language.

88

Content Coupling class Counter { // Invariant: value >= 0 public: Counter() { reset(); } void reset() { value = 0; } void increment() { ++value; } int read() { return value; } int value; }; 246 The author of class Counter asserts that the value of the counter can never become negative. This might be true if value was declared private, but it is in fact public.

Content Coupling . . . class Sneaky { public: Sneaky(Counter & c) { c.value = -1; } }; 247 When an instance of class Sneaky is constructed, it sets the value of Counter c to class invariant of Counter. This is content coupling.

In this case, the fix is obvious: don’t allow public attributes!

Common Coupling const double PI = 4 * atan(1); . . . class Circle { public: Circle(double r) { radius = r; } double circumference() { return 2 * PI * r; } private: double radius; };

89

— 1, violating the

248 At an early stage in development, the developers decide that π is used throughout the system and should have a global definition. The class Circle uses this definition.

Common Coupling “House Bill 1246: Be it enacted by the General Assembly of the State of Indiana, That it has been found that a circular area is equal to the the square on a line equal to the quadrant of the circumference.”

249

Common Coupling const double PI = 4; . . . class IndianaCircle { public: Circle(double r) { radius = r; } double circumference() { return PI * r; } private: double radius; }; 250 At a later stage, a programmer from Indiana (where a law was passed in 1897 decreeing that π = 4) joins the project. This programmer finds the definition of π, changes it, and writes his own class IndianaCicrle. The owners of class Circle are now puzzled because they are getting incorrect values for circumferences. This is an example of common coupling.

Avoid global definitions as much as possible. Maintain careful control over the global definitions that you must have. For example, one team member might be made responsible for all changes to global definitions.

Control Coupling enum ENV { LAND, SEA, AIR }; . . . class Globe { public: void travel(ENV e) { switch (e) { case LAND: driveCar(); break; case SEA: sailShip(); break; case AIR: flyPlane(); break; } } }; 90

251 The control flow in method travel depends on the value of the parameter e. The effect is defined only for values of e in the enumeration ENV. Later on, someone adds SPACE to the enumeration: travel does nothing for this case, and gives no warning that anything is wrong. This is control coupling.

In general, all conditional statements (if and switch) should be checked carefully to make sure nothing can go wrong.

Stamp Coupling class Expenses { public: double mileage(const Car & c) { return distance * c.mpg; } private: double distance; }; 252 Passing a reference to an instance of class Car to method mileage couples classes Expenses and Car and is an example of stamp coupling. In this case, the coupling could have been avoided by passing the value of mpg instead of the entire object.

Data Coupling class Expenses { public: void tourism(string place) { itinerary += place; } private: string itinerary; }; 253 The method tourism and the attribute itinerary create coupling between class Expenses and the built-in class string. This is data coupling. It is less serious than stamp coupling.

Type Use Coupling enum ENV { LAND, SEA, AIR }; . . .

91

class Globe { public: void travel(ENV e) { switch (e) { case LAND: driveCar(); break; case SEA: sailShip(); break; case AIR: flyPlane(); break; } } }; 254 Class Globe uses the type ENV which is defined elsewhere in the program. This is type use coupling and the potential problem is that someone may change ENV without checking each place in the code where it is used.

Inclusion/Import and External Coupling // File foo.cpp #include "bar.h" #include <math.h> 255 The #include directives create coupling between the components foo.cpp and bar.h (inclusion/import coupling ), and between foo.cpp and math.h (external coupling). Some coupling of this kind is unavoidable, but good design should minimize it.

More Sneaky Coupling class Rabbit { public: void init() { time = 0; f.init(*this); assert(time == 0); } void update() { time += 10.0; } }; 256

92

More Sneaky Coupling class Fox { public: void init(Rabbit & r) { r.update(); } }; 257

How to reduce coupling • Import only the components that you really need • Declare all attributes private • Provide get() methods only when needed • Avoid set() methods as much as possible • Using get() and set() on all attributes is not OOP! • Pass just the data needed, not whole objects 258

17.4

High Level of Abstraction

High Level of Abstraction • Abstraction means ignoring details (for now) • Focus on essential ideas • Delay decisions until necessary information is known • In classes, attend to methods before attributes 259

Abstraction Mechanism An abstraction mechanism in a programming language: • is associated with an entity, X • allows instances of X to be named • allows named instances of X to be invoked • provides a way of passing arguments to X 260

93

Abstraction Mechanism Examples: • Void methods abstract statement sequences • Value-returning methods abstract expressions • Classes abstract a group of methods with associated data • Packages abstract a group of classes 261

17.5

Reuse

Design for Reuse • Design simple components with few parameters • Avoid system-specific details in a utility class E.g., values returned by class Date should not depend on the phase of the moon • Do not spend too much time worrying about reuse — get on with the project!

262

Design with reuse • If suitable artifacts from earlier projects are available, use them • Build a collection of “reusable components” • Don’t keep reinventing wheels!

263

Hooks • A hook provides a way for another user to modify behaviour • Hooks are better than lots of parameters • Frameworks provide nothing but hooks • Example: \setbeamertemplate{frame end} { \refstepcounter{framecounter} \hfill \fbox{\theframecounter} } 264

94

Reuse Barriers • Poor quality Wise programmers will not reuse components that are incorrect, unreliable, or inefficient • Complexity Wise programmers will not reuse modules that are hard to understand or poorly documented • Incompatibility Modules designed for reuse should use only stable technology • Cloning DO NOT copy and paste code from one part of the software to another 265

Reuse in practice • Reuse was intended to be a benefit of OOP • People imagined plugging objects together to build systems • This has happened, but: – only to a very limited extent – only in specialized areas • People imagined building collections of reusable components • Problems encountered include: – effort spent building collection must be charged to project – “reusable” components were hard to reuse 266

17.6

Flexibility

Design for Flexibility • Also called adaptability • Anticipate future changes • Design so that changes can be made easily • Reduce coupling, increase cohesion • Use abstraction • Flexible ⇐⇒ reusable • Eliminate hard-coding 267

95

Hard-coding • Also called hard-wiring • Refers to anything in the code that: – reduces flexibility – complicates maintenance • Constants belong in configuration files, not in code Numbers, file names, URLs, codes, error messages, . . .

• System dependent code belongs in dedicated modules 268

Hard-coding example Canadian National, circa 1973: fare = 0.56 * distance(a, b); if (a == "Brockville" && b == "Belleville") fare = 32.50; else if (a == Moose Jaw" && b == "Medicine Hat") fare = 55.75; else . . .

269

17.7

Obsolescence

Anticipate Obsolescence • Special case of “design for flexibility” • Avoid: – Early releases of third-part hardware and software – Libraries with system or technology dependencies – Undocumented features of hardware or software – Products without long-term support • Use: – Standard languages and technologies – Products supplied by multiple vendors 270 A Montreal company for whom I consulted refused to use Eiffel, even though it was the most appropriate language for their application, because it was available only from Bertrand Meyer’s company Interactive Software Engineering.

96

17.8

Portability

Design for Portability A software system is portable if the effort required to adapt it for another platform is significantly less than the effort required to rewrite it for that platform.

• Portability used to be hard to achieve • Try porting a C++ program from Linux to Windows!

• Portability is easier to achieve today • Java programs are portable because they use the JVM rather than the OS • Portability issues still exist E.g., Mac ↔ Windows • Avoid system dependencies • Avoid libraries with system dependencies 271

Endianness • Send a 32-bit integer over a network • At the network level, 4 bytes are sent • In what order are they sent: – least significant byte first or – most significant byte first?

• Least significant first = little endian x86, x86-64, VAX • Most significant first = big endian 68000, IBM Power, System/370 • Endianness creates portability issues 272

17.9

Testability

Design for Testability • Testing should be automated • Testing the UI is hard: another reason to keep it separate!

• Include testing methods in classes main in Java 273

97

17.10

The Big Issues

Design — The Big Issues • Modularity • Encapsulation • Separation of Concern • Reuse • Maintenance 274

Modularity • Modules should be interchangeable components • A minor modification to the system should affect only one module • A major modification should affect only a few modules • Modules should be usable in many systems • Prefer small modules 275

Encapsulation • A module should keep a secret • Representation is a simple secret • Operations are important, not data • A module must ensure the integrity of its data • David L. Parnas (1972): information should be hidden 276

Separation of Concern • A module should be fully responsible for one task • Examples: – UI performs all interaction with user and nothing else – Database stores persistent data and provides access to it – CSS determines style; HTML determines content

98

– Scanner extracts tokens from source code – Parser builds parse trees from tokens – Game logic is separated from rendering – MVC, WEA, etc.

277

Reuse • Low-level reuse is often used E.g., input/output, math, graphics, etc.

• High-level reuse is less common • Emphasize generalities, avoid specifics 278

Maintenance • Maintenance accounts for up to 90% of the cost of a software product over its lifetime • Maintainability is a key factor in every phase of development • Aids to maintenance: – readable, complete, accessible documentation – clear, simple design – clear, simple code — no clever tricks – modularity – separation of concern 279

The Book and the Course 1 Software and software engineering 2 Review of object orientation 3 4 5

Basing software development on reusable technology Developing requirements Modeling with classes

6

Using design patterns

Covered during the course Light coverage — you should know most of it!

Coming later 280 Already covered, but more to come Partly done (class diagrams), other diagrams to come Coming later — light coverage

99

The Book and the Course 7 Focusing on users and their tasks 8 Modeling interactions and behaviour 9 Architecting and designing software 10 Testing and inspecting to ensure high quality 11 Managing the software process 12 Review

Coming later Coming soon Design principles — what we are doing now Coming later Coming later — light coverage Yes

100

281

18 Architecture and Design Principles Architecture and Design Principles • Architectures are based on design principles • A particular architecture may emphasize particular principles • Subsequent slides show how architectures support principles 282

Layered Architecture • Application consists of layers • Each layer uses services provided by the layer below it • Calls go down but not up 283

Layered Architecture • Divide and Conquer: Separate layers can be designed independently • Increase Cohesion: Well-designed layers provide layer cohesion — tasks within a layer are closely related to one another, but not to other layers • Reduce Coupling: Lower layers do not know about upper layers Higher layers can be replaced without impacting lower layers • Increase Abstraction: Higher layers do not have to know implementation details of lower layers A layer needs to know only the API of the layer below it • Increase Reusability: Lower layers can be designed in a way that may allow their use in other systems 284

Layered Architecture • Increase Reuse: Take layers that provide useful services from other systems • Design for Flexibility: A well-designed layer allows for uses outside specific requirements • Anticipate Obsolescence: When a layer becomes obsolete, it can be replaced by another layer providing the same API • Design for Portability: Platform dependencies can be isolated in lower layers • Design for Testability: Each layer can be tests independently provided that the layers below it are either available or can be simulated • Design Defensively: APIs can validate their inputs, avoiding undetected errors 285

101

Client-Server Architecture • At least one component that acts as a client making requests • At least one component that acts as a server providing services • Connection (e.g., network) between components • Extends to WEA, etc.

286

Client-Server Architecture • Divide and Conquer: Clients and servers can be developed independently, provided that the communication protocol has been specified • Increase Cohesion: Services are confined to the server • Reduce Coupling: There is only one channel between server and client, however complicated they are • Increase Abstraction: Distributed components make good abstractions; clients do not have to know how the server works 287

Client-Server Architecture • Design for Flexibility: Client-server systems can be reconfigured by adding extra servers and clients • Design for Portability: A component may run only on a particular platform, but protocols enable it to communicate with components running on different platforms • Design for Testability: Clients and servers can be tested independently • Design Defensively: Services can check requests from clients Clients should perform validity tests to ensure the honesty of the server 288

Broker Architecture • A Broker hides details (e.g., location) of a remote object • Clients call the broker • Broker passes call to any object that can handle it, locally or remotely • Remote objects may change without informing caller • E.g., Common Object Request Broker Architecture (CORBA) 289

102

Broker Architecture • Divide and Conquer: Remote objects can be designed independently • Increase Cohesion: Remote objects can be used by different clients • Increase Reuse: Remote objects can be reused in different systems • Design for Flexibility: Broker objects can be updated as required • Anticipate Obsolescence: Reliance on protocols enable components to run on different (or updated) platforms • Design for Portability: Remote objects can be written or new platforms without invalidating those running on current platforms • Design Defensively: Remote objects can check requests thoroughly 290

Transaction Processing • Dispatcher accepts requests (“transactions”) one at a time • Dispatcher chooses a suitable processor for the transaction • Dynamic binding in OOP is a low-level example of a transaction processing architecture 291

Transaction Processing • Divide and Conquer: Different teams can work on different transaction handlers • Increase Cohesion: Each transaction handler performs a simple, complete, well-defined task • Reduce Coupling: Coupling between transaction handlers is very weak • Design for Flexibility: It is easy to add new transaction handlers • Design Defensively: Each transaction can check its inputs 292

Pipe and Filter • Pipes move data around the system • Filters process data • Most filters have one input and one output • Data formats are standardized, so that components are interchangeable • E.g., sound processing system with:

103

– noise reduction – echo cancelling – equalization – compression – frequency filtering – reverberation 293

Pipe and Filter • Divide and Conquer: Processes can be designed independently • Increase Cohesion: Each process has functional cohesion • Reduce Coupling: Each process has one input and one output: minimal coupling • Increase Abstraction: Processes hide their internal details • Increase Reusability: Processes can be used in different applications • Increase Reuse: Processes from other systems may be used • Design for Flexibility: Processes can easily be added to or removed from the pipeline • Design for Testability: Processes can be tested individually • Design Defensively: Processes can check their inputs 294

Model-View-Controller • Model performs application logic • View provides UI • Controller passes data where required 295

Model-View-Controller • Divide and Conquer: Three components can be designed independently • Increase Cohesion: Each component is responsible for one task • Reduce Coupling: Simple, well-defined communication channels • Increase Reuse: Components can be used, especially controllers and views • Design for Flexibility: Change UI by changing View, etc.

• Design for Testability: Views and Models can be tested independently 296

104

Service-Oriented Architecture • Collection of services • Communication by simple and universal interfaces • Server manages services and deals with clients 297

Service-Oriented Architecture • Divide and Conquer: Built from independently-designed web services • Increase Cohesion: Services provide functional cohesion • Reduce Coupling: Communication between components (rather than method calls) keeps coupling low • Increase Abstraction: Each service hides its details from others • Increase Reusability: A Web service is a highly reusable component • Increase Reuse: Services can easily be reused for different applcations • Anticipate Obsolescence: Web services can be re-implemented without affecting their clients • Design for Portability: Web services can be reimplemented quickly on different platforms, provided suitable languages are used • Design for Testability: Web services can be tested independently • Design Defensively: Web services must check input data very carefully 298

Message-Oriented Architecture • Clients communicate with a Message Centre • Message Centre: – sends messages to designated receiver(s) – ensures replies go to appropriate senders – buffers when busy • Also called Message Oriented Middleware (MOM) 299

105

Message-Oriented Architecture • Divide and Conquer: The application consists of isolated components that can be developed independently • Reduce Coupling: Components are coupled by data formats (data coupling), which is weak • Increase Abstraction: Messages form an abstraction: details of sending and receiving belong in the components • Increase Reusability: Simple message formats allow components to be reusable • Increase Reuse: Components can be reused in different systems that use similar message formats • Design for Flexibility: Components can easily be added or removed • Design for Testability: Components can be tested independently • Design Defensively: Components accept only messages that they understand 300

19 From Domain Model to Design From Domain Model to Design • We have discussed the Domain Model • We have discussed (parts of) the Design • How do we get from one to the other?

• One recommended method involves two steps: 1. Draw System Sequence Diagrams 2. Formulate Operation Contracts • The information we need is contained within the use cases 301

System Sequence Diagrams (SSD) • A SSD illustrates input and output events for the system • The software is treated as a “black box” • The use case is modelled as a sequence of – inputs to the system – responses from the system • Example from Wikipedia (next two slides) http://upload.wikimedia.org/wikipedia/commons/ 4/47/SsdExample.jpg 302

106

SSD: Example Extract from a use case: 1. For each item in sale: Clerk uses scanner to enter ID and amount 2. System generates invoice from scanned items 3. Clerk enters payment amount 4. System generates receipt Note that the SSD describes one scenario from a use case, not necessarily the complete use case.

303

SSD: Example

304

SSD: structure • Two dashed lines running vertically • Time goes down the page • Left heading “Actor” • Right heading “System” • Solid left→right arrows are inputs to the system • Dashed right→left arrows are responses from the system • Repeated actions (“loops”) are enclosed in boxes • Other examples: see previous SOEN 341 projects

107

• SSDs are not UML Sequence Diagrams (see later) 305

SSD: another example Use case (Larman, p177): 1. Customer arrives at POS checkout 2. Cashier starts a new sale 3. Cashier enters item identifier and quantity 4. System records item and displays description, price, and runing total Cashier repeats steps 3–4 until indicates done 5. System presents total with taxes calculated 6. Cashier tells Customer total and asks for payment 7. Customer pays and System handles payment 306

SSD: another example

Cashier makeNewSale quantity total endSale total with taxes makePayment(amount) receipt

307

Naming events • Name events according to the intention • Name should not imply an implementation

108

• E.g., enterItem, not scanItem • Events are usually verbs • Data is enclosed in parentheses, like a method call event(arg1, arg2, ...)

308

System Operations • A left→right arrow in a SSD names a system operation • The following right→left arrow may be considered part of the operation • E.g., makePayment and change, receipt form a system operation 309

Operation Contracts • For simple system operations, the use case and SSD are sufficient • Complex operations may be accompanied by an Operation Contract • Contracts are part of the use case model and may be included in the use cases • Operation contracts have four parts: 1. Operation 2. Cross References 3. Precondition 4. Postcondition 310

Operation Contracts • Operation: name of the operation and parameters, if any • Cross References: use case(s) associated with this operation • Precondition: statement(s) about the state of the system that are assumed to be true before the operation • Postcondition: statement(s) about the state of the system that are assumed to be true after the operation 311

109

Operation Contracts • Write preconditions in the present tense — they describe things that are true now • Write postconditions in the past tense — they describe things that have happened • Postconditions may mention objects that have been created or deleted by the system operation 312

Examples of Postconditions From Applying UML and Patterns: an Introduction to Object-Oriented Analysis and Design and Iterative Development by Craig Larman • A SalesLineItem was created • A SalesLineItem instance sli was created • sli.Quantity was updated • sli was associated with the current Sale 313

Summary: SSDs and Operations Contracts • Create SSDs for events that will become part of the design • Use SSDs to summarize and understand the system interface • Identify system operations from the SSDs • Unless a system operation is trivial, provide a contract for it • Write postconditions to record: – instance creation and deletion – attribute modification – associations formed and broken • Present tense for preconditions • Past tense for postconditions 314

110

Recapitulation • Domain Model describes the entire application and its environment at an abstract level • Requirements describe precisely what the system has to do • Use Cases provide scenarios of the system in action • System Sequence Diagrams summarize use cases as interactions with the (black box) system • Operation Contracts specify pre- and post-conditions for events All of these provide a foundation for design.

315

20 Design Documents Design Documents Each design document should include: • Purpose • Priorities • Outline • Issues • Details 316

Design: Purpose • Explains the role that this part of the design performs in the application as a whole • Refers to the requirements that this part of the design implements • Provides traceability 317 Traceability is important at all stages of development. For example, a maintenance programmer must be able to trace a piece of code back through testing, implementation, and design to find the original requirement that led to the code being there.

111

Design: Priorities • Describe the important goals of this design component • Explains how the design addresses: – functionality – quality – testability – maintainability – ....

318

Design: Outline • Brief, high-level description • A reader should be able to obtain a good general idea of what the design is about from the outline • The outline may include the class diagram(s) for this component 319

Design: Issues • Explains any important issues that had to be resolved during the design • Problems encountered and how they were solved • Inconsistencies or incompatibilities detected and what was done about them • Important relationships with other design components • All of these constitute a rationale for the design 320 The discussion of issues is important for maintenance programmers: it helps them to avoid repeating bad choices that were considered and rejected at an earlier stage.

Design: Details • Everything else • Describe classes, methods, attributes, protocols, constraints, etc.

321 We have seen the static model; we will discuss dynamic models later.

112

What to leave out A design document should not include: • Information that designers and programmers are expected to know E.g., don’t describe Linear Search Algorithm — just use it • Low-level details that programmers can decide and document for themselves E.g., why a hash-table is used rather than a balanced tree • Information that can easily be obtained automatically E.g., a list of classes and methods 322

21 Case study: Therac–25 We will consider several case studies during the course. Therac–25 is the first and earliest.

Each case study reviews the development of a software system that went wrong in some way. Failures of this kind illustrate the importance of using a reliable process for software development. Unfortunately, good case studies are hard to find: all too often, the key factors that led to failure never become known to the public.

Case study: Therac–25 • Consortium: – Atomic Energy Canada Limited (AECL) – CGR (France) • Products: – Neptune – Sagittaire – Therac–6: 6 MeV X-ray with Neptune and DEC PDP/11 – Therac–20: 20 MeV dual-mode X-ray with Sagitaire and DEC PDP/11 • Purpose: administer controlled doses of radiation to cancer patients 323

Background • Therac–6 and Therac–20 could be operated without the computer • “Industry standard hardware safety features and interlocks” used • Software control was added for convenience • If the software failed, operations would be restricted by hardware 324

113

Therac–25 • 1975: AECL developed the Therac-25 • Used “double pass” technology:, – the energy source is a magnetron rather than a klystron – acceleration path is folded so as to require less space • Therac-25 generates electron or X ray beams at up to 25 MeV • High doses permit treatment at greater depth in the body The machine is therefore potentially more dangerous 325

Design • Therac-25 was controlled by a PDP/11 • The software was an essential component of the system, not an optional add-on • Therac-25 relied on software correctness for safety • Therac-25 did not have electrical and mechanical interlocks like the Therac-6 and Therac-20 • Some of the software from the Therac-6 and Therac-20 was reused 326

History • 1976: first prototype • 1982: commercial version • 1983: safety analysis with assumptions: – Software errors had been extensively tested with a hardware simulator – Any residual errors were not included in the analysis “Residual” probably refers to possible interactions between the software and the hardware – Software does not degrade due to wear, fatigue, or reproduction – Computer execution errors are caused by faulty hardware and random errors introduced by alpha particles and electromagnetic noise 327

114

Safety Analysis • The fault tree obtained from the analysis includes “computer failure”.

• The probability that the computer would select the wrong energy level was estimated to be 10−11.

• The probability that the computer would select the wrong mode was estimated to be 10−9.

• The report provides no justification for these numbers and seems to imply that they arise from hardware failure, not software failure.

328

History • Five Therac-25s installed in USA and six in Canada.

• 1985–1987: six accidents involving radiation overdoses.

• Therac-25s were recalled in 1987.

329

Typical Incident Reports • Patient: “You burned me”.

• Diagnosis revealed one or two doses of radiation in the range 15K to 20K rads.

• Typical doses are around 200 rads; 1K rads can be fatal.

• This patient did not die but required extensive surgery.

330

Typical Accident Reports • The operator activated the Therac-25 but it shut down after 5 seconds with an “H-tilt” error message and displayed “no dose”.

• The operator pressed “P” (proceed — standard procedure) and the Therac-25 again shut down.

• This sequence was repeated four times.

• The patient complained of an “electric tingling shock”.

• She received between 13K and 17K rads and died four months later.

331

115

Diagnosis • AECL could not reproduce the failures but suspected a “transient failure in a microswitch” used to determine turntable position.

• The computer reads a 3-bit signal giving the status of three microswitches in the turntable that determines the orientation of the radiation gun.

• A 1-bit error could produce an ambiguity in the position.

• An additional problem was that a plunger, used to lock the turntable at one of three positions, could be extended when the turntable was far out of position; • this would also lead to a false position reading.

332

Solutions • AECL modified the software to: read the turntable position correctly in the presence of a 1-bit error; and to check for “in transit” status of switches to provide additional assurance that the switches were working and the turntable was moving correctly.

• AECL claimed that the accident rate of the new system was improved by “at least five orders of magnitude” (that is, accident rate should be less than previous accident rate by a factor of 105 or more — on the basis of the previous estimate, this gives an accident rate of 10−14).

• However, AECL said that it could not “be firm on the exact cause of the accident”.

333

Other studies • Gordon Symonds of the Canadian Radiation Protection Bureau (CRPB) wrote a report on the Therac-25 that mentioned the microswitch problem and design errors in both the hardware and the software.

• November 1985: CRPB requested AECL to make four modifications to the Therac-25 based on the CRPB report.

• The Ontario Cancer Foundation (OCF) said that the Therac-25 needed an independent system to verify turntable position and recommended a potentiometer.

334

Response • AECL made the microswitch changes as described above, but did not comply with the other requirements of the CRPB. • The CRPB asked that treatment be terminated after a dose-rate malfunction, but AECL simply reduced the number of retries allowed from five to three.

• AECL did not install the potentiometer recommended by OCF. 335

116

March 1986: Another incident The operator: • entered the required radiation prescription; • realized that she had pressed “x” instead of “e” • used ↑ to reposition the cursor on the “x” and changed it to “e” • typed RETURN several times to confirm the other entries • hit “b” (“Beam on”) to begin the treatment • The Therac-25 shut down with the message “Malfunction 54”, described as a “dose input 2” error • The Therac-25 indicated 6 units delivered from a dose of 202 units • The operator pressed “P” and the Therac-25 again shut down.

• Patient felt as though “he had hot coffee poured all over his head” and had had “an electric shock”.

• He had received between 16K and 25K rads.

• He died five months later.

336

April 1986: Another incident • A patient at the same clinic reported a feeling like being hit on the side of the face, a flash of light, and a sizzling sound.

• He died three weeks later.

337

Investigation • Physicist at Texas clinic discovered that rapid data entry to lead to massive overdoses • After practicing data entry, he could turn a 100 rad dose into a 4K rad overdose — these experiments were not tried on patients!

• AECL claimed at first they could not reproduce the error • after further trials, discovered that accidental doses of up to 25K rads could be delivered 338

117

June 1986: Response • Extended analyses followed.

• In June 1986, AECL produced a corrective action plan (CAP) proposing software modifications to prevent the specific sequence of events noted in Texas.

• Some electrical safety circuits were also added.

• AECL claimed that this CAP improved safety by “many orders of magnitude”.

339

January 1987: Another incident • In January 1987, there were problems with a Therac-25 at Yakima Valley Memorial Hospital.

• A patient given treatment died in April.

• AECL decided that this problem was not caused by “hardware alone” • problem could have been caused by software failure — a different failure from that in Texas 340

Further Analysis • One problem was caused by an 8-bit counter used to record the execution of SetUpTest.

• SetUpTest reschedules itself automatically and will be called hundreds of times during the set-up procedure.

• If the operator presses “set” after exactly 256 executions of SetUpTest, the counter is zero and the “upper collimator position check” is not performed.

• The Therac-25 takes time to respond to commands: for example, the bending magnets take up to 8 seconds to move ino position.

• The Therac-25 software was written as a collection of concurrent processes communicating by shared variables.

• The analysis determined that some of the problems were due to incorrect updating of shared variables, i.e., “race conditions”.

341

Conclusion • The software contained basic errors • A programmer who had taken an undergraduate course in concurrent systems could have recognized and avoided the errors • People died because of this casual approach to software development 342

118

22 Static and Dynamic Static and Dynamic • A static property of a program describes something that does not change with time • Static properties are also called compile-time properties • A dynamic property of a program describes something that happens when the program runs • Dynamic properties are also called run-time properties 343

Static Properties • The Domain Model provides a static view of the system • The Class Diagram provides a static view of the system • In Java, final qualifies an entity that cannot later be changed or overridden. So final classes, methods, and variables are static (in principle) • A variable is statically allocated if the compiler determines its address, either absolutely or relative to the stack frame 344

Dynamic Properties • Use Cases provide a dynamic view of the system • System Sequence Diagrams show what happens at run-time • Object, Activity, and State also show what happens at run-time • In OOPLs, methods are usually bound dynamically When the call o.m() is encountered during execution, the run-time system chooses which version of method m to execute, based on the class of o.

• A variable is dynamically allocated if its address is determined at run-time In Java, new indicates dynamic allocation. Executing new Widget() invokes the memory manager to find space in memory for the new instance of Widget.

345

119

23 Dynamic Modelling Dynamic Modelling • UML provides several kinds of diagram that express the dynamic behaviour of a system: – communication diagrams – sequence diagrams – state diagrams – activity diagrams • All of these complement the Class Diagram, which is static • Communication and Sequence Diagrams are known collectively as Interaction Diagrams 346

Dynamic Modelling What we will do: • briefly review the dynamic modelling notations • summarize their usage 347

Communication Diagram move()

:Referee • Two objects, Referee and Player • Colon and underline indicate objects, not classes • Line joining them indicates communication • Labelled arrow specifies the message (method call) • The message may have arguments 348

120

Communication Diagram

Object-Oriented Software Engineering, page 290 349

Communication Diagram

Object-Oriented Software Engineering, page 290 350

Communication Diagram Objects can communicate when: • The classes of the objects are linked by an association The association implies that one object “knows about” the other • The receiving object was created by the sender This is implied by «local» in previous slide • The sender was passed a reference to the receiver This is implied by «parameter» in the previous slide • The receiver is a global object This is indicated by «global» • The objects communicate over a network This is indicated by «network» 351 121

Sequence Diagrams Sequence Diagrams • are like System Sequence Diagrams, but more general • are used to show a sequence of calls and returns • may involve two or more objects 352

Sequence Diagrams :Referee

move()

moveDesc

• Two objects, Referee and Player • Each object has a vertical dashed life line • Thin vertical boxes denote method activations • Solid horizontal arrows show calls and returns • Time goes downwards 353

Sequence Diagram

Object-Oriented Software Engineering, page 287 354

122

Sequence Diagram • The create message has a dashed line and a open arrow head The object Registration is constructed by this call • Registration is positioned lower than the other objects because it is constructed after them • Some software tools do not permit lowering objects in this way • Time dimension (down) specifies sequence of events: 1. requestToRegister 2. create 3. addToSchedule 4. addToRegistrationList 355

Sequence Diagram

Object-Oriented Software Engineering, page 288 356

Sequence Diagram • Greater level of detail • User interacts with GUI, not CourseSection • Arguments and return values are specified • Events in the “opt” box may or may not occur • The condition [hasPrerequisite] specifies when the events in the “opt” box will occur • The dashed return from CourseSection indicates a possibly long delay 357

123

Equivalent Diagrams: communication and sequence

358

Sequence or Communication Diagram?

Use a Communication Diagram when: • inferring communication from a class diagram • validating class diagrams • a sequence diagram would be too detailed (abstraction) 359

Sequence or Communication Diagram?

Use a Sequence Diagram when: • the order of messages is important • building an interaction model from a use case • arguments and return values of messages are important • the sequence includes optional steps and loops 360

States and Transitions • Dynamic behaviour can be modelled with states and transitions • The system remains in a state for a while then makes a transition to another state • State Diagrams show states and transitions • State Diagrams are similar to Nondeterministic Finite Automata (NDFA) but have more features 361

124

State Diagram open

FileReady

read

EndOfFile

close

read • Solid circle denotes the unique start state • Ringed circle denotes an end state • Boxes contain named states • Arrows with optional labels indicate transitions • Multiple transitions with the same name indicate nondeterminism in the model • After read, the file may still be in state FileReady or it may be in state EndOfFile 362 State Diagram

Object-Oriented Software Engineering, page 293 363 State Diagram

125

Object-Oriented Software Engineering, page 295 364 State Diagram The previous slides illustrate: • Multiple end states • Nondeterminism • No end states, indicating that objects are to be retained • Conditional transitions: classSize ≥ minimum classSize ≥ maximum 365 State Diagram with nested substates

Object-Oriented Software Engineering, page 300 366

126

State Diagram with nested substates • An alternative version, using nested substates • cancel is a transition from any nested substate • The state following transition closeRegistration depends on the preceding state • If the nested substate exits, it may immediately be re-entered with a requestToRegister transition 367 State Diagram with nested substates

Object-Oriented Software Engineering, page 299 368 State Diagram with nested substates • Nested substates make State Diagrams significantly more powerful than NDFAs • An arrow to the edge of a nested substate is a transition to its start state E.g., selectDrive transitions to First • An arrow from the edge of a nested substate is a transition from any one of the nested states E.g., any gear can take the transition selectNeutral • An arrow that crosses the boundary of a nested state transitions to a particular state E.g., selectSecond goes to state Second • The transition reachSecondSpeed [driveSelected] means that the transmission will change up to second gear only if the nested substate was entered via selectDrive 369

127

Activity Diagrams Activity Diagrams: • model work flows • explicitly support concurrency (the other diagrams do not) • are used for both people and system activity • are similar to Petri nets • are best thought of in terms of tokens that move around the diagram 370

Activity Diagram nodes A

B

C

Fork: when a token arrives at A, two tokens concurrently leave along B and C

371

Activity Diagram nodes A

B

C Join: when a token has arrived at A and a token has arrived at B, a token leaves along C

372

Activity Diagram nodes A

B

C

D

Rendezvous: when a token has arrived at A and a token has arrived at B, two tokens concurrently leave along C and D 373

128

Activity Diagram nodes A

B

C

Decision: when a token arrives at A, a token leaves along B if P is true, or along C if P is false 374

Activity Diagram nodes A

B

C Merge: when a token arrives at either A or B, a single token leaves along C

375

Activity Diagrams

Object-Oriented Software Engineering, page 302 376

Activity Diagrams The previous slide illustrates: • start and end nodes, as in state diagrams • a fork, after Receive course registration request • a join, before Complete registration 129

• several decisions • a merge 377

Activity Diagrams

Object-Oriented Software Engineering, page 303 Swimlanes show how tasks are divided between objects 378

Dynamic Modelling: Summary • UML provides many different ways of modelling dynamic behaviour • Different diagrams suit different contexts • Too many diagrams lead to confusion • Choose diagrams that fit your application’s needs best 379

Dynamic Modelling: Problems

A0

A1

C0

A A3

C1

B0

C

B

C2

A2 B2

B1

130

• Processes A, B, C • Process A has states A0, A1, A2, A3, etc.

• Arrows show transitions • Dashed lines show communications 380

Dynamic Modelling: Problems • A state of the system is a tuple (a, b, c) with a ∈ { A0, A1, A2, A3 }, etc.

• The system has 4 × 3 × 3 = 36 states • A transition is a pair of states (s1, s2) • Theoretically, the system has 362 = 1296 transition 381

Dynamic Modelling: Problems Now consider a moderately complex system: • P processes • Each process has S states • System has P S states • There are P S

2

possible transitions

• E.g., 100 processes, 10 states per process, gives 10010

2

= 1040 transitions

• Some current systems are much larger than this • This is the state explosion problem • How do we reason about systems with this many states?

382

Dynamic Modelling: Solutions Two main approaches: 1. Theorem proving: • Construct a formal theory, e.g., process algebra • Express properties of programs in the theory, e.g. no deadlock • A property of a particular program is a theorem to be proved

131

• Proofs are constructed semi-automatically by a theorem prover • Number of states is unlimited, but proofs may be long 2. Model checking: • Construct a modelling language for concurrent processes • Abstract the program to the model language • Explore all possible states of the program • Exploration is performed by a model checker • Number of states is limited, but 10100 or more can be handled Both techniques are difficult — active research area!

383

Dynamic Modelling in UML Conclusion: • Sequence diagrams, activity diagrams, etc., are not capable of handling realistic problems of concurrent programming

I’ve been working with advanced, high-performance, scalable real-time solutions for more than 25 years, and this [UML] book really is a denial of my whole professional career and my experiences.

P. Erichles, Technical Coordinator, Space Shuttle, NASA 384

24 User-Centered Design User Interface Design Things that prevent good software from being used: • Bad (or non-existent) documentation • Bad user interface Solution: Things that prevent good software from being used: • Good documentation • Good user interface 385

132

User-Centered Design Old approach: • Developers design and implement the software, including the UI • Customer is informed: “Here it is — use it” New approach: • Developers work with the customers: – study current ways of working – ask users what they want – develop the UI collaboratively • When complete, the UI can be evaluated • Improvements can be made if necessary 386

User-Centered Design: Approaches • Understand the users Users know more about the application domain and their ways of working in it than developers do; respect this knowledge.

• Design reflects user activities Design decisions should be made from the point of view of users, not from the point of view of the implementation.

• Keep users involved Don’t interview uses and then forget about them: make sure they are in the loop at all stages.

• Use established principles for UI design Everyone thinks they know how to design a UI. The result is lots of bad UIs. • Get feedback from users Write draft user manuals, code prototypes, do anything that will allow users to get a sense of the system and respond to it.

387

User-Centered Design: Advantages • Reduce overall costs Extra time spent on good UI design will be compensated by reduced training and support time.

• Reduce learning time Users will acquire the skills they need quickly and will like the system.

133

• Increase efficiency Users who understand the UI well will use the system efficiently.

• Avoid redundancy Implementing only the features that users actually need will keep the UI simple and will reduce costs.

• Avoid change If you deliver a bad UI, you will end up changing it later: this takes money and time.

• Prioritize Knowing what users want most helps developers to schedule their work 388

Getting to know the users • Find out what users expect to achieve by using the system • Determine patterns of use. E.g.: – 4–5 p.m. every day – Friday afternoons — summarize week’s activity – Intermittently – Switching between this application and others • Demographics: age, education, language skills, technical knowledge, etc.

• Specific knowledge: application domain, computer systems • Physical abilities: will the system be used by people with vision, hearing, or physical impairments?

389

Usability Usability: • enables users to operate the software effectively • is not about what the software can do • is about what the users can do (or learn) quickly and easily

• If the system is not usable, people will not use it • If people do not use the system, developing it was pointless 390

134

Aspects of usability • learnability • efficiency • error handling • acceptability 391

Learnability • Learnability measures how easily and quickly users acquire fluency and competence in working with the system • Fluency: working rapidly and continuously, without pauses • Competence: correct usage without errors • Easy: quick to learn but may frustrate expert users • Hard: slow to learn but efficient • Best: combine easy and hard E.g., menus and hot keys 392 Rant: “steep learning curve” steep learning curve = fast learning Skill

shallow learning curve = slow learning

Time 393

Efficiency • UI is efficient if it allows normal tasks to be completed: – rapidly – with minimal actions (mouse motions, clicks, keystrokes) • Measure as:

135

– time per task – tasks per hour – daily throughput 394

Error handling • Prevention: do not allow the user to make errors E.g., do not allow file to be opened if it is already open • Detection: recognize and report errors to user E.g., do not allow telephone number to be saved if format is wrong • Correction: recognize errors and correct them E.g., autocorrection in MS Word • Allow users to adjust the level of error handling E.g., some people like autocorrection, others hate it • Murphy’s Law: if it is possible for an error to be made, someone will make it 395

Acceptability Acceptability: • measures whether users like the system • is subjective — the same UII may be both liked and disliked • is crucial — no acceptance =⇒ no users 396

UI Jargon • dialog, control, widget, . . . .

• The state of a UI determines what the user can see and do • The affordance of a control is the set of operations that the control enables a user to perform • A mode if a UI is a state in which affordance is limited E.g., model dialog • Feedback from a UI is what the user sees or hears as a response to actions 397

136

Affordance gone wrong

398

Affordances in UI design • Appearance of a control should suggest its use – Links should have a distinctive colour (e.g., blue) – Buttons should look as if they can be “pressed” – Scroll bars should suggest possibility of horizontal or vertical motion – Tabs should change when pressed – Radio buttons are mutually exclusive; check boxes are independent • Respect conventions!

399

Coca-Cola survey

137

400

Death by 1000 tabs

401

Hints for UI Design 1. Test the UI with real users • Designers are often shocked when they see ordinary users struggling with their carefully crafted UIs • Avoid the shocks by testing early and often • If users frequently make mistakes, it’s the designer’s problem, not the users’ 402

138

Hints for UI Design 2. Base UI design on application tasks • Use cases often form a good basis for UI design 403

Hints for UI Design 3. Action sequences for common tasks should be short and simple • Long sequences are susceptible to errors • Users perform steps automatically and do not notice unusual events 404

Moodle: Adding a “resource” 1. Press Turn editing on 2. Open menu Add a resource 3. Select Link to a file or web site 4. Enter a name for the resource 5. Click Choose or upload a file 6. Click Upload a file 7. Click Choose file 8. Select file using Explorer 9. Click Upload this file 10. Find the uploaded file on the Files page 11. Click Choose 12. Scroll to bottom of Add a resource screen 13. Click Save and return to course 405

139

Moodle: Adding a “resource” • The options at the last step are: – Save and return to course – Save and display – Cancel • There is no option for Add another resource — which is usually what you want to do • The button Save and return to course is not visible after you have clicked Choose • Failing to click Save and return to course ensures that the entire sequence has no useful effect 406

Hints for UI Design 4. Users must always understand where they are • At any stage, the user must know: – what has just happened – what will happen next, for each affordable control – how to go back to a previous step – how to recover from a mistake • Users should never be afraid to “try it and see” 407

Hints for UI Design 5. Help users with feedback • A button should change in some way when it is clicked • Long actions should display a “something is happening” indication • Important events justify pop-up message boxes • Errors should be reported and the user given a way to escape 408

Hints for UI Design 6. For every “do”, there should be an “undo” • Provide undo mechanisms wherever possible • Back buttons should not leave changed state • Issue warnings for actions if there is no “back” or “undo” E.g., Do you really want to reformat C:?

409

140

Hints for UI Design 7. Keep response times low • Most actions should have an almost immediate response • Long actions should display a “something is happening” indication 410

Hints for UI Design 8. Choose labels carefully • Labels should reflect the user’s point of view, not the system’s • Provide help buttons if labels are inadequate 411

Hints for UI Design 9. Aim for a neat and simple appearance • Cluttered displays are confusing and tiring to use • Too many clickable areas lead to accidental clicks • Learn how to use colours 412

Hints for UI Design 10. Consider different groups of users • Provide different options beginners and experts • Allow selection of large fonts • Provide different possibilities for sound cues, including none • Allow for different locales use OS whenever possible • Use skins if feasible • Be generous with help facilities 413

141

Hints for UI Design Last but not least . . .

11. be consistent!

• On large project, ensure that all screens have similar looks, controls, and effects • Design themes for colours, fonts, etc., and use them throughout the system • If the user is allowed to change aspects of the UI, apply the changes uniformly across the system 414

Models • An implementation model is an abstraction of the system’s operation • A mental model is the user’s abstraction of how the system works • E.g., spreadsheet – Implementation model: linked nodes with data or formulas at each node – Mental model: grid of boxes containing text or numbers • E.g., Windows move/copy files – Implementation model: same disk is a move; different disk requires copying – Mental model: dragging = moving • “Find all Concordia students living in Quebec and Ontario” – Implementation model: intersection gives empty set – Mental model: union (Quebec or Ontario) • Photographers work with images, not with numbers and sliders 415

Photoshop: colour balance controls

416

142

Photoshop: variations

417

Don’t replicate paper artifacts

418

Don’t replicate paper artifacts

143

419

Don’t replicate paper artifacts

420

Software Postures • Term is from About Face 2..02: the Essentials of Interaction Design by Alan Cooper and Robert and Robert Reimann, Wiley, 2003.

• Posture determines – How often the software is used 144

– How long is a typical session – How familiar users are likely to be with the application • Three main postures: 1. Sovereign 2. Transient 3. Auxiliary 421

Sovereign Posture • Used for long periods of time • Often used in full-screen mode (especially with old, tiny screens) • E.g., word processors, spreadsheets, compilers, etc.

• Users are typically not beginners, but may not be experts either • Designing for sovereign posture: – assume a large window – complex design acceptable – keep colours muted but distinctive – provide choices for input: mouse, hot keys, dialog boxes, etc.

– maximize document views 422

Transient Posture • Used for short periods of time • Allows user to make quick adjustments • E.g., clock/calendar, sound control, external device, etc.

• Designing for transient posture: – assume window may be small – big buttons, easy-to-read labels, clear controls – bright colours – simple and consistent controls, e.g., just buttons – remember state, e.g., open in same place each time 423

145

Auxiliary Posture • Combines features of sovereign and transient • Often present, but plays a supportive role • E.g., taskbar, performance monitor, clock, stock ticker, etc.

• Should not be the main focus of the user’s attention 424

Other Postures • Web – display useful information versus ease of navigation – frequent updates imply greater user familiarity: e.g., weather forecast versus store information – Large amount of information requires effective navigation • Kiosk – ATM, airline check-in, etc.

– people use them infrequently – clear, unambiguous instructions – clear, unambiguous view of where you are • Handheld devices – limited power, size, resolution, input mechanisms – used more for display than for input – make effective use of limited resources 425

Evaluating user interfaces Heuristic Evaluation: • At each step (window, dialog, combo, etc.) look for potential problems • Record defects, with a short description and screen shot • Propose and try improved versions that avoid defects • Let several people evaluate and compare responses 426

146

Evaluating user interfaces Evaluation by observing users: • Select users corresponding to actors in the use cases • Select use cases • Write simple task descriptions • Organize 20–30 minute sessions • During a session: – Explain tasks to be performed – Record the session on video and/or with event capturing software – Encourage users to think out loud – When tasks are finished, ask users about their experiences – Analyze difficulties encountered • Obtain quantitative data by timing tasks, etc.

This enables assessment of improvements 427

25 Design Patterns Design Patterns A design pattern: • describes a design-level concept • can be used in many different applications • has a good track-record of being useful and effective • has a name • has examples of use • may be described using UML diagrams and other techniques As collection of patterns constitutes a design language that designers can use when discussing designs 428

History of Patterns • A Pattern Language: Towns, Buildings, Construction by Christopher Alexander, 1977 • Beck and Cunningham, OOPSLA, 1987 • Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, 1994. Also called “The Gang of Four Book” or “The GoF Book”.

147

• Pattern Languages of Programming Conference, 1995 • Many new patterns — too many • patterns should represent well-understood and widely-used ideas 429

Pattern Description • Context: when do you use this pattern?

• Problem: what problem(s) does this pattern solve?

• Forces: what do you have to think about when using this pattern?

• Solutions: how do you apply this pattern to this problem?

• Antipattern: are there other patterns that look appropriate but do not work for some reason?

• Related: are there patterns that are similar to this one and might be used instead?

• References: who inspired, developed, or modified this pattern?

430

Patterns solve complex problems • It is hard to understand a pattern if you have not encountered the problem that it solves • Some of the GoF patterns are quite complex 431

148

26 GRASP GRASP • GRASP stands for General Responsibility Assignment Software Patterns • Some people feel that GRASP defines principles, not patterns • GRASP has nine “patterns”: Creator

Controller

Pure Fabrication

Information Expert

High Cohesion

Indirection

Low Coupling

Polymorphism

Protected Variations

• We have seen some of these before!

432

GRASP: Creator • Who is responsible for creating new instances of a class?

• Class B should be responsible for creating instances of class A if: – B contains an A or a collection of As – B records A – B closely uses A – B has the information necessary to create instances of A • Creator tries to find an object that will be as closely related to the new object as possible 433

GRASP: Information Expert • Is there a general principle for assigning responsibilities to objects?

• Assign a responsibility to the information expert, defined as the class that has the greatest amount of the information needed to fulfill the responsibility • The answer may not always be as obvious as it looks – Should an object be responsible for writing itself to the database?

– Should this responsibility belong to a special class that knows about databases?

434

149

GRASP: Low Coupling • How do we support low dependency, low change impact, and increased reuse?

• Reduce coupling to achieve all of these beneficial effects • A strongly-coupled class: – causes changes to cascade – is hard to understand in isolation – is hard to reuse because of dependencies • Assign responsibilities in a way that minimizes coupling 435

GRASP: Controller • What is the first object outside the UI layer that receives and coordinates operation of the system?

• It may be useful to have a Controller object that handles all events from the UI and passes them onto appropriate subsystems • Increases potential for reuse • Permits pluggable interfaces • Problem: too many events may lead to a bloated controller • Solution: controller should delegate 436

GRASP: High Cohesion • How do we ensure that objects are focused, understandable, manageable, and have low coupling?

• Assign responsibilities to maximize cohesion 437

GRASP: Polymorphism • How do we handle alternatives based on the types of objects?

• How do we create pluggable interfaces?

• Use polymorphism to assign responsibilities according to varying behaviour • In other words, use inheritance • Do not use type-dependent logic within a single class • Benefit: easy to extend for new behaviour 438

150

GRASP: Pure Fabrication • How do you assign responsibility when other principles do not work?

• Introduce a new class specifically to handle this responsibility • Example: a Persistent Storage class solves the earlier problem (who saves an object in the database?)

• Can increase cohesion • If misused, can cause fragmentation of the system into unrelated functions 439

GRASP: Indirection • How do you assign a responsibility without creating direct coupling between objects?

• Assign the responsibility to a third object that mediates between the other two • The intermediate object creates an indirection between the original two objects • Persistent Storage (shown earlier) is intermediate between and object and the database • Reduces coupling 440

GRASP: Protected Variations • How do we design objects and subsystems so that variations do not impact other parts of the system?

• Identify points of variation or instability and assign responsibilities to create a stable interface around them • Protected Variations is a variant of Information Hiding 441

27 Midterm 1 Midterm 1 • Date: Friday, 18 February 2011 • Time: 08:50 – 10:00 • Materials: pen, or pencil and eraser No books, notes, calculators, . . .

• Topics: what we have done so far

151

– what is Software Engineering?

– software process models, lifecycles – phases of software development – heavyweight and agile processes – requirements: domain analysis; domain model; use cases – architectures: MVC, WEA, . . .

– design: strategies, rationale – design principles – UML: class, [system] sequence, state, activity diagrams – user interface design – GRASP 442

28 GoF Patterns GoF Design Patterns • Selected patterns from Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides • “The GoF Book” • 23 patterns altogether • Each pattern addresses a common problem in OO design • Each pattern describes an accepted and widely-used solution 443

Adapter • Intent: convert the interface of a class into another interface that clients expect • Other names: Wrapper • Example: we have a hierarchy rooted at Shape in which every class has BBox() (return bounding box) • There is a TextView class that we want to include but it doesn’t have BBox() 444

152

Adapter Shape BBox()

Circle BBox()

Square BBox()

TextView getExtent() 445

Adapter • Solution: introduce a new class that adapts TextView to the hierarchy • How to do it: Class Adapter: inherit Shape’s interface and TextView’s implementation Object Adapter: compose a TextView instance within a TextShape 446

Object Adapter Shape BBox()

Circle BBox()

Square BBox()

TextShape BBox() text: TextView

TextView getExtent() 447

153

Adapter Consequences: • Work done by adapter can vary from a simple name change to a complex sequence of actions • Pluggable adapters: a subsystem provides a “socket” and adapters are used to convert other objects into “plugs” so that they can use the subsystem • Two-way adapters can enable incompatible systems to work together 448

Decorator • Intent: attach responsibilities to an object dynamically • Other names: Wrapper (also used for Adapter!)

• Problem: various responsibilities should be added, but there is no hierarchical pattern • Example: plain window; add title, scrollbars, border, toolbar, . . .

• Solution: introduce an object that implements the responsibility and delegates the basic task 449

Decorator: class view View draw()

TextView draw()

LineView draw()

Gadget draw()

Border draw() drawBorder() cpt: View

ScrollBar draw() scrollTo() cpt: View 450

154

Decorator • At run-time, link the Gadget we need to the View that we want to see

:border cpt: View

:scrollBar cpt: View

:textView cpt: View 451

Decorator: abstract pattern • Hierarchy of Components • Subclasses of Component for various applications • Decorator is also a subclass of Component • a Component can have a collection of Decorators • for a given instance, the Decorators are called in succession 452

Decorator Component op()

Cpt1 op()

Decorator op()

Cpt2 op()

Dec1 op()

Dec2 op() 453

Decorator Consequences: • Decorators provide a form of inheritance, but without the static restrictions of inheritance • Decorators avoid features accumulating at the top of the hierarchy

155

• A decorator and its component are different objects: reference comparison will fail • Decorators may lead to lots of little objects 454

Chain of Responsibility • Intent: avoid directly coupling a request to its receiver • Problem: it may be impossible to decide which object can best handle a request at compile-time • Solution: build chains at run-time; a requests is passed along the chain until an object that can handle it is found • An object either handles the request or delegates it to the next object in the chain • The last object in the chain either handles the request or resports failure 455

Chain of Responsibility • Example: a help system • Clicking the “help” icon on a control provides information about that control • The control may not know what its role is within the application • Chain of Responsibility allows a control either to provide help directly or to pass the request down the chain 456

Chain of Responsibility

:printButton handler :okButton handler

:saveDialog handler :printDialog handler

:application handler

457

156

Chain of Responsibility Consequences: • Reduced coupling: objects do not have to know which object fulfills a request • Adds flexibility: allows distribution of responsibility amongst objects • Risk: receipt is not guaranteed: a request may not be handled if it “falls off” the end of the chain 458

Composite • Intent: – compose objects into tree structures to represent part-whole hierarchies – treat individuals an compositions uniformly • Example: – a picture is a collection of primitive graphics objects – it should be possible to use a picture in a larger picture – users should not have to distinguish primitives and pictures • Solution: – one subclass of Graphic is a class Picture – a Picture contains a collection of Graphic objects 459

Composite Graphic draw()

Line draw()

Text draw()

Rectangle draw()

Picture draw() 460

157

Composite Consequences: • Explicit parent references: maintaining parent references (i.e., references “up” the tree as well as “down”) simplifies tree management • Sharing: Graphic objects can be used many times in a tree by sharing one object • Maximize component interface: make the interfaces of primitive objects and Pictures as similar as possible 461

Composite Another example: • A text processor places Symbols on a page • Letters, blanks, etc., are primitive graphical objects • A Row is a collection of graphical objects arranged horizontally • E.g.: Word, Line • A Column is a collection of graphical objects arranged vertically • E.g., Paragraph 462

Composite: example Graphic

Row

Symbol

Word

Column

Line

Paragraph 463

158

Bridge • Intent: decouple an abstraction from its implementation so that the two can vary independently • An abstraction is a system component with N variations, typically implemented as an inheritance hierarchy • An implementation implements the components, perhaps in M different ways • Problem: avoid creating M × N implementation classes • Solution: separate the abstraction hierarchy and the implementation hierarchy 464

Bridge Example: • Suppose we have a Shape hierarchy: a number of different shapes that can be drawn • We want to implement the Shapes on various kinds of hardware: monitors, plotters, printers, . . .

• draw() in Shape is implemented as void draw() { imp.drawImp(); } so that the appropriate implementation handles the drawing operation.

465

Bridge Shape draw() imp: ShapeImp

ShapeImp drawImp()

Monitor drawImp()

Plotter drawImp()

Printer drawImp() 466

159

Bridge Consequence: • Decouple interface and implementation. Implementation of an abstraction can be chosen (and changed) at run-time • Eliminates compile-time dependencies • Improved extensibility: the abstraction and implementation hierarchies can be extended independently • Hiding implementation: clients cannot access implementation details, which makes them easier to change 467

160

Topics to be covered • Implementation • Quality Control • Maintenance • Management • Reuse 468

29 Implementation Implementation • Implementation is writing code that matches the design • Big decisions should have been made by designers • Implementors make only small decisions 469 Implementation is the process of building a software product from the design documents. Much of implementation is programming, or coding, but there are other things to do. Implementation is not a particularly creative process; if the design work has been done well, coding is almost mechanical, although it is best done by skilled programmers.

Implementation in RUP • Make a plan for developing components and integrating them into the system • Implement the components • Fix obvious defects of components • Test individual components • Inspect and review 470 Five principal activities that are performed during implementation: Plan Integration. Make a plan for developing the various components of the system and integrating them into progressively larger subsets of the product. For a very small system, this step can be omitted.

The goal of planning is to avoid major jumps where things can go wrong. Instead of developing 50 modules and then putting them altogether at once, figure out how subunits of 5 modules can be assembled, then 10 or 15 modules, and, when that is achieved, go for 50 modules.

Implement Components. This is what most people mean by “implementation”. Programmers, working from the detailed design document of each module, write code for the modules.

161

Fix Defects. The code will contain errors, some of which are immediately obvious. For example, a module might compile with errors. These defects are fixed quickly. Unit testing (the next item) will also reveal defects that must be corrected.

Test Units. The completed modules are tested individually (that is, without linking them into a larger part of the system). It will usually be necessary to write special code to call the functions of the module. There are various names for this code: driver, scaffolding, test harness, etc.

Review Code. The code is reviewed carefully. Reviewing is an important part of the process because it may reveal deep, or latent, errors that do not appear in tests. Some studies suggest that reviewing code is a more effective way of removing defects than testing. (The comparison is made with respect to a metric such as defects detected per person-hour.)

Techniques for inspecting and reviewing code will be discussed in detail later in the course.

29.0.1

Traceability

Developers must be able to follow a feature of the system through the requirements, design, and implementation stages. For example, given a function in a class, we should be able to quickly find that function in the design and to identify the requirement that it is supposed to meet. When this is possible, the system is traceable. Traceability can be provided by cross-referencing, documentation tools, and other means.

Some development systems provide round-trip engineering. Ideally, it should be possible to work in two directions: • make a change to the design and use the development tool to generate new code; • make a change to the code and use the development tool to modify the design documents.

Current tools (e.g., those from Rational) permit limited forms of round-trip engineering. For example, class declarations can be changed in both directions. Round-trip engineering of algorithmic code is beyond the state-of-the-art and will probably remain so for some time.

Information needed for implementation • Design documents • Algorithmic information Design may not specify domain-specific algorithms in detail E.g., details of interpreting flight-control data • Rationale Implementors need to know not only what to do but also why to do it in a particular way E.g., why use RPC rather than MOM 471 Implementors need three kinds of information: • The design documents are obviously necessary and are the primary source of information.

• Algorithmic information from the application domain may be required. Programmers are expected to know how to implement hash tables, balanced trees, and so on, but they may not know how to compute insurance premiums or highway curves.

162

• Rationale information explains why a particular strategy was adopted in favour of other strategies that might look equally good. Developers should both make use of rationale information and include it in comments, so that maintenance programmers don’t make mistakes that the designers avoided.

For example, the design might specify synchronous communication between processors using RPC (remote procedure call). The rationale for this decision is that messages are blocked when the network is busy and the network is therefore less likely to become overloaded. If the rationale is omitted, a smart programmer might decide to use MOM (message-oriented middleware) for communication because it is easier to implement and seems to be more efficient because it is asynchronous and non-blocking. The problem with MOM is that, when activity is high, the network may become saturated with waiting messages.1

Coding Conventions Badly written code: void calc (double m[],char *g){ double tm=0.0; for (int t=0;t<MAX_TASKS;++t) tm+=m[t]; int i=int(floor(12.0*(tm-MIN)/(MAX-MIN))); strcpy(g,let[i]);} 472

Coding Conventions Improved version: void calculateGrade (double marks[], char *grade) { double totalMark = 0.0; for (int task = 0; task < MAX_TASKS; ++task) totalMark += marks[task]; int gradeIndex = int(floor(12.0 * (totalMark - minMarks) / (maxMarks - minMarks))); strcpy(grade, letterGrades[gradeIndex]); } 473 These two function definitions are identical as far as the compiler is concerned. For a human reader, however, the difference is like night and day. Although a programmer can understand what calc() is doing in a technical sense, the function has very little “meaning” to a person.

The second version of the function differs in only two ways from the first: it makes use of “white space” (tabs, line breaks, and blanks) to format the code, and it uses descriptive identifiers. With these changes, however, we can quite easily guess what the program is doing, and might even find mistakes in it without any further documentation.

In practice, we would include comments even in a function as simple as this. But note how the choice of identifiers reduces the need for comments.

1See

http://www.sei.cmu.edu/str/descriptions/rpc_body.html for details.

163

Basic Rules of Coding • Use a clear and consistent layout • Choose descriptive and mnemonic names for constants, types, variables, and functions • Use comments when the meaning of the code by itself is not completely obvious and unambiguous 474 These are generalities; in the following sections we look at specific issues.

Layout • Indent code according to nesting level • Incorrect indentation makes code harder to read • Use three or four spaces for indentation • ++p is not in the loop body: while (*p) p->processChar(); ++p; 475 The most important rule for layout is that code must be indented according to its nesting level. The body of a function must be indented with respect to its header; the body of a for, while, or switch statement must be indented with respect to its first line; and similarly for if statements and other nested structures.

You can choose the amount of indentation but you should be consistent. A default tab character (eight spaces) is too much: three or four spaces is sufficient. Most editors and programming environments allow you to set the width of a tab character appropriately.

Brace conventions • There are several popular ways of placing braces ({ and }) • Pick one and use it consistently • If your organization defines a convention, use it 476

164

Brace conventions Readable, wastes space: void fibonacci (int n) { if (n <= 1) return 1; else { int a = fibonacci(n - 1); int b = fibonacci(n - 2); return a + b; } } 477

Brace conventions Harder to match braces, saves a few lines: void fibonacci (int n) { if (n <= 1) return 1; else { int a = fibonacci(n - 1); int b = fibonacci(n - 2); return a + b; } } 478 In addition to indentation, you should use blank lines to separate parts of the code. Here are some places where a blank line is often a good idea but is not essential:

Layout Consider using blank lines between: • method declarations in a class declaration; • variable declarations in a class declaration; • major sections of a complicated function.

479

Naming conventions Various kinds of name occur within a program: • constants

165

• types and classes • local variables • attributes • methods 480 It is easier to understand a program if you can guess the kind of a name without having to look for its declaration which may be far away or even in a different file. There are various conventions for names.

Naming conventions You can use: • the convention described next • your own convention • your employer’s convention 481

A naming convention • Constants: upper case with underline separators MAXIMUM_TEMPERATURE • Types and classes: initial capital, camel case AdjacencyMatrix • Local variables: initial small, camel case short, longName, evenLongerName • Attributes: consistent prefix d_name, d_address • Methods: initial small, camel case doIt 482

A naming convention • Camel case: lower case, start words with an upper case letter thisIsAnExampleOfCamelCase • Alternative: underscore this_uses_underscores • Underscores: – take up more space – are easier to miss 483

166

Brown University Conventions As an example of a (rather old) coding standard, we shown the standard required at Brown University for UNIX/C code.

Brown University has a set of coding standards used for introductory software engineering courses.

Most of the conventions are reasonable, but you can invent your own variations. Here are some of the key points of the “Brown Standard”, with my (P.G.) comments in [square brackets]: • File names use lower case characters only.

UNIX systems distinguish cases in file names: mailbox.h and MailBox.h are different files. One way to avoid mistakes is to lower case letters only in file names.

Windows does not distinguish letter case in file names. This can cause problems when you move source code from one system to another. If you use lower case letters consistently, you should not have too many problems moving code between systems. Note, however, that some Windows programs generate default extensions that have upper case letters!

• Types and classes start with the project name.

An abbreviated project name is allowed. For example, if you are working on a project called MagicMysteryTour, you could abbreviate it to MMT and use this string as a prefix to all type and class names: MMTInteger, MMTUserInterface, and so on.

[I don’t think this is necessary for projects. The components of a project are usually contained within a single directory, or tree of directories, and this is sufficient indication of ownership.

The situation is different for a library, because it must be possible to import library components without name collisions.]

• Methods start with a lower case letter and use upper case letters to separate words. Examples: getScore, isLunchTime.

[I use this notation for both methods and attributes (see below). In the code, you can usually distinguish methods and attributes because method names are followed by parentheses.]

• Attributes start with a lower case letter and use underscores to separate words. Examples: start_time, current_task.

• Class constants use upper case letters with underscores between words. Examples: MAXIMUM_TEMPERATURE, MAIN_WINDOW_WIDTH. • Global names are prefixed with the project name. Example: MMTstandardDeviation.

[I use the same convention for methods and global functions. When a method is used in its own class, this can lead to ambiguity. In many cases, however, you can recognize methods because they appear as o.method() or p->method(). My rule for global variables is avoid them.]

• Local variables are written entirely in lower case without underscore. Examples: index, nextitem.

Comments Comments: • are an essential component of good code • are usually written badly or omitted altogether • are difficult to write well Golden rule Comments should not provide information that can be easily inferred from the code.

484

167

Using the golden rule Eliminate comments: counter++;

// Increment counter.

// Loop through all values of index. for (index = 0; index < MAXINDEX; index++) { ............ } 485

Using the golden rule Change int np; int flag; int state; double xcm; double ycm;

// Number of pixels counted. // 1 if there is more input, otherwise 0. // 0 = closed, 1 = ajar, 2 = open. // X-coordinate of centre of mass. // Y-coordinate of centre of mass.

to int pixelCount; bool moreInput; enum { CLOSED, AJAR, OPEN } doorStatus; Point massCentre; 486

Good places to write comments • at the beginning of a file • at the beginning of a class • at the beginning of a method • accompanying a constant or variable declaration unless its role is obvious 487 In many cases, it is best to put a comment explaining what the function does in the header file or class declaration and a different comment explaining how the function works with the implementation. This is because the header file will often be read by a client but the implementation file should be read only by the owner. For example:

Users and maintainers A method should have a public descriptor and a private descriptor:

168

class MathLibrary { public: // Return square root of x. double sqrt (double x); .... }; MathLibrary::sqrt (double x) { // Use Newton-Raphson method to compute // square root of x. .... } 488

Block comments Example: /***************************************/ /* */ /* The Orbiting Menagerie */ /* Author: Peter Grogono */ /* Date: 24 May 2010 */ /* (c) Peter Grogono */ /* */ /***************************************/ 489

Block comments Problems with block comments: • they take time to write • they take time to maintain • they become ugly if they are not maintained properly (alignment is lost, etc.)

• they take up a lot of space 490 Nevertheless, if you like block comments and have the patience to write them, they effectively highlight important divisions in the code.

Inline comments • comments interleaved with code in the body of a method or function • use when the logic of the function is not obvious

169

• inline comments must respect the alignment of the code.

• align to the current left margin • Inline comments must always confirm or strengthen the logical structure of the code — never weaken it 491

Inline comments void collide (Ball *a, Ball *b, double time) { // Process a collision between two balls. // Local time increment suitable for ball impacts. double DT = PI / (STEPS * OM_BALL); // Move balls to their positions at time of impact. a->pos += a->vel * a->impactTime; b->pos += b->vel * a->impactTime; // Loop while balls are in contact. int steps = 0; while (true) { // Compute separation between balls and force separating them.

492

Documentation Tools • If documentation tools are available, use them • Examples: JavaDoc, Doxygen 493

Comments — Summary Comment are not useful if: • there are not enough • there are too many • they do not contribute to understanding the code • they appear in unexpected places • they clutter the code 494

170

Comments — Summary Comment are essential, provided that: • they explain things that are not obvious from the code • the do not impede reading the code • conform to the requirements of a documentation tool 495

30 Quality Control Quality Control The goal is to avoid software failure. Reasons for failure include: • Missing requirement • Unimplementable requirement • Specification derived incorrectly from requirements • Error in high-level design • Error in detailed design • Error in code 496 • A requirement was omitted.

Example: the client loses a master file and complains that the program should have maintained backups of important files automatically. This is a serious “failure” from the client’s point of view but we cannot blame the software product for the failure because there was no requirement for automatic backups.

• The requirements were unimplementable.

Example: the client complains that the system is so busy with housekeeping that it never gets any work done. Investigation shows that both hardware and software are performing correctly, but the hardware configuration is inadequate for the client’s needs.

• The specification was incorrect.

Example: a student logs in to the University’s Student Information System and requests her grade for a non-existent course; the system crashes because the specification stated that a course number consisted of four letters and three digits and defined no further validation.

• There was an error in the high-level design.

Example: The component for remote access must be linked to the client database in order to validate customers who access the system by telephone. Since the link was omitted in the highlevel design, the people working on the detailed design did not notice the need for validation.

• There was an error in the detailed design.

Example: the specification required unique keys for a database but the design did not enforce uniqueness. The program was implemented according to the design but does not meet its specification.

171

• There was an error in the code.

Example: the design states that no action is to be performed if a certain pointer is NULL. The programmer omitted the test for NULL and the program crashed when it attempted to dereference the pointer.

Terminology • A fault causes a failure • The process of discovering what caused a failure is called fault identification.

• The process of ensuring that the failure does not happen again is called fault correction or fault removal.

• “Bug” is colloquial, not standard, terminology 497 “Bug” is a popular term for “fault”. There is a story to the effect that the first hardware failure was caused by a bug that was trapped between relay contacts in an early computer. This story is almost certainly mythical, because engineers were using the word “bug” before any computers had been built.

But the usage is important: the word “bug” suggests that faults wander into the code from some external source and that they are therefore random occurrences beyond the programmer’s control.

This is not possible for software: if your code has faults, it is because you put them there.

We have seen that faults can exist in requirements, specifications, and designs. We have also seen ways of avoiding such faults (e.g., code review). This section is concerned mainly with faults in the code.

Finding faults • Formal verification: prove that the code is correct • Testing: execute the program and check the results Beware of bugs in the above code; I have only proved it correct, not tried it.

Knuth Testing can reveal only the presence of faults, never their absence.

Donald

Edsger Dijkstra 498

There are essentially two ways of ensuring that the number of faults in code is small or — ideally — zero. One is to prove that the code has no faults and the other is to perform tests designed to find faults. Much effort has been put into proof techniques for programs, but the resulting systems are not widely used in industry. (The main exception is in the UK, where there are legal requirements for certification for certain kinds of critical application.)

Consequently, the main technique for fault detection is testing. Dijkstra has said: testing can reveal only the presence of faults, never their absence. In other words, you can never be certain that your program contains no faults but, with sufficient testing, you can be confident that the number of remaining faults is acceptably small.

172

Varieties of Error • Syntax Errors • Algorithmic Errors • Precision Errors • Documentation Errors • Stress Errors • Capacity Errors • Timing Errors • Performance Errors • Recovery Errors • Hardware Errors • Error of Omission • Error of Commission 499 There are many kinds of fault that can exist in code; some of them are listed below.

Syntax Errors. Most syntax errors are detected by the compiler, but a few are not. (Some people would argue that all syntax errors are caught by the compiler by definition, and that a compiled program therefore cannot contain syntax errors.) However, a declaration such as char*

p, q;

is best classified as a syntax error (if q is meant to be a pointer) but the compiler does not report it.

Algorithmic Errors. A method does not execute according to its specification because there is an error in the coding logic. Some common causes are: • incorrect initialization; • “off by one” error (example: starting at 1 rather than 0, stopping at N rather than N − 1); • incorrect condition (example: forgetting de Morgan’s laws); • misspelling a variable name; type errors that remain undetected in the presence of implicit conversion.

Precision Errors. These arise when a programmer uses an int where a long was needed, or a float where a double was needed. Precision errors can also occur as the result of implicit conversions.

A common example is expecting 2/3 to evaluate to 0.666667 rather than 0 (note that the operands might be variables rather than integer literals).

Documentation Errors. The comments and accompanying code are inconsistent with one another.

If the code is correct, there is not actually a fault. However, there is a strong likelihood of a fault being introduced later by a programmer who believes the documentation rather than the code.

Stress Errors. These are faults that occur when the system is stretched beyond its designed limits.

For example, a simple operating system that had an array of size N for active users might fail when user N + 1 tries to log in. Two kinds of failure are possible: if the new user is refused but the system continues to run, it is a soft failure; if the system crashes, it is a hard failure.

173

Capacity Errors. A word processor is required to handle documents up to 2 Gb in size but its performance is unacceptably slow for documents over 1 Mb. Timing Errors. A system with multiple processes or threads fails occasionally because two events occur in the wrong order or simultaneously. Errors of this kind are very hard to diagnose.

Performance Errors. The requirements state that the system must respond in less than 1 second but in fact the response to some kinds of query is more than 10 seconds.

Recovery Errors. The system is “fault tolerant”: that is, it is supposed to detect certain kinds of failure and recover gracefully. A failure to recover from an anticipated failure is a “recovery error”.

Hardware Errors. Hardware errors are usually, but not necessarily, beyond the programmer’s control. However, safety-critical systems may anticipate hardware failures and, when such a failure occurs, handle it by switching to a stand-by system, for example.

Error of Omission. Something which should be present is not. For example, a variable has not been initialized.

Error of Commission. Something that should not be present is. For example, an exception handler for a low-level failure is included when handling should have been delegated to a higher level component of the system.

Fault Classification Orthogonal Defect Classification (ODC) IBM (http://www.research.ibm.com/softeng/ODC/ODC. HTM) • function • interface • checking/validation • assignment/initialization • timing/serialization • build/package/merge (repositories, version control) • documentation • algorithm 500 Various groups, mostly industrial, have attempted to classify faults. Appropriate fault classification, combined with systematic detection and recording of faults, can provide insight into the strengths and weaknesses of the software development process.

The Orthogonal Defect Classification system (Table 7.1, page 282), developed at IBM, has the following categories of defect (defect ≡ fault): • function; • interface; • checking/validation; • assignment/initialization; • timing/serialization;

174

• build/package/merge (repositories, version control); • documentation; • algorithm.

Fault Classification Hewlett-Packard: Fault Category Logic Documentation Computation Other code Data handling Requirements Process/interprocess Hardware

Occurrence (%) 32 19 18 11 6 5 5 4

501 Hewlett-Packard have another fault classification system (Pfleeger, Figure 7.1, page 283) that they use for “profiling” problems within divisions of the company. Here are the results for one division (see also Figure 7.2, page 284):

Varieties of Testing • Unit Testing: test a component in isolation • Integration Testing: test all components together • Function Testing: test for correct functionality (use cases) • Performance Testing: test for adequate speed, capacity, etc.

• Acceptance Testing: test to show clients that system is complete • Installation Testing: test on clients’ platforms 502 There are various ways to detect faults: reviews are important but, at some stage, it is usually necessary to resort to testing.

A simple definition of testing: execute the system (or one of its components) and compare the results with anticipated results.

The “anticipated results” are the results predicted by the requirements if we are testing the whole system. It may be harder to pin down the anticipated results when we are testing components but, in general, they should be predicted by the design documents.

There are various kinds of testing; not all of the kinds listed below would be needed in small or medium scale projects.

Unit Testing. (Also called module testing or component testing.) We test a component of the system in isolation. The component will expect inputs from other system components and will generate outputs that are sent to other components. For unit testing, we must construct an environment for the component that provides suitable inputs and records the generated outputs.

175

Integration Testing. We test all of the components of the system together to ensure that the system as a whole “works” (that is, compiles and doesn’t crash too often).

Function Testing. Assuming that the system “works” , we test its functions in detail, using the requirements as a basis for test design.

Performance Testing. We measure the system’s speed, memory and disk usage, etc., to confirm that it meets performance requirements.

Acceptance Testing. The previous tests are usually performed by the suppliers. When the suppliers believe the software is ready for delivery, they invite the clients in to confirm that they accept the software.

Installation Testing. When the clients have accepted the software, it is installed at their site (or sites) and tested again.

Testing Teams • Programmers like their code too much to test it properly • Testers must be nasty to code • Random tests are not productive • Tests must be designed carefully 503

30.1

Testing Teams

When you test your own code, it is tempting to be “friendly” to it. After all, you don’t want your nice, new program to crash and, partly subconsciously, you will avoid giving it test data that might make it crash.

This is the wrong attitude! A tester should be as nasty to the code as possible. The goal of testing is to make the software fail.

It follows that programmers are not the best people to test their own code. It is better to assemble a separate testing team of people who have no interest in the code and who get rewarded for smashing it.

Programmers don’t like people who smash their code. It is important to develop psychological habits that avoid “blaming” developers for errors in their code. The viewpoint that everyone should adopt is: “we all want the system to work as well as possible and we will all do what we can to remove errors from it”. This attitude is sometimes called (following Gerald Weinberg) egoless programming.

Random tests are not very useful. The first task of the testing team is to design a battery of tests.

There is an important distinction between black box testing and white box testing. The terms come from electrical engineering; instead of “white” box, we can also so “clear” or “open” box.

Black and white boxes Black box testing tests the component without making use of any knowledge of how it works.

White box testing tests the component using information about how it works. (Also called clear box testing ) 504

176

Black box testing • Consider testing double sin (double x); • Black box: call sin(x) with a few values of x and check against trigonometric tables 505

White box testing Look at the code: double sin (double x) { if (x < 0.0) return - sin(-x); while (x > TWO_PI) x -= TWO_PI; if (x > HALF_PI) return sin(PI - x); if (x < 1e-6) return x; double result = x; for (i = 3; i <= 11; i += 2;) result -= (result * x * x)/(i * (i - 1)); return result; } 506

White box testing The code suggests various tests: • x<0 • x>0 • x < 2π • x > 2π • x< 2 π • x> 2 π

• x < 10−6 • x > 10−6 507

177

White box testing and also some boundary tests: • x=0 • x = 2π • x= 2 π

• x = 10−6 • x > 10−6 508

Procedure for testing a component • Choose data that will be provided to the component as input.

• Decide, before executing the component, what the expected results should be.

• Execute the component with the chosen data and compare the actual and expected results.

• If the expected and actual results are the same, the test has passed. Otherwise the test has failed.

509

Test Set • A test set is a collection of tests.

• Regression testing on a test set is carried out as follows: – Perform tests from the test set one after another – When a test fails, stop testing and wait until the fault has been corrected – Start the tests again from the beginning 510

Difficulties • Inputs may consist of keystrokes, mouse movements and clicks, and other events, instead of just “data”.

• Tests should specify exactly what events will occur and in what order.

• Tests may even specify timing (“the left mouse button is clicked twice with less than 0.5 seconds between clicks”).

• Outputs may appear in many forms: a window is created, destroyed, or turned grey; a popup menu appears; a list of files is displayed; etc.

• Test 23.4: Help functions.

178

– Move the cursor to the Help icon.

– Click the left mouse button once. A popup menu opens.

– Move the cursor to the Contents box.

– Click the left mouse button once.

– ....

511

White box in practice • Include valid data: data that the component is supposed to process and for which the expected results are known.

• Include invalid data: data that the component is not supposed to process.

• Include boundary cases. For example, if a table is supposed to store up to 20 items, test it with (at least) 0, 19, 20, and 21 items.

512 A test set should be a comprehensive collection of specific tests for the software component. Testing is generally more effective if information about the implementation is used — that is, it is at least partially “white box”.

Test coverage • Statement testing ensures that all statements are executed.

• Branch testing ensures that, wherever there is a “branch point” (if or switch statement), each branch is executed in at least one test.

• Path testing executes each path in the component (considered as a directed graph).

• Other possibilities: e.g., ensure that each definition/use pair is tested.

513 The coverage of a test set is the code that will be exercised by performing all the tests in the test set.

Branch versus path testing if (pulseRate > 0) rep.add("pulse present"); else { rep.add("no pulse"); flow = 0; } if (!insured) fillTime = capacity / flow; else rep.add("send home");

Branch testing: 1. pulseRate > 0 2. pulseRate ≤ 0 3. !insured 4. insured

179

514

Branch versus path testing Path testing:

if (pulseRate > 0) rep.add("pulse present"); else { rep.add("no pulse"); flow = 0; } if (!insured) fillTime = capacity / flow; else rep.add("send home");

1. pulseRate > 0 && !insured 2. pulseRate > 0 && insured

515

3. pulseRate ≤ 0 && !insured — FAIL! 4. pulseRate ≤ 0 && insured

Branch versus path testing

516

30.2

Integration Testing

When components have been tested, they can be incorporated into the growing system. Integration testing means testing a group of components together. There are various ways in which integration testing can be carried out:

Integration Testing • Bottom-up Integration First test components Cn that have no dependencies; then components Cn−1 that depend only on components Cn; etc.

• Top-down Integration First test components C0 that are not called by an components; then test components C1 that are called by C0 components; etc.

• Big-Bang Integration Test components individually, then all together

180

• Sandwich Integration Combine bottom-up and top-down integration 517 Bottom-up Integration. First test the components Cn that don’t use any other components; then test the components Cn−1 that use the components Cn but no others; and so on.

In bottom-up integration, the components that a component uses have already been tested and can be used in the test on the assumption that they work correctly. However, we will need to build drivers to call the components, because the code that will eventually call them has not yet been tested. Drivers are written as simply as possible but should realistically exercise the components under test.

Top-down Integration. First test the components C0 that are not called by any other components; then test the components C1 that are called by components C0; and so on.

In top-down integration, the components that call the component under test can be used on the assumption that they work correctly. However, we will need to build stubs that simulate the components called by the component under test. Stubs are written as simply as possible: they respond to all reasonable requests but return very simple results.

Big-Bang Integration. First test the components individually, then link all the components together, click Run, and see what happens (usually the system crashes immediately). For systems of any complexity, big-bang integration is unlikely to be efficient. The problem is that, when failures occur, it is hard to figure out what caused them.

Sandwich Integration. This is a combination of top-down and bottom-up, the objective being to converge on a layer in the “middle” of the system for which higher and lower components have already been tested. The following advantages are claimed for sandwich testing: • Integration testing can start early in the testing process, because groups of components can be tested.

• Top-level components (control) and bottom-level components (utilities) are both tested early.

Cyclic Dependencies • Cycles in the dependency graph prevent bottom-up or top-down integration • All components in a cycle must be tested together • Avoid cycles!

518

Goals for integration • Each component should be tested exactly once.

• A single test should involve as few components as possible, preferably one.

• A component should never be modified for the purpose of testing.

• Need stubs and drivers: keep them!

519

181

Stubs and Drivers • A stub is a dummy component that can be called during testing.

• Stubs respond to calls with default return values • A driver is a dummy component that calls another component during testing.

• Drivers pass chosen arguments to called components.

• Code for stubs and drivers is not part of the system.

520

Stubs and Drivers A

Stub1

Driver

B

Stub2

C

D 521

30.3

Testing Object Oriented Code

A high proportion of new code is object oriented. As such, it presents a few special problems for testing.

Although OO code has special problems, it should also have certain advantages with respect to testing.

In particular, if classes respect encapsulation, it should be possible to test them independently of classes that use them (although not classes that they use).

Testing Object-Oriented Code Encapsulation simplifies testing.

Special problems: • Testing classes individually is difficult in the presence of inheritance.

• Suppose that a parent class P has children C1, C2, . . ..

• Then methods in Ci may invoke methods in P .

• If an error in Ci is caused by an error in P , correcting the error in P may break code in Cj (i /= j).

• Dynamic binding: effect of o.f() depends on the class of o.

522

182

Testing Strategies • Establish a plan for testing • (Ad hoc testing produces odd hacks.)

• A test plan consists of a collection of tests and a strategy for applying them.

523

Test Plan The test plan should describe: • what happens when a test fails • what happens when faults detected have been corrected • how test results should be recorded 524

Regression Testing • Perform tests T1, T2, T3, . . .

• If test Tn fails, repeat tests T1, T2, . . . , Tn 525 • The plan should describe what happens if a test fails. Usually, the failure is noted and tests proceed. However, if the test is a particularly significant one, testing may have to be delayed until the fault is corrected. For example, if the system fails on startup, the testing team have to wait until the problem is fixed.

• The plan should describe what happens when the faults revealed by tests have been corrected. A common strategy is called regression testing. Assume that the tests are numbered 1, 2, 3, . . . and that test n fails. After the fault has been corrected, regression testing requires that tests 1, 2, . . . , n must all be repeated.

Regression testing takes a long time. If possible it should be automated (see below). Otherwise, a careful analysis should be performed to see if all of the previous tests must be repeated or whether some of them are, in some sense, independent of test n.

• Test results must be carefully recorded.

Automation. If possible, testing should be automated. This requires a program that can: • invoke the component under test with suitable test data; • observe the effect of the test; • decide whether to stop or continue, depending on the results for the test.

Automatic testing is fairly straightforward if we are dealing with functions that accept parameters and return results. It is more complicated if we are testing, for example, a windows-based application.

However, there are testing tools that will record a sequence of events (keystrokes, mouse movements, etc.) and “play them back” during testing.

183

Automated Testing • Whenever possible, testing should be automated • Embed system in a test harness • Tests are executed, results collected • XP requires one-button automatic testing 526

JUnit • JUnit is a framework for automatic testing of Java programs: http://www.junit.org/ • To

get started:

http://junit.sourceforge.net/doc/cookbook/cookbook.htm 527

A JUnit Test From http://junit.sourceforge.net/doc/cookbook/cookbook.htm: @Test public void simpleAdd() { Money m12CHF= new Money(12, "CHF"); Money m14CHF= new Money(14, "CHF"); Money expected= new Money(26, "CHF"); Money result= m12CHF.add(m14CHF); assertTrue(expected.equals(result)); } Running tests: java org.junit.runner.JUnitCore TestClass1 ....

528

Other Testing Tools • Static Analyzers check code without executing it • Test Case Generators analyze code and generate tests for it • Dynamic Analyzers make measurements while the code is executing • Capture and Replay Tools record user actions and can repeat them automatically 529

184

Static Analysis double score; if (player.started()) { score = 0.0; .... } else { .... } Warning: variable score is not initialized if player.started() is false.

530

Test Case Generation Function to be tested: string grade(double score) { if (score > 90) return "A"; else if (score > 80) return "B" else return "F"; } Generated tests: test(95); test(85); test(75); 531 Although it is not strictly “testing”, software tools can be used to check code both statically and dynamically.

• Static analyzers check that variables are initialized before they are used, that all statements can be reached, that components are linked in appropriate ways, etc. Compilers perform some static analysis, of course, but they tend to be better at within-component analysis than at between-component analysis.

• Test case generators analyze the source code a generate tests based on it. These tools can ensure, for example, that there are tests for each branch of every condition statements. Of course, if the code contains errors, a test case generator may generate inappropriate tests.

• Dynamic analyzers make measurements while the code is running. They can collect statistics about the frequency of execution of various blocks and look for potential synchronization problems in concurrent processes.

• Capture and replay tools record a sequence of user actions and can play them back later.

User actions include keystrokes, mouse movements, and mouse clicks. These tools avoid the time-consuming and error-prone task of repeating a complicated series of actions whenever a test has to be run.

185

When do you stop testing? The testing strategy must include a criterion for terminating testing.

Ideally, we would terminate testing when there are no faults left. In practice, this would mean testing for ever for most systems. We can make the following observations:

When does testing stop?

• Ideal: stop when there are no faults left • In practice: – Assuming that testing is continuous, the rate of fault detection is likely to fall.

– The accumulated cost of testing increases with time.

– The value of the product probably decreases with time (for example, competitors get to the market).

• There will be a break-even point at which it is better to release the product than to continue testing • It would be useful to estimate the number of faults still in the code 532 At some time, there will be a break-even point where it is better to release the product with residual faults than it is to continue testing. Of course, it is not always easy to decide exactly when the break-even point has been reached!

Fault Estimation • Assume that the software contains n faults • We want to obtain an estimate of n: call it n̂ • Two groups of testers, X and Y , test for a given period • Group X finds x faults • Group Y finds y faults • q faults were found by both groups: q ≤ x and q ≤ y 533

Fault Estimation • The eflectiveness of a group is the number of faults found divided by the total number of faults: Ex Ey

= x/n̂ = y/n̂

• Another measure of effectiveness: divide faults found by both groups by faults found by the other group: Ex′

=

q/y

E′

=

q/x

y

534

186

Fault Estimation • Assume these measures are equivalent: E′ = Ex and E′ = Ey x

y

• Then x/n̂ y/n̂

= =

q/y q/x

both of which give n̂ =

xy/q 535

Fault Estimation q E′ = q/y

Case

x

y

1 2 3 4 5 6 7 8

20 20 20 20 20 20 20 20

20 20 20 10 20 5 20 1 20 0 5 5 5 1 0 0

x

1.0 0.5 0.25 0.05 0.0 1.0 0.2 0.0

E′ = q/x

n̂ = xy/q

1.0 0.5 0.25 0.05 0.0 0.25 0.05 0/0

20 40 80 400 ∞ 20 100 0/0

y

536

Fault Estimation • Lines 1–5: as the number of common faults goes down, the estimate goes up • Lines 6–7: Different numbers of errors found (20 and 5) tend to reduce extreme effects (cf. 400 in line 4 and 100 in line 7) • Lines 8: fails if one team finds no errors 537

Fault Estimation Justification: • The number of faults in the system is n (which is unknown). Team X, with efficiency Ex, expects to find a set Sx of faults, with |Sx| = n Ex. • Similarly, Y expects to find a set Sy of faults, with |Sy| = n Ey. • Consider a particular fault, f . The probability that f ∈ Sx is Ex and the probability that f ∈ Sy is Ey.

187

• If these probabilities are independent then the probability that f ∈ Sx ∩Sy is ExEy. The expected number of faults in Sx ∩ Sy is therefore n ExEy. • Thus we have n̂

|Sx| |Sy| |Sx ∩ Sy| n Ex × n Ey = n Ex Ey = n =

538

Fault Estimation • The flaw in this argument is the assumption that the probabilities Ex and Ey are independent.

• It is more likely that both teams will find the same obvious faults and that neither team will find the obscure faults.

• The number of common faults found is likely to be more than n ExEy and the estimate n̂ is probably too large.

539

Fault Seeding / Fault Insertion • Another way of measuring fault density is by inserting faults into the software and then testing for a while.

• Suppose that the software contains S seeded faults and F real (i.e., unseeded) faults.

• Suppose also that the testing team discovers s seeded faults and f unseeded faults.

• Then we can estimate the unknown F by assuming s/S = f/F , giving F

=

fS s

• Less effective than the “two teams” approach described previously 540

Checking and Inspection • Desk Checking: read code carefully before running it • Walkthrough: present code to a small group line by line • Inspection: structured walkthrough (Fagan, 1976) 541

188

Fagan Inspection • Planning: prepare materials, organize participants and meeting • Overview: educate participants and assign roles • Preparation: participants review material and rehearse roles • Inspection: meet and go through material • Rework: resolve discovered defects • Follow-up: verify that all defects have been corrected 542

Fagan Inspection • Inspection thought to be more cost-effective than individual debugging • Some more recent research disputes this • Improved inspection techniques developed 543 It is often more productive to read the code than to run tests on it. After you have observed a fault, you have to read the code anyway, to see what went wrong. Often, you can avoid the need for debugging by spotting the error before running the tests. There are several ways of reading code.

Desk Checking. Get into the habit of reading code that you have just written before running it.

This often saves time because simple errors sometimes lead to very strange symptoms.

Code Walkthrough. During a “walkthrough”, a programmer presents code to a small group line by line, explaining the purpose of each line. Members of the group read the lines as they are presented to ensure that the code actually does what the presenter claims it does. It is important to place emphasis on the code itself, not on the person who wrote it. When people question features of the code, the programmer’s job is not to defend it but to admit that it is wrong or explain why it is correct although it appears to be wrong.

It is best not to attempt to correct errors during the walkthrough; the important thing is to identify errors for subsequent correction.

Code Inspection. Code inspection was introduced in 1976 at IBM by Mike Fagan. An inspection is like a walkthrough in that code is studied carefully but an inspection involves another set of documents, which can be requirements, specifications, or designs. The purpose of the inspection is to check that the code does in fact meet the requirements, satisfy the specifications, or implement the designs. The people present include the originators of the documents as well as the implementors of the code.

Inspections are sometimes conducted as three-phase processes. There is a preliminary meeting at which the goals of the inspection are identified. Then team members study the code individually, noting any errors that they find. Finally, there is another meeting of the inspection team during which the errors are presented and discussed.

There has been a substantial amount of research into the effectiveness of code reviews. Most of the results confirm that reading and inspecting code is more eflective than debugging. That is, the number of faults identified for each person-hour spent is greater when the people are inspecting code than when they are debugging it.

189

31 System Testing Varieties of Testing • Unit Testing: test a component in isolation • Integration Testing: test all components together • Function Testing: test for correct functionality (use cases) • Performance Testing: test for adequate speed, capacity, etc.

• Acceptance Testing: test to show clients that system is complete • Installation Testing: test on clients’ platforms 544 We have already discussed Unit Testing and Integration Testing. The remaining four kinds of testing are often called collectively System Testing.

System Testing The last four of these may be bracketed together and called System Testing: • Function Testing: test for correct functionality (use cases) • Performance Testing: test for adequate speed, capacity, etc.

• Acceptance Testing: test to show clients that system is complete • Installation Testing: test on clients’ platforms 545 In some cases, the code forms the major part of the system and, when program testing is complete, there is not much more to do. In the majority of cases, however, the code component of a software engineering project is only one part of the total system.

System Testing As before: • faults in the system lead to failures • failures must be identified and the corresponding faults corrected • run regression tests to ensure that new faults have not been introduced 546

Example: Flight Control • Suppose that the product is flight-control software for a new kind of aircraft • The system is the aircraft as a whole 547

190

Example: Flight Control Function Testing: • Software is thoroughly tested in an environment that simulates the aircraft • Software is provided with inputs close to those that it would receive in actual flight • Software must respond with appropriate control signals • When the function test results have been accepted, we have a functioning system 548

Example: Flight Control Performance Testing: • “Non-functional requirements” of the software are thoroughly tested • Does it respond within acceptable time limits?

• Are there any circumstances in which available memory might be exhausted?

• Does it degrade gracefully when things go wrong?

• If there are duplicated subsystems, is control transferred between them when expected?

• Others: stress, volume, configuration, compatibility, regression, security, timing, environment, quality, recovery, maintenance, documentation, and human factors (or usability) • After performance testing, we have a verified system 549

Example: Flight Control Acceptance Testing: • The tests are run for the clients, still on simulated equipment • Experienced pilots will “fly” the simulated aircraft and will practice unusual as well as standard manoeuvres • After acceptance testing, the clients agree that this is the system that they want • The system is said to be validated 550

191

Example: Flight Control Installation Testing: • The software is installed on an actual aircraft and tested again • tests are conducted slowly and carefully because of the consequences of an error – Runway tests – Short flights – Normal flights • After successful installation, the software is deployed • The maintenance phase starts 551 Problems can persist even with all this testing. For example, NASA experienced a memory leak during one of the Apollo moon shots. The eak used up memory in the rocket, but not in the ground simulation.

It was caused by an astronaut failing to turn off a crucial device after take-off.

There are some aspects of system testing that are significantly different from program testing. These are discussed briefly here.

Other Aspects of System Testing • Configuration • Versions • Releases • Production System • Development System • Deltas 552

Configuration • The software may have to run in many different configurations • In the worst case, each platform may be unique • All of these must be tested, either on a common platform or on the intended platform for which they are intended 553

192

Versions • Later versions replace earlier versions • There may be a tree of versions to accommodate different configurations and platforms • Need version control tools 554 Stu Feldman refers to more than a thousand make file needed for telecom projects.

Releases • Release is a formal variation of version • The software is issued in a series of numbered releases, each of which is intended to be an improvement on its predecessors • Major releases incorporate significant enhancements • Minor releases correct small problems • Systematic numbering: “Release 4.3” is the third revision of the fourth major release.

555

Production System • Developers keep a version of the software identical to the client’s • This is the production system • Client complaints and problems can be resolved by using the production system • There may be many production systems in use at one time 556

Development System • The Development System is used by developers to continue enhancing the software • At selected times: the Development System 1. is made into a new release 2. is delivered to clients 3. becomes the Production System 557

193

Deltas • Keeping complete copies of versions requires space and (copying) time • Alternative: keep one complete version (“base”) and deltas • A delta records the differences between base and a variation • Releases can be made quickly from base and deltas • Important not to lose the base!

• E.g., UNIX

TM

SCCS (Source Code Control System) uses deltas

• Recent source control systems: SVN, GIT, . . .

558

31.1

Reliability, Availability, Maintainability

Reliability • Reliability is a measure of the system’s ability to run without failure for a given time interval • Time is measured while the system is running, not when it is idle • E.g., a system that performs flawlessly for 5 seconds each year is 100% reliable • Reliability varies from 0 (never available) to 1 (always available) 559 A system is reliable to the extent that it can operate without failure for a given time interval. The time is measured while the system is running, not while it is idle. A system that is required to run for 5 seconds a year, and always performs flawlessly for those 5 seconds, is entirely reliable. Reliability is usually measured on a scale of 0 to 1 in which 0 means the system never operates and 1 means that it always operates.

Availability • Availability is a measure of the system’s ability to perform when needed • If the system is currently running, it is available • If the system is “down” for repairs, it is not available • Availability is measured in real time, not execution time 560 A system is available to the extent that it is operating correctly when it is needed. If the system is currently running, it is available. If it is “down” for repairs, it is not available. Availability time is real time, not execution time. A system that runs for 5 seconds per year has low availability, even if it runs flawlessly during those 5 seconds.

194

Maintainability • Maintainability is a measure of the time taken to recover from failure • Hardware is usually unavailable during repair work • Modern software systems may be required to be available even during maintenance • “Hot loading” means replacing components while the software is executing 561 A system is maintainable to the extent that, after a failure, it can be made to operate again within a given period of time with a given probability. Whereas hardware systems are usually unavailable during maintenance, there are an increasing number of software systems that are required to operate while they are being maintained.

32 Software Reliability Modelling Software Reliability Modelling • It is useful to get some quantitative results about reliability • Warning: these definitions are widely used, but have problems!

• Define: MTTF = mean time to failure MTTR = mean time to repair MTBF = mean time between failures = MTTF + MTTR • These measures are well-defined and meaningful.

562

Software Reliability Modelling running repairing TBF TTF

TTR 563

195

Software Reliability Modelling Reliability = Availability = Maintainability =

MTTF 1 + MTTF MTBF 1 + MTBF 1 1 + MTTR 564

Software Reliability Modelling These parameters: • have values value between 0 and 1 • are given in various text books, etc.

• are meaningless 565

Software Reliability Modelling Suppose MTTF = 4 days = 5760 minutes MTTR = 0.0138 days = 20 minutes Unit of time is 1 day:

Unit of time is 1 minute:

Reliability =

1+4

Availability =

1+4+0.0138

Reliability =

1+5760

Availability =

1+5760+20

4 4+0.0138

5760 5760+20

=

0.8

=

0.9863

=

0.9998

=

0.9998

566 The clue: dimensional analysis. Adding 1 to a time imp[lies that 1 is a time — but what is its unit?

Software Reliability Modelling A better analysis: pages 622–3 of Software Engineering: an Engineering Approach by Peters and Pedrycz (Wiley, 2000) • System has two states: up (running) and down (being repaired) • Define transition probabilities for time interval ∆t: up → down = λ ∆t down → up = µ ∆t In these equations, ∆t does not have to be small: it could be a minute or a month.

196

• The transition probability matrix for the system is: 1 − λ ∆t µ ∆t

λ ∆t 1 − µ ∆t 567

Software Reliability Modelling • pu(t) is the probability that the system is up at time t • pd(t) is the probability that the system is down at time t • From the transition probability matrix: pu(t + ∆t) = =

p (t) p (t) u

pd(t + ∆t) 1 − λ ∆t

λ ∆t

d

µ ∆t 1 − µ ∆t pu(t)(1 − λ ∆t) + pd(t)µ ∆t pu(t)λ ∆t + pd(t)(1 − µ ∆t) 568

Software Reliability Modelling • Equivalently: pu(t + ∆t) = pu(t)(1 − λ ∆t) + pd(t)µ ∆t pd(t + ∆t) = pu(t)λ ∆t + pd(t)(1 − µ ∆t) • Solving this as an ODE gives the dynamic behaviour of the system • To find the steady state solution, set ∆t = 0: −λpu + µpd =

0

λpu − µpd

0

=

These two equations are equivalent, and don’t provide as much information as might first appear.

569

Software Reliability Modelling • From probability theory, pu + pd = 1. Therefore: pu = pd =

µ λ+µ λ λ+µ

• Define Availability = pu 570

197

Software Reliability Modelling Example: • Probability of failure during a one hour run is 1% • Probability of repairing it within one hour is 90% • Then: λ µ λ+µ pu

= = = = =

0.01 0.9 0.91 0.9/0.91 0.989

• The system has an availability of 98.9% 571 During the development, we (hopefully) remove defects from the software. Thus we can assume that the reliability improves. In general, we expect • The reliability is initially very low (close to zero), because most components will have faults.

• The reliability improves monotonically during development, as faults are removed.

• The reliability tends asymptotically to 1.

As a consequence, we can say that the cost of testing (measured as the time required to detect and correct one fault) must increase (the fewer the faults, the harder they are to find).

Software Reliability Modelling • Reliability tends to increase with time • Early release =⇒ unreliable system • Late release =⇒ reliable system 572

Software Reliability Modelling reliability 1 R2

R1

T1

198

T2 time

573 As the reliability increases, the cost of releasing the software decreases. To see this, suppose we release the software at an early stage, when there are many faults. There will be numerous complaints from clients, and the developers will spend a lot of time attending to them. Even worse, potential sales will fall as news of the unreliability spreads. Conversely, if we wait until the software is practically perfect before releasing it, there will be few complaints, and the cost of release will be low.

Now consider the total cost, the sum of the cost of testing and the cost of releasing, as a function of time, t. For small t, it is high because of client complaints. For large t, it is large because tests are expensive. Therefore (as economists say), there must be a value of t for which the total cost is minimal; this is the best time to release the software.

Software Reliability Modelling • Early release: – low cost of testing – high cost of releasing unreliable software – keep ahead of competitors • Late release – high cost of testing – low cost of releasing reliable software – possible loss of market • There may be an optimum time of release. . . if we can find it!

574

Software Reliability Modelling cost

total cost cost of testing

cost of releasing Topt

time 575

33 Delivery Although delivery is important in practice, we will not spend a lot of time on it in this course. The main point to note is that the delivery process depends strongly on the kind of system.

199

Delivery Shrink-wrap Software: • Self-contained: vendors do not meet customers • Documentation with product or available on-line • May be internet or telephone support • Product should be easy to install, learn, and use • Cost: $0 – $5K 576

Delivery Standard but expensive: • Above $5K, customers expect extras • help with installation • on-site acceptance tests • training courses • vendor site or customer site 577

Delivery Bespoke software: • developed for a particular customer • close relationship between developer and customer • delivery is neither the first nor the last step: just a milestone 578 • “Shrink-wrap” software is delivered to customers through retail stores. The product must be essentially self-contained because the suppliers cannot afford to spend time with individual clients; the best they can do is provide some kind of assistance via internet or telephone. This implies that: the software should be easy to install, learn, and use; and that all documentation, printed or on-line, comes with the package. The cost of shrink-wrap software ranges from about $5 to $5 000.

• Above $5 000 or so, customers expect additional services. The suppliers may offer: help with installation; on-site acceptance tests; and training courses, at either their own or the customer’s site.

200

• When the software is developed for an individual client, there will probably be a close relationship between the supplier and the client. As we have seen, the client will be involved with the software from an early stage, such as requirements analysis. Delivery will be just one step — albeit an important step — in the software development process. Delivery is not the last step; rather, it signals a transition from development to maintenance.

Software will not be used unless its users understand it and are comfortable with it. “Shelfware” is the name give to software purchased, sometimes at considerable cost, and then never used. To avoid your product becoming shelfware: • make the software as easy to use as possible; • write clear and unambiguous user manuals; • provide on-line help, where applicable; • write all documentation from the point of view of the user rather than the programmer.

Delivery Shelfware • shelfware is software that is paid for, delivered, and never used • To avoid becoming shelfware, your product should: – be as easy to use as possible – come with clear and unambiguous user manuals – provide on-line help, where applicable – be documented from the point of view of the user rather than the programmer 579

34 Maintenance After software has been delivered, in whatever form, it must be maintained. Studies support the “80–20 rule”: over the entire lifespan of a software product, 20% of the effort is in development and 80% is in maintenance.

The word “maintenance” suggests lubricating your bicycle or taking an applicance to Mr FixIt to have a part replaced. This kind of maintenance clearly does not apply to software, because code does not get stiff or wear out. Software maintenance is generally divided into four varieties.

Maintenance • The usual estimate of the cost of maintenance as a proportion of the total cost is 80%.

• Some recent authors put it higher: up to 90%.

• Conventional classification: perfective, adaptive, corrective, preventive • Proportion of effort:

201

Activity Perfective maintenance Adaptive maintenance Corrective maintenance Preventive maintenance

% Effort 50 25 21 4 580

Perfective Maintenance (50%) • improves the system even when it is not failing • some improvements may not be visible to users • other improvements may be visible: e.g., short-cuts • algorithms and data structures may be changed • improvements may make future maintenance easier 581

Adaptive Maintenance (25%) • improves the system even when it is not failing • responds to changing conditions • operating system upgrades may require adaptation • hardware may be modified 582

Corrective Maintenance (21%) • responds to faults detected by developer or customer • determine cause of fault • choose strategy for correcting it • make the correction • document the change process 583

202

Preventive Maintenance (4%) • prevent failures before they occur • look for weak spots and insecurities in the code • preventive and corrective maintenance often go together: while correcting one fault, prevent similar faults • security is a very big issue in modern systems 584 After the suppliers have delivered a product, it is essential that they devote some resources to maintaining it. The maintenance team can be of any size from one person to thousands of people. Exact data is hard to find, but here is one specific example: in 1990, WordPerfect employed 600 people whose sole responsibility was to answer telephone complaints.

Maintenance Team Responsibilities of the maintenance team include: • understanding the software; • becoming familiar with the system documentation; • answering questions about the way in which the system works (or is supposed to work); • analysing faults and problems; • locating the cause of faults in the code and correcting the code; • keeping system documentation up to date (changes to code imply changes to documents); • restructuring design documents and the corresponding code; • deleting parts of documents and code that are no longer used; • adapting existing functions to changing requirements; • adding new functions; • managing change.

585 There are many problems associated with maintenance. Here are brief discussions of a few of them.

Maintenance Difficulties • Understanding the software • Management • Morale • Longevity • Managing change 586

203

Understanding the Software. One study showed that 47% of maintenance programmers’ time is spent in understanding the software. This is a natural consequence of several factors: • Most developers keep their “best” programmers for development, considering them too important for maintenance. Consequently, maintenance programmers are usually not top calibre.

• Newly-hired programmers are often given maintenance tasks before they are allowed to work on development.

• Developers are closely associated with the software for a long time and come to know it well.

Maintainers may be given a component with a problem and told to “fix it”. It may take them a long time to become familar with the overall structure of the system

Understanding the software • maintainers spend 47% of their time understsanding the code • most developers keep their “best” programmers for new development • maintainers are often not the best programmers • new hires are often given maintenance work before being allowed to develop • developers live with the software for a long time and know it well • maintainers are typically much less familiar with the software • maintainers may (not) be allowed to consult developers: company policy 587 Management. There is usually a lot of pressure from managers to get faults repaired rapidly to please the client. Conscientious programmers who spend a lot of time analyzing and trying to understand the fault receive less praise than sloppy programmers who find a “quick fix”. As the quick fixes accumulate, the software becomes harder to understand and repair. The short-term policy of rapid repair has the long-term consequence of software that is “brittle” — it is poorly structured and breaks under the slightest strain.

Management • pressure from managers to get faults repaired quickly • tendency to produce “quick fixes” rather than good solutions • many quick fixes =⇒ unmaintainable software • old software is often called brittle: touch it and it breaks 588

204

Morale. Maintenance programmers often have a lower status than developers. This is unjustified because maintenance programming is in some ways harder than development programming. Nevertheless, the perception that the maintainers are “second tier” programmers is common and has the effect that every maintainer wants to be “promoted” to development.

The morale problem can be handled by a good manager who treats all programmers as equals and who requires everyone to take turns at development and maintenance. This approach has the added advantage that doing maintenance gives the development programmers a better understanding of the importance of clarity, simple solutions, and good documentation.

Morale • maintainers have a lower (perceived) status than developers • maintainers may feel “second class” and have low morale • some companies rotate programmers between development and maintenance: – improves morale – maintainers become more familiar with code – developers become more aware of maintainers’ needs 589 Longevity. The long life of software creates maintenance problems. A large system may be used for 20 years or more. Moore’s Law says that hardware performance doubles about every 18 months.

During the 20–year lifespan of the software, the hardware that it runs on can be expected to improve by a factor of 220/1.5 10 ≈ 000. Design decisions that seemed reasonable during the initial development phase may look stupid in the light of such improvements.

The classic example of a longevity problem was the much-exaggerated “Y2K” problem, introduced by the decision to assign two digits rather than four digits to the “year” field in many programs.

Performance, however, was not the major factor in the Y2K problem. The decision to use two digits for the year was not made because memory was expensive but because it simply did not occur to the designers that their code would still be running in 1999.

Longevity • large systems are used for 20 years or more • Moore’s Law: hardware performance doubles in 18 months • during lifetime of software, hardware will improve by a factor of about 220/1.5 ≈ 10, 000 • design decisions made during development may become inappropriate • Y2K problem: during 1960–1990, developers used two-digit years to save memory (!). By 2000, when problems arose, this seemed an absurd economy.

590

205

Managing Change. The maintenance team must know, at all times, the exact status of each component of the system. Each time there is a change request for any component, the some or all of the following information should be recorded.

Managing change • maintainers must always know the exact status of the system • need a system for change requests (RFCs) • RFC should include: Synchronization : when is the change to be made?

Identification : who will make the change?

Naming : what components of the system are affected?

Authorization : who gave permission for the change to be made?

Cancellation : who can cancel the change request?

Routing : who will be informed of the change?

Delegation : who is responsible for the change after it has been made?

Valuation : what is the priority of the change?

Authentication : was the change made correctly?

591 The traditional approach to maintenance is that you maintain the system until it becomes unmaintainable — that is, the cost of keeping it running exceeds the benefit of running it. At this time, the system is scrapped and either rewritten from scratch or replaced by a new system designed to different requirements.

A more modern approach is to attempt to rejuvenate the software. If rejuvenation succeeds, the system becomes easier to maintain and its useful life can be extended. There are various approaches to rejuvenation, some simple and others more drastic.

Rejuvenation • Old model: – maintain software until it becomes unmaintainable – abandon it, or – rewrite from scratch, probably in a different language • New model: – keep the software fresh and “new” • Approaches: redocumentation, reverse engineering, reengineering, restructuring, refactoring, paradigm change 592

206

Redocumentation • analyze system thoroughly • prepare new documentation for it • doesn’t improve software, but allows other forms of rejuvenation • beneficial side-effect: programmers become familiar with the software 593

Reverse Engineering • infer the design of the system by analyzing the code • would not be necessary if software was properly developed in the first place, but often it wasn’t • powerful tools exist to help with system analysis 594

Reengineering • reverse engineer and then forward engineer • that is, first understand the system and then rewrite (parts of) it • changes structure without changing functionality • E.g., convert a single-processor system to a distributed system 595

Restructuring • modify code to improve maintainability • modify code to reflect advances in the programming language. E.g., recode Java programs using generics • can sometimes be automated 596

Refactoring • similar to restructuring, but may be on a larger scale • merge/split components for performance/maintainability • redistribute functionality 597

207

Paradigm Change • modify software to reflect a new paradigm • rewrite procedural code as object-oriented code • rewrite object-oriented code in functional style 598

Verification and Validation Verifying the system is the process of ensuring that the software is internally consistent and that all functions perform according to specifications. Informally, verification answers the question: Have we built the system right?

Validating the system is the process of ensuring that the software meets the clients needs. Informally, verification answers the question: Have we built the right system?

599

Case Studies from Aerospace Why aerospace?

• there is software that is not games or web apps • aerospace provides good examples of software engineering • projects are large • safety is important • mistakes are well-documented 600

35 RADARSAT Payload Computer Software System RADARSAT Payload Computer Software System Contractor: Spar Space Systems Designer: Manh The Nguyen (BCS, Concordia, 1982) • Spar Space Systems was part of Spar Aerospace • Spar Aerospace was based in Edmonton • Operational from 1967 – 2009 • Produced hardware for satellites, shuttle, space-station, etc.

• Now part of MacDonald Dettwiler 601

208

RADARSAT • First Canadian remote sensing spacecraft • Launched in 1995 • Planned operational life: 5 years — lasted longer • Imaging with Synthetic Aperture Radar (SAR) • Horizontally polarized C-band microwave radiation • Wavelength 5.6 cm • First spacecraft to implement ScanSAR to obtain wider image 602

RADARSAT • Orbit: 800 km near-polar (full earth coverage) • Resolution: 10 to 100 m • Image width: 45 to 500 km on ground • Incidence angle: 20◦ to 50◦ • Resolution/image/incidence controlled from ground • Permits imaging through heavy cloud night and day • Can measure: – soil texture – vegetation conditions – sea-ice concentrations and dynamics – geological surface structures 603

RADARSAT

209

604

RADARSAT: Montreal with winter flooding

605

RADARSAT: Dresden flooding

210

606

RADARSAT: Dresden map overlay

607

RADARSAT: Classifying wetlands

211

608

RADARSAT Two modules: • BUS Module • SAR Payload Module 609

Bus Module • Command, Telemetry, and Ranging (CT&R) allows Mission Control System (MCS) to communicate with Payload Module • Attitude Control Subsystem (ACS) has yaw, roll, and pitch sensors that enable the Attitude Control Processor (ACP) to maintain altitude accurately • Electrical Power Subsystem (EPS) provides regulated power (solar cells and storage batteries) • Propulsion subsystem for orbital adjustments • Thermal subsystem uses thermostatically controlled heaters to maintain all components within preset temperature limits 610

Payload Module • SAR Antenna (ANT) transmits selectable beam shapes • Receiver (RCVR) detects radar return signal and digitizes it

212

• High Rate Tape Recorder (HRTR) stores SAR data • Downlink Transmitter (DLTX) modulates digitized SAR data for X-band transmission (8–12 GHz) • Low Power Transmitter (LPT) generates coded waveforms for radar pulses • High Power Microwave Circuits (HPMC) converts LPT signal to high peak-power pulse for radar 611

Payload Module • Calibration (CALN) subsystem routes signals between SAR components • Timing and Data Handling (T&DH) generates all reference frequencies and timing signals • Payload Computer System (PLC) – controls everything – health-monitoring and fault analysis for all subsystems – primary Payload status monitoring function – interfaces Bus module to MCS 612

Payload Module • Subsystems in the Bus controlled directly by Mission Control via the CT&R • Subsystems in the Payload are controlled by the PLC • The PLC hardware is based on Spacecraft On-board Modular Microcomputer (SOMM) • SOMM consists of modules connected by Unit Bus (UB) — a proprietary Spar Bus protocol 613

PLC Software • Initial Program Load ROM (IPL) uploads operational software • Control Program monitors spacecraft “health”, analyses faults, controls equipment, and executes Tables • Application Logic, expressed as Tables, a.k.a. Computer Software Configuration Items (CSCIs) 614

213

Computer Software Configuration Items • Payload Computer Initialize Software (PCIS) (= IPL) resides in ROM • Payload Computer Application Software (PCAS) = Control Program 615

Normal scenario • Ground Station generates operational tables based on client’s request • verifies tables with Ground Station simulator • uploads Tables to satellite • starts operation 616

Tables Two kinds of table: • One-Shot Table which triggers one or more control operations that are executed continuously • Sequence Command Table which defines a sequence of One-Shot operations with delays between them Rationale for this approach: • Evolution of Control Program continues after launch but at a low rate • Operational complexity occurs on the ground • Programmed operations can be verified on the ground by simulation • Simple integration scheme for the spacecraft 617

Software Development Methodology • Goal: high quality software at a reasonable cost.

• Difficulties: – Software solutions are often applied to problems that are new and poorly defined – Discontinuity in input/output flows make mathematical modelling hard – Complexity level of software increases exponentially with the size of the program • BUT: software is still more economical than hardware.

618

214

Software Development Methodology Payload Computer Application Software (PCAS): • developed by Composite Methodology for Real-Time System Software Development Process (CMRS SDP) • introduced by Nguyen and Bishun Notation: • cloud represents (uncertain) initial user requirements • rectangles represent activities • hexagon represents information storage • circle with arrows indicates the actual data flow (read/write/update) • solid lines indicate the information invocation direction • dashed lines indicate control flow that triggers the start of each activity 619

Software Development Methodology CMRS tries to balance two approaches: • Waterfall Model: start next phase only when current phase is completely understood.

• Spiral Model: – initially problem is not understood – repeat ∗ analysis ∗ design ∗ coding ∗ testing until problem understood 620

Software Development Methodology CMRS Process: • Requirements Analysis – rapid throwaway prototype helps clients to identify needs and examine feasibility issues – semantic information model • Design • Implementation

215

• Operation • Each phase is iterated until the expected model is obtained • All phases use Ada-based OO techniques: Analysis, Design, Coding 621

Software Development Methodology Prefer “composition” to “generalization/inheritance” because: • timing constraints are more controllable with composition • behaviour inheritance (required for real-time) was not mature in 1995 (and still isn’t) • hard to systematize class hierarchy identification process • Ada does not support inheritance 622

Requirements Analysis Phase • Client’s requirements gathered in textual form • Experts in each domain interviewed: radio frequency, microwave, operations, . . . .

• Ward/Mellor Real-Time Structured Analysis (RT/SA) applied to obtain Environment Model • Environment Model consists of a context diagram and an event list • For each input event, Functional Flow and Data Transform (FFDT) methodology applied (an FFDT chart is roughly equivalent to a “use case”) 623

Requirements Analysis Phase • Shlaer-Mellor OOA methodology applied using Cadre Teamwork CASE tool, yielding: – Entity Relationship Diagram (ERD) – Object Communication Diagram (OCD) – State Transition Diagram (STD) – Data Flow Diagram (DFD) – Data Dictionary (DD) • This involves building: – an Information Model – a Communication Model – a State Model – a Process Model

216

• Translate final Requirements Model to Hatley-Pirbhai notation (MIL-STD-2167A) • Protoype the Requirements Model using Borland C++ • Use the prototype to show clients how the system operates 624

Design Phase Process: • Generate and evaluate a set of designs • Select one design • Prototype selected design in Ada • Test prototype in Target Environment • Stop when a design satisfies the requirements 625

Design Criteria • memory utilization • processing speed • maintainability • expandability • technology and risks of new technology • schedule • correctness (only factor not compromised!)

626

Software Development Methodology Methodology: • Based on Booch’s OOD methodology • high level objects assembled from component objects (bottom up) Prototyping: • each high level object mapped to an Ada task • reduce number of tasks grouping objects not required to run concurrently • represent each object as an Ada Package Specification • identify possible deadlocks, etc., and design countermeasures • code and test the programs 627

217

Implementation Phase • formal implementation, testing, and integration of selected design • perform McCabe complexity analysis on final source code • construct a Software Test Description (STD) from the Software Requirements Specification (SRS) =⇒ • all requirements verified without knowledge of implementation details • conduct formal/informal reviews with/without clients 628

Metrics PCAS code size RAM Ada tasks Subroutines FQT test cases Analysis phase Implementation phase Testing Designs Integration defects Requirements defects

10,150 semicolons 192K words available; 105K words used 11 278 151 17 months 10 months 6 person-months 7 16 1 629

Lessons Learned • Some drawbacks of Shlaer-Mellor methodology identified • OOA methodology was simple and straightforward • Object identification was systematic (because SA and FFDT are well-understood, mature methodologies) • Cadre Teamwork modelling notation for OOA facilitated client/developer communication • Design process produced a high quality design • Ada provided a close mapping between design constructs and final code • Phase transitions were smooth • Clients attended most code walkthroughs and structured inspections — few surprises!

630

218

36 The Ariane 5 Rocket On 4 June 1996, an Ariane 5 rocket was launched for the first time. About 30 seconds after lift-off, at an altitude of 3700 metres, the rocket went off course, broke up, and exploded. The cost of the accident was approximately $500 million.

The Ariane 5 Rocket • European Space Agency build a series of rockets: Ariane N • 4 June 1996: first Ariane 5 rocket launched • 30 seconds after lift-off, at 3700 metres, rocket went off-course and self-destructed • Cost of accident: about $500 million 631

The Ariane 5 Rocket

632 The problem was a software error in the Inertial Reference System (SRI). Computations are performed to align the SRI and should be completed 9 seconds before lift-off. However, the computation is allowed to continue for the first 50 seconds of the flight so that, in the event of a short delay, the launch does not have to be cancelled because the SRI is not ready (it takes several hours to reset).

The Ariane 5 Rocket • Cause: software error in the Inertial Reference System (SRI) • SRI takes several hours to initialize • Alignment computations are completed 9 seconds before lift-off

219

• Computation is allowed to continue until 50 seconds after lift-off • This avoids cancellation of a launch because SRI is not ready 633

The Ariane 5 Rocket • SRI computation includes 7 conversions in which a 64-bit quantity is moved to a 16-bit word • If the stored value requires more than 16 bits, an exception is raised • Exceptions must be handled • Formal analysis showed that exception handlers were required for 4 cases out of 7 • Requirements state that if an unhandled exception occurs, the control computer shuts down and the mission is aborted • Ariane 5 failed because one of the 3 unchecked conversions failed 634

The Ariane 5 Rocket • The SRI code was written for the Ariane 4 rocket • It was correct for Ariane 4 trajectories • Ariane 4: 113 successful launches between 15 June 1988 and 15 February 2003 • The SRI code was reused for Ariane 5 635

The Ariane 5 Rocket A possible sequence of events: • engineering analysis for the Ariane 4 showed that overflow could not occur • the conversion was deliberately left unchecked • the requirements for Ariane 4 were transferred to the Ariane 5 without further analysis • The system was tested against Ariane 4 IRS requirements and Ariane 5 Flight Control System (FCS) requirements.

• There was no integrated testing (IRS-FCS).

636

220

The Ariane 5 Rocket • Much discussion; many opinions • Jèzèquel and Meyer: – A programming language that forced explicit error handling for all data errors – If an error can be shown not to occur, the programmer would still have to code “no action” explicitly – Code inspection would have detected unsafe “no action” handlers – Subtext: use DBC and EIffel!

637

The Ariane 5 Rocket • Garlington: With respect to the Ariane 5 accident, the final report summary states that the development team deliberately avoided use of the available language feature that could have been used to protect the code; thus, it does not seem fair to blame the language in this case.

• Baber: The strict precondition of any data conversion routine must include range guards. Lack of attention to the strict preconditions was the direct cause of the destruction of the Ariane 5 and its payload.

638

The Ariane 5 Rocket • Subsequent studies used information omitted from the original report • Analysis by Peter Ladkin • Fault occurred in the “quick alignment function” (QAF) • QAF avoids recomputation if a launch is cancelled during T − 9 to T − 5 • Ariane 5 launches are automatically cancelled if a problem arises during T − 9 to T − 5 • QAF therefore serves no purpose in the Ariane 5 • This was not known when SRI requirements for Ariane 5 were written • QAF was needed for Ariane 4 and was used once 639

221

The Ariane 5 Rocket • Original version: mechanical gyro, SRI written in assembler • Upgraded for Ariane 4: ring-laser gyro, SRI written in Ada83 • Failing process not actually needed for ring-laser gyro • Failure was due to systems engineering, not software engineering • QAF was included in Ariane 5 because software was reused (or re-implemented) • System requirements analysis would have showed that QAF was redundant 640

The Ariane 5 Rocket Conclusion (Colin O’Halloran): It is reasonable to suggest that as a precautionary measure any functionality that served no purpose on Ariane 5 should have been switched off for that configuration of use. However, it is not clear that at that stage in the A5 programme that they could have anticipated that the QAF would not be useful design decisions made later might have led to the redundancy in the requirement for quick alignment.

641

The Ariane 5 Rocket • a JPL study of safety-critical systems concluded that 90% of failures are due to requirements errors • avoid such errors by fixing the requirements process and including integrated testing • Good practice includes explicit documentation of data range assumptions • A few programming languages provide this; most don’t.

• Where an exception can occur, and a handler is not provided, the documentation should say explicitly “no handler” and, preferably, explain why.

• A code inspection would then reveal potential problems of the Ariane kind.

642

The Ariane 5 Rocket Links: http://en.wikisource.org/wiki/Ariane_501_Inquiry_Board_report http://www.comp.lancs.ac.uk/computing/resources/IanS/SE6/CaseStudies/Ariane5/Ladkin-Ariane5. html http://www.rvs.uni-bielefeld.de/publications/compendium/incidents_and_accidents/ariane5. html 643

222

37 Software Measurement Software Measurement Early days: • Software size = Lines Of Code (LOC) • Refined to Source Lines of Code (SLOC) — excludes white space, comments, etc.

• Also: – DLOC — Delivered Lines Of Code – KLOC — Thousand Lines Of Code – etc.

644

Software Science • Halstead, 1976: First attempt to provide a theory of software measurement • If X is a true value, X̂ is an estimator for that value • Definitions: η1

= number of unique operators

η2 = number of unique operands N̂ = length estimator = η1 log2 η1 + η2 log2 η2 • Cf. Information theory: entropy = −p log p 645

Software Science • Volumes: V

= =

program volume number of mental comparisons needed for software size N

= N log2(η1 + η2) V ∗ = most compact volume = (2 + ηo) log2(2 + ηo) in which ηo is the number of conceptually unique inputs and outputs of a procedure • Level L = programming language level V∗ = V • A large value of L (higher level language) indicates less difficulty for a given algorithm 646

223

Software Cyclomatic Complexity • Measure number of decisions (MacCabe, 1977) • Based on cyclomatic number of a directed graph: CN (G) = E − N + 2 E N

= number of edges = number of nodes

• To obtain cyclomatic complexity of a component: 1. draw the flow chart of the component 2. measure CN (G) as above • Cyclomatic complexity is additive: – if components Ci have cyclomatic complexity ci, – then the cyclomatic complexity of the system is

Σ

ci 647

Other measures • Reachability: based on number of paths in flowchart • Nesting levels: how deeply control structures are nested • Entropy: based on information theory • Metrics for object-oriented code: – weighted methods per class – depth of inheritance – number of subclasses – lack of cohesion – coupling between classes – response for a class 648

Summary • most metrics seem rather dated (not object-oriented!)

• formulas seem arbitrary, but may have a sound basis • metrics correlate moderately well • LOC is easy to measure and correlates with other measures • metrics based on code enable measurement of existing software but do not help with prediction 649

224

Function Points • Original idea: Albrecht, 1979 (IBM) • Refinements: – Albrecht and Gaffney, 1983 – Garmus and Herron, 1995 • Count: – external inputs – external outputs – user inquiries – external files – internal files 650

Function Points • weight according to complexity: Item External input External output User inquiry External file Internal file

Simple 3 4 3 7 5

Average 4 5 4 10 7

Complex 6 7 6 15 10 651

Function Points • Function point calculation: FP = UFC × TCF Σ UFC = Wk Ik i

TCF = 0.65 + 0.1

Σ

Fi

i

where Ik

= an item

Wk

= weight of the item

Fi

= is a “detail factor” 652

225

Summary • FPs require a complete software specification • FPs tend to underestimate actual difficulties, especially for unusual applications • Measurement is subjective • FPs are best for old-style, information-processing, batch-oriented programs • Ignores developments in software development tools • Recent versions introduce measures for more modern software 653

38 COCOMO COCOMO • COCOMO (COnstructive COst MOdel) is a system for estimating software costs • originally described by Barry Boehm in 1981 (Software Engineering Economics, Prentice Hall) • extensively refined since then • uses FPs • intended to predict, not just measure • the current version is called COCOMO II • more information and an implementation at http://sunset.usc.edu/csse/research/COCOMOII/ cocomo_main.html 654

COCOMO • Simplest form, Basic COCOMO, is based on the formula E

=

bSc

in which E = effort S = estimated size (e.g., KLOC, FP) b, c = constants depending on kind of project 655

226

COCOMO • An organic project is developed by a small, experienced team working in a familiar environment.

• An embedded project is part of a system with a highly constrained environment, such as air traffic control, that is developed by an experienced team.

• A semidetached project is intermediate between organic and embedded.

Project type b organic 2.4 semidetached 3.0 embedded 3.6

c 1.05 1.12 1.20 656

COCOMO Effort for projects of various sizes: KLOC 1 10 100 1000

organic 2.4 26.9 302.1 3390.0

semidetached 3.0 39.6 521.3 6872.0

embedded 3.6 57.1 904.2 14333.0 657

COCOMO • Intermediate COCOMO takes into account a number of factors other than the kind of project and the number of lines of code • based on fifteen or so attributes called cost drivers • cost drivers are assumed to affect productivity and hence costs • COCOMO model defines a set of factors for each cost driver • Example cost driver: Driver Complexity

very low 0.70

low 0.85

nominal 1.00

high 1.15

very high 1.30

extra high 1.65 658

227

COCOMO Some other cost drivers: • Product attributes – reliability required – database size – product complexity • Computer attributes: – execution time constraints – main storage constraints – virtual machine volatility – computer turnaround time 659

COCOMO Some other cost drivers: • Personnel attributes: – analyst capability – applications experience – programmer capability – virtual machine experience – programming language experience • Project attributes: – use of modern programming techniques – use of software tools – required development schedule 660

COCOMO The basic formula becomes E

= bSc m(X)

where X is a vector derived from the cost drivers and m is a weighting function.

228

661

COCOMO Effort Estimation Equation (from first page of COCOMO Manual): Y 17

PM =

EMi · A ·

i=1

1+

REVL 100

B

· Size

+

ASLOC · AT 100 ATPROD

100 − AT · 100 AA + SU + 0.4 DM + 0.3 CM + 0.3 JM 100 5 Σ = 0.91 + 0.01 SFj

size = KNSLOC + KASLOC ·

B

j=1

662

COCOMO • Must choose values for all cost drivers • E.g., personnel experience: Experience Extra low Very low Low Nominal High Very high Extra high

months less than 3 3 to 5 5 to 9 9 to 12 12 to 24 24 to 48 more than 48

weight 1.29 1.29 1.13 1.00 0.91 0.82 0.82 663

COCOMO • Detailed COCOMO uses the same cost drivers but splits them up according to development phases or stages • During the first stage, application composition, complexity is measured in object points • During the second stage, early design, complexity is measured in function points • During the last stage, postarchitecture, complexity is measured in LOCs 664

COCOMO • COCOMO uses Function Points and Object Points • An object point:

229

– has nothing to do with object oriented programming – is a screen (or window in modern systems), a report, or a software component (usually a function or procedure) – is a simplified form of function point 665

COCOMO: Summary • Detailed, but potentially fairly accurate estimation tool • Doesn’t make much sense for an individual project • A company can record results for projects and adjust parameters • After completing a few similar projects, estimation can be quite good • You can try it for yourself, but do not expect meaningful results 666

39 The Software Crisis The Software Crisis • Friedrich Bauer first used the term “software crisis” • NATO Software Engineering Conference, Garmisch, 1968 http://homepages.cs.ncl.ac.uk/ brian.randell/NATO/NATOReports/index.html • “software engineering” originated at the same time 667

Peter Naur, 1968

230

668

What was the “software crisis”?

Dijkstra (Turing Award Lecture, 1972): The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.

669 Gigantic computer, c. 1972

670

What was the “software crisis”?

Observations: • Projects running over-budget • Projects running over-time • Software was very inefficient • Software was of low quality • Software often did not meet requirements • Projects were unmanageable and code difficult to maintain • Software was never delivered Source:

http://en.wikipedia.org/wiki/Software_crisis

231

671

Consequences of the “software crisis” • Spawned a research industry • Many papers begin: The problem is well-known: there is a software crisis. In this paper, we describe our solution to the software crisis . . . .

672

The Chaos Report Report entitled “CHAOS” released by The Standish Group in 1995 In the United States, we spend more than $250 billion each year on IT application development of approximately 175,000 projects. . . . A great many of these projects will fail. Software development projects are in chaos, and we can no longer imitate the three monkeys – hear no failures, see no failures, speak no failures.

The Standish Group research shows a staggering 31.1% of projects will be cancelled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates.

673

The Chaos Report One just has to look to the City of Denver to realize the extent of this problem. The failure to produce reliable software to handle baggage at the new Denver airport is costing the city $1.1 million per day.

Based on this research, The Standish Group estimates that in 1995 American companies and government agencies will spend $81 billion for cancelled software projects. These same organizations will pay an additional $59 billion for software projects that will be completed, but will exceed their original time estimates.

On the success side, the average is only 16.2% for software projects that are completed ontime and on-budget. In the larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget.

674

The Chaos Report

232

675

Consequences of the “Chaos Report” • Spawned a research industry • Many papers begin: The problem is well-known: as reports by the Standish Group have shown, there is a software crisis. In this paper, we describe our solution to the software crisis . . . .

• Cost of the Standish Report at Amazon.com: $999.00 • How many researchers actually read it?

• Now available free: www.projectsmart.co.uk/docs/chaos-report.pdf 676

Chaos Refuted • http://www.guerrillaprojectmanagement.com/the-chaos-report-myth-busters • The Rise and Fall of the Chaos Report Figures J. Eveleens and C. Verhoef IEEE Software Magazine, Jan/Feb 2010 677

We applied the Standish definitions to our extensive data consisting of 5,457 forecasts of 1,211 real-world projects totaling hundreds of millions of euros. Our research shows that the Standish definitions of successful and challenged projects have four major problems: they’re misleading, one-sided, pervert the estimation practice, and result in meaningless figures.

233

These case studies show that the Standish figures for individual organizations don’t reflect reality and are highly influenced by forecasting biases. Because the underlying data has an unknown bias, any aggregation of that data is unreliable and meaningless.

678

Chaos Refuted By ignoring the potential bias and forecasting quality, the figures of the Standish Group don’t adequately indicate what, according to their definitions, constitutes a successful or challenged project. Some organizations tend to overestimate while others underestimate, so their success and challenge rates are meaningless because Standish doesn’t account for these clearly present biases.

679

Chaos Refuted

680

Chaos Refuted

234

681

Is there a Software Crisis?

YES!

• It is easy to find examples of software projects that went wrong • Large amounts of money are (mis)spent — particularly by governments • There are many ways in which software development processes can be improved • Many small companies still do not use effective processes • $51,000,000,000 losses due to software piracy • $15,000,000,000 losses due to malware: http://www.computereconomics.com/article.cfm? id=1225 682

Malware Crisis

683

235

Is there a Software Crisis?

NO!

• Hardware and software have improved enormously since 1968 • During 1990–2010: – processors improved by a factor of 1,000 – algorithms improved by a factor of 43,000 – computation overall by a factor of 43,000,000 Source: http://bits.blogs.nytimes.com/2011/03/07/software-progress-beats-moores-law/ • We expect far more of computers now than in the past • Society is far more heavily dependent on computers than in the past 684

Is there a Software Crisis?

YES!

• 1970s: US DoD perspective • More than 500 programming languages in use • Many obsolete or hardware dependent • None supported safe modular programming • Big cost overruns on software projects • Delivered software unmaintainable • 1975: High Order Language Working Group (HOLWG) formed • 1980: Ada specified (Jean Ichbiah, CII Honeywell Bull) • 1987–97: DoD mandated Ada 685

Ada • Designed for military contracts • Increasingly used for civil applications • Recent Ada projects: – USA: Boeing 777 “fly-by-wire” system software – Canada: Automated Air Traffic System (106 Ada SLOC) – UK: air traffic control system: Future Area Control Tools Support (iFACTS) – France: TVM in-cab signalling system on the TGV 686

236

40 CMM Watts Humphrey, 1927–2010

687

Watts Humphrey • Worked at IBM 1959–86 • Started Software Process Program at Software Engineering Institute • Led to Capability Maturity Model (CMM) 1987–97 • Evolved to Capability Maturity Model Integration (CMMI) 2002– • Developed: – Personal Software Process (PSP) – Team Software Process (TSP) 688

Software Engineering Institute (SEI) From http://www.sei.cmu.edu/about/statisticshistory.cfm: • 1984: established as part of Carnegie Mellon University (Pittsburgh) by US DoD • 1987: “SEI publishes the first technical reports describing the Capability Maturity Model (CMM) for Software and a methodology for assessing the process maturity of defense contractors” • 1988: “SEI creates the first computer emergency response team after an Internet worm cripples 10% of computers on the Internet”

237

• 1991: “SEI publishes version 1.0 of the CMM for Software (SW-CMM). More than 30,000 people are eventually trained in the principles and techniques of CMM, and more than 2,400 organizations are assessed on the five-level CMM scale. The SW-CMM is upgraded to CMM Integration (CMMI) in 2000.”

689

CMM • Idea: a software development company can obtain certification at Level 1, 2, 3, 4, or 5 • Companies usually move up levels, one step at a time • Original goal: to obtain government contracts, companies Had to obtain certification at a specified level • Goal: CMM certification is useful for any company looking for software contracts • Most appropriate for larger companies 690

CMM Structure • Maturity Levels: a 5-level process maturity continuum - where the uppermost (5th) level is a notional ideal state where processes would be systematically managed by a combination of process optimization and continuous process improvement.

• Key Process Areas: a Key Process Area (KPA) identifies a cluster of related activities that, when performed together, achieve a set of goals considered important.

• Goals: the goals of a key process area summarize the states that must exist for that key process area to have been implemented in an effective and lasting way. The extent to which the goals have been accomplished is an indicator of how much capability the organization has established at that maturity level. The goals signify the scope, boundaries, and intent of each key process area.

691

CMM Structure • Common Features: common features include practices that implement and institutionalize a key process area. There are five types of common features: commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation.

• Key Practices: The key practices describe the elements of infrastructure and practice that contribute most effectively to the implementation and institutionalization of the KPAs. 692

238

CMM Levels 1. Initial: processes undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. Chaotic or unstable environment.

2. Repeatable: some processes are repeatable, possibly with consistent results. Process discipline is not rigorous.

3. Defined: sets of defined and documented standard processes established and subject to some degree of improvement over time.

4. Managed: processes effectively controlled using process metrics. Possible to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications.

5. Optimizing: continual improvement of process performance through incremental and innovative technological changes.

693

CMM Levels (Wikimedia)

694

CMMI — KPAs • Each maturity level is characterized by Key Process Areas (KPAs) • Each KPA defines: 1. Goals 2. Commitment 3. Ability 4. Measurement 5. Verification 695 239

CMMI — KPAs • Process Management – Organizational Process Focus – Organizational Process Definition – Organizational Training – Organizational Process Performance – Organizational Innovation and Deployment • Project Management – Project Planning – Project Monitoring and Control – Supplier Agreement Management – Integrated Project Management for IPPD – Risk Management – Integrated Teaming – Integrated Supplier Management – Quantitative Project Management 696

CMMI — KPAs • Engineering – Requirements Management – Requirements Development – Technical Solution – Product Integration – Verification – Validation • Support – Configuration Management – Process and Product Quality Assurance – Measurement and Analysis – Decision Analysis and Resolution – Organizational Environment for Integration – Causal Analysis and Resolution 697

240

Achieving CMMI compliance • establish: – an Engineering Process Group (EPG) – Process Action Teams (PATs) • members of the EPG and PATs must be trained in the CMMI • perform informal appraisal (SCAMPI C) • prioritize process areas for improvement • SEI qualified team performs formal appraisal (SCAMPI A) 698

Achieving CMMI compliance Standard CMMI Appraisal Method for Process Improvement (SCAMPI) SCAMPI A enables a sponsor to • gain insight into an organization’s capability by identifying the strengths and weaknesses of its current processes • relate these strengths and weaknesses to the CMMI reference model(s) • prioritize improvement plans • focus on improvements (correct weaknesses that generate risks) that are most beneficial to the organization given its current level of organizational maturity or process capabilities • derive capability level ratings as well as a maturity level rating • identify development/acquisition risks relative to capability/maturity determinations 699

Achieving CMMI compliance • SCAMPI: http://en.wikipedia.org/wiki/SCAMPI • Published appraisal results:

http://sas.sei.cmu.edu/pars/pars.aspx 700

241

CMM — Results • High CMM levels lead to good performance • Slow: – 1.5 – 2.0 years pers tep – at least 10 years to get to Level 5 • Expensive: typically $ millions spent on process improvement • Worthwhile: savings eventually exceed costs (usually) 701

CMM — Results • Project failure in a CMM Level 5 company Measure Total effort (person/months) Duration (days)

Estimate 37.5 50

Actual 66.5 222

Deviation 177% 434%

• Reasons: – new type of application – new architecture and development platform – unforeseen complexity – unforeseen limitation of reusable components – lack of experience with new methods – distribution of tasks to remote locations 702

CMM — Results Description of failed project: Type Size Technology Tools Process

Web-based software for a call centre 60 KSLOC PHP and Javascript 1 KSLOC Java 57 KSLOC Java (reused) Java, PHP, CSS, Javascript Eclipse Incremental, Scrum 703

242

41 97 Things 97 Things

704

97 Things • 97 Things Every Programmer Should Know Kevlin Henney (Editor) O’Reilly, 2010 • http://programmer.97things.oreilly.com/wiki/index.php/97_Things_Every_Programmer_ Should_Know • Also: – 97 Things Every Software Architect Should Know Edited by Richard Monson-Haefel – 97 Things Every Project Manager Should Know Edited by Barbee Davis 705

97 Things Giles Colbourne: Ask “What Would the User do?” (You Are not the User) • We assume that others think like us, but they don’t • In particular, programmers and users think differently • To find out how users think, watch them • Give them a real task E.g., Calculate your expenses for the last month • Users get stuck, narrow their focus, muddle through • There’s a gap between what users want and what they do • Capture requirements by watching users 706

243

97 Things Filip van Laenen: Automate Your Coding Standard • Coding Standards often fail: – good intentions are abandoned under pressure – programmers forget, don’t see the point, are not told, . . .

– coding according to standards is boring – programmers are rebellious • Good reasons to have standards: e.g., programmers can’t “own” code • Solution: enforce standard by automating it: – include source code formatting in the build process – use static analysis to scan for antipatterns • Coding standard should be dynamic: let it evolve with the project 707

97 Things Jørn Ølmheim: Beauty is in Simplicity Beauty of style and harmony and grace and good rhythm depends on simplicity.

Plato

• We strive for: readability, maintainability, speed of development, beauty • Simplicity enables all of these • If you haven’t read other people’s code ...........do so right now!

• Beautiful code is simple code • Beauty is born of and found in simplicity 708

97 Things Dan North: Code in the Language of the Domain Compare: if (portfolioIdsByTraderId.get(trader.getId()) .containsKey(portfolio.getId())) {...} and: if (trader.canView(portfolio)) {...} • Which of these codebases would you rather be working in?

• Older languages had only built-in types

244

• Newer languages have user-defined types (and classes) • Use them to code in the language of the domain • The programmer who comes along a few months later to work on the code will thank you • The programmer who comes along a few months later might be you 709

97 Things Kevlin Henney: Comment Only What the Code Cannot Say • In theory, commenting is a good idea • In practice, comments can become a blight • Skill is required to write good comments • Skill is required to know when not to write comments • Bad comments provide a source of distraction and misinformation • A few bad comments encourage maintainers to ignore all comments • Comment what the code cannot say, not simply what it does not say 710

97 Things Gregor Hohpe: Convenience is not an -ility • APIs: difficult to get right the first time; difficult to change later • API designer “insights”: – I don’t want other classes to have to make two separate calls to do this one thing.

– Why should I make another method if it’s almost the same as this method? I’ll just add a simple switch.

– If the second string parameter ends with ".txt", the method automatically assumes that the first parameter is a file name, so I really don’t need two methods.

• Result: parser.processNodes(text, false) • Design for the convenience of the caller, not the implementor • A good API should define an expressive language • English does not have one word for MakeUpYourRoomBeQuietAndDoYourHomeWork even though it would be convenient 711

245

97 Things Dan Bergh Johnsson: Distinguish Business Exceptions from Technical • Two things that can go wrong: – technical problems prevent us from using the application – business logic that prevents us from misusing the application • Both problems can be handled by exceptions • Use a separate exception hierarchy for each one • Technical problems should be handled by the application framework • Business domain exceptions are handled by client code 712

97 Things Steve Smith: Don’t Repeat Yourself (DRY) • “Of all the principles of programming, (DRY) is perhaps one of the most fundamental.”

• Duplication is waste • Repetition in process calls for automation • Repetition in logic calls for abstractio • A Matter of principle – Once and Only Once Principle – Open/Closed Principle (“software entities should be open for extension, but closed for modification”) – Single Responsibility Principle (“only one reason to change”) 713

97 Things Udi Dahan: Beware the Share • Dahan’s first project: maximize reuse; eliminate duplicate code • Code review: wrong!

• What had Dahan missed? — context • Different components performing similar computation does not mean much • Eliminating duplicate code increased coupling, complicated maintenance • Fewer SLOC, more dependencies • Reuse is good — but only in the right context 714

246

97 Things Einar Landre: Encapsulate Behavior, not Just State • Classes are the hardest encapsulation constructs to get right • Classes with one 3KLOC method, with only get() and set() methods, . . .

• An object encapsulates state and behaviour • Three classes (with roles): – Customer (credit limit, credit validation) – Order (customer, addItem) – Item • May fail: customer.validateCredit(item.price()) • Mistake: make one class OrderManager with all business logic in one class • Result: error-prone, unmaintainable • Don’t break encapsulation: use your language to enforce it 715

97 Things Olve Maudal: Hard Work Does not Pay Off • If you are trying to be focused and ‘productive’ for more than 30 hours a week you are probably working too hard • Software development is a continuous learning process • To avoid wasted work, you must allow time to observe the effects of what you are doing, reflect over the things that you see, and change your behaviour accordingly • Avoid embarrassing yourself, and our profession, by behaving like a hamster in a cage spinning the wheel • As a professional programmer you should know that trying to be focused and ‘productive’ 60 hours a week is not a sensible thing to do • Act like a professional: prepare, effect, observe, reflect, and change 716

247

97 Things Johannes Brodwall: Keep the Build Clean • Have you ever looked at a long list of compiler warnings and thought: “I really should do something about that . . . but I don’t have time just now?”

• Have you ever looked at one warning and just fixed it?

• To make warnings useful again, I try to use a zero-tolerance policy for warnings from the build.

• Even if the warning isn’t important, I deal with it.

• By making sure that the build is always clean, I will not have to decide that a warning is irrelevant every time I encounter it.

• Warnings from your build are useful.

• You just need to get rid of the noise to start noticing them.

717

97 Things Peter Sommerlad: Only the Code Tells the Truth • The ultimate semantics of a program is given by the running code.

• Looking at the source code, the meaning of the program should be apparent.

• A design document may capture a planned design, but it will lack the necessary detail of the implementation.

• These documents may have lost sync with the current implementation . . . or may simply have been lost.

• Or never written in the first place.

• The source code may be the only thing left.

• Establish some sanity in the code and keep your own sanity.

718

97 Things Uncle Bob: The Single Responsibility Principle • Gather together those things that change for the same reason, and separate those things that change for different reasons.

• Careful application of the SRP, separating things that change for different reasons, is one if the keys to creating designs that have an independently deployable component structure.

719

248

97 Things Uncle Bob (continued) • Wrong (functions change for different reasons): public class Employee { public Money calculatePay() ... public String reportHours() ... public void save() ... } • Right (each class changes for just one reason): public class Employee { public Money calculatePay() ... } public class EmployeeReporter { public String reportHours(Employee e) ... } public class EmployeeRepository { public void save(Employee e) ... } 720

97 Things Gerard Meszaros: Write Tests for People • You are writing automated tests for some or all of your production code. Congratulations!

• You are writing your tests before you write the code? Even better!!

• But are you writing good tests?

• For each scenario, the tests: 1. describe the context, starting point, or preconditions that must be satisfied 2. illustrate how the software is invoked 3. describe the expected results or postconditions to be verified • Each test should clearly illustrate the cause and effect relationship between these three parts.

• Your tests should speak clearly to a person trying to understand your code.

721

97 Things Pete Goodliffe: You Gotta Care about the Code • you refuse to hack something that only seems to work.

• you write code that is discoverable, maintainable, and clearly correct

249

• you work well alongside other programmers • you want the team to write the best software possible, rather than to make yourself look clever • any time you touch a piece of code you strive to leave it better than you found it • since you care about code and about programming, you are constantly learning new languages, idioms, and techniques . . . but you only apply them when appropriate.

722

97 Things Nate Jackson: Your Customers Do not Mean What They Say • I’ve never met a customer yet that wasn’t all too happy to tell me what they wanted — usually in great detail.

• The problem is that customers don’t always tell you the whole truth.

• They generally don’t lie, but they speak in customer speak, not developer speak.

• They use their terms and their contexts.

• They leave out significant details.

• They make assumptions that you’ve been at their company for 20 years, just like they have.

• This is compounded by the fact that many customers don’t actually know what they want in the first place!

723

97 Things Nate Jackson (continued) • In a past life, I was a “multimedia programmer” on a team who produced glitzy projects.

• A client of ours described her thoughts on the look and feel of the project in great detail.

• The general color scheme discussed in the design meetings indicated a black background for the presentation.

• Teams of graphic designers began churning out hundreds of layered graphics files.

• When the client saw the product, her exact words about the background color were When I said black, I meant white • So, you see, it is never as clear as black and white.

724

250

42 Beautiful Architecture Beautiful Architecture The following slides are based on: Beautiful Architecture Diomedis Spinellis and Georgios Goustos (editors) O’Reilly, 2009

42.1

A Tale of Two Systems

We start with: A Tale of Two Systems: a Modern Day Software Fable Pete Goodliffe 725

A Tale of Two Systems A comparison of two systems with common features: • similar size — around 500 KSLoC • both “embedded” consumer audio appliances • both software ecosystems were mature and had gone through many product releases • both Linux-based • both written in C++ • both developed by “experienced” programmers who should have known better • programmers were the architects 726

System 1: the Messy Metropolis • early difficulties • code fantastically hard to learn • no consistency, no style, no unifying concepts • many “bad smells” • no one could explain the structure • need a map: reverse engineer the architecture 727

251

System 1: the Messy Metropolis The architecture: “It was stunning. It was psychedelic. It was as if a drunk spider had stumbled into a few pots of poster paint and then spun a chromatic web across a piece of paper. ......... Then it all became clear: we had drawn a map of the London Underground.”

728

System 1: the Messy Metropolis

729

System 1: the Messy Metropolis • situation was understandable (but not condonable) • startup company • pressure to get many releases out quickly • delays not tolerated because they would lead to financial ruin • code thrown together in “mad dashes” Lesson Your company structure and unhealthy development processes will be reflected in poor software architecture.

730

252

System 1: the Messy Metropolis Incomprehensibility: • difficult to comprehend • practically impossible to modify • recent hires unable to grasp what was going on • bad design encouraged further bad design to be “bolted on” • easier to add than extend — these words are not synonymous Lesson It is important to maintain the quality of a software design. Bad design leads to further bad design.

731

System 1: the Messy Metropolis Lack of cohesion: • components not cohesive • each component had a grab-bag of unrelated functionality • hard to decide why some components existed at all • hard to find where particular functionality was located • personality struggles led programmers to build their own “software empires” Lesson The health of the working relationships in your team will feed directly into the design. Unhealthy relationships and inflated egos lead to unhealthy software.

732

System 1: the Messy Metropolis Unnecessary coupling: • no layering • dependencies not unidirectional • no bottom layer or “hub” — code was a “monolithic blob” • impossible to bring up a skeletal system — all components needed • changes rippled across system • low-level testing impossible Lesson Good design takes into account connection mechanisms and the number of connections between components. Individual parts must be able to stand alone. Tight coupling leads to untestable code.

733

253

System 1: the Messy Metropolis Code problems: • no common style, idioms, libraries • no naming conventions • no integrated build system • compiling was considered a “rite of passage” • extensive code duplication • reason: prototypes tacked together instead of being thrown away Lesson A lax and fuzzy architecture leads to components that are badly written and don’t fit well together, and to duplication of code and effort.

734

System 1: the Messy Metropolis Problems outside the code: • new hires confused (see above) =⇒ high turnover • people who stayed had to work very hard =⇒ high stress levels • planning new features “instilled a dread fear” • simple changes took a long time • release cycle cumbersome and slow =⇒ impatient customers • product support engineers had an “awful time” 735

System 1: the Messy Metropolis • external control protocol: – a “thin veneer over the guts of the software” – baroque, hard to understand, prone to random failure, impossible to use – made third-party engineers “miserable” • intra-company politics: – friction between different “tribes” – strained relations between development and marketing/sales – manufacturing department stressed at every release Lesson The consequence of a bad architecture is not constrained within the code. It spills outside to affect people, teams, processes, and timescales.

736

254

System 1: the Messy Metropolis Requirements: • the team did not know what it was building • company had an idea of the market . . .

• . . . but didn’t know the kind of product needed • so they asked for software that could do “many things” . . .

• . . . by yesterday Lesson It is important to know what you’re designing before you start designing it. If you don’t know what it is and what it’s supposed to do, don’t design it yet.

737

System 1: the Messy Metropolis Where is it now?

• design completely irredeemable • reworking, refactoring, correcting prohibitively expensive • new features implemented as “kludges, band-aids, calculated fudges” • bad code, bad morale, endless development cycles • all software thrown away 738

System 1: the Messy Metropolis Conclusion: lack of foresight and poor architecture led to: • low-quality produce with infrequent releases • inflexible system that could not accommodate change • pervasive code problems • staffing problems • messy internal politics • lack of success for the company 739

255

System 2: Design Town Background: • new team of four capable developers • started from scratch • team members had not met before this project • used XP 740

System 2: Design Town Early steps: • establish functionality: audio path, content management, user interface • simple initial architecture: User interface Control components Audio path OS/Audio Codecs • Audio path: pipes and filters

741

System 2: Design Town Decisions made: • which libraries to use (Boost and database) • top-level file structure • how to name things • “house style” for presentations • common coding idioms • unit test framework • infrastructure: source control, build system, continuous integration 742

256

System 2: Design Town Locating functionality: • new code added according to functionality • no questions about where code belonged • easy to find existing functionality • put code in the “right” place rather than a “convenient” place • this makes things easier later on Lesson A good architecture helps you to locate functionality: to add it, modify it, or to fix it.

743

System 2: Design Town Consistency: • entire system consistent • every decision taken in the context of the whole design • code matched design • code matched previously-written code • good taste at high levels led to uniform and neat code at lower levels Lesson A clear architectural design leads to a consistent system. All decisions should be made in the context of the architectural design.

Lesson Clear architecture helps reduce duplication of functionality.

744

System 2: Design Town Growing the architecture: • new functional areas appeared: storage management and external control • design was malleable and refactorable • code principle: “stay nimble” • keep designs simple and easy to change • maintain good structure

257

Lesson Architecture is not set in stone. Change it if you need to. To be changeable, the architecture must be simple. Resist introducing complexity.

745

System 2: Design Town Deferring design decisions: • YAGNI principle: You Aren’t Going To Need It • design only the important stuff early on • defer decisions for as long as possible (but not longer) • don’t design what you don’t understand • don’t add things that you might need Lesson Defer design decisions until you have to make them. Don’t make decision when you don’t know the requirements. Don’t guess.

746

System 2: Design Town Quality control: • pair programming • code/design reviews • unit tests for all code • reject anything that doesn’t integrate cleanly • believe in the design Lesson Architectural quality must be maintained. Developers must give and take responsibility for it.

747

System 2: Design Town Testing: • everything was unit-tested (XP requirement) • allows change without worry • threading and interconnection changed radically without problems • big design changes early on, small design changes later

258

Lesson Having a good set of automated tests allows you to make fundamental architecture changes with minimal risk. It gives you “space” in which to work.

Lesson Unit testing leads to better software design. Design for testability.

748

System 2: Design Town Working with the design: • codebase large, but coherent and understandable • no complex interconnections • no weird legacy code • new hires could quickly understand the system • low staff turnover • when people work well together, code integrates cleanly 749

System 2: Design Town Where is it now?

• running successfully for three years (in 2009) • code is not perfect, but is good • maintenance continues with few problems 750

A Tale of Two Systems: Summary Good architecture comes from: • intentional up-front design • quality and experience of designers • keeping the design clearly in view • team accepts responsibility for design • no fear of changing design when necessary • making decisions at the right time • good management • hiring the right people 751

259

Digression: Latency and Bandwidth • “latency” and “bandwidth” are terms used in communication • latency is a measure of how long you might have to wait for a message • bandwidth is a measure of the rate at which you can receive data • “throughput” is another name for bandwidth • E.g., a geostationary communications may have a very large bandwidth but long latency: bandwidth = 10 Gb/s distance < all > latency = speed of light < all > ≈ 470 milliseconds • Telephone has small bandwidth but short latency 752

42.2

Architecting for Scale

Beautiful Architecture The following slides are based on: Beautiful Architecture Diomedis Spinellis and Georgios Goustos (editors) O’Reilly, 2009 Next up: Architecting for Scale Jim Waldo 753

Architecting for Scale • Problem: implementing massively multiplayer online games (MMOs) • Solution: Darkstar at Sun Microsystems Laboratories (pre Oracle) • Website state: – quiet: a few transactions a minute – busy: thousands of transactions per second • State change can occur within minutes • MMO: – possibly many transactions – most independent (no player interaction) – some dependent (involve more than one player) • “embarrassingly parallel” but interdependent sometimes 754

260

Architecting for Scale • Game culture: – PC and console games – all resources available to game – low latency – single user • MMO must combine console game performance but “enterprise” scalability • MMO requires stability and consistency of the virtual world • World of Warcraft has 12 million subscribers, several hundred thousand active at one time 755

Architecting for Scale Requirements: • need many servers • must be easy to add (or remove) servers as needed • present a simple model to games programmers unused to concurrency • game developer should “see” a single machine running a single thread • “reactive” architecture: server listens for user-generated events • response to event is a short-lived (100 milliseconds or less) task • task: – accesses and updates the virtual world – communicates with the user 756

Architecting for Scale Similarities and differences: • similar to enterprise-level architecture (J2EE, web services, . . .)

• enterprises have thin clients and need big services • but MMO have fat clients and need smaller services • so push data out to client, especially if it doesn’t change much E.g., geographic information, textures, rule sets, . . .

• keep server simple, with abstract representation of world • server does as little as possible • Real job of server: maintain shared truth of the state of the world 757

261

Architecting for Scale Data access: • enterprise architecture: – 90% accesses are read-only – most tasks read a lot of data then alter a small amount • MMO: – access a small amount of data – alter half of it or more 758

Architecting for Scale Latency: • enterprise architecture: – low latency is good but some delays are acceptable – bandwidth is sometimes important • MMO: – games must be fun; latency is the enemy of fun – aim for low latency over bandwidth 759

Architecting for Scale Managing geography: • assign different geographic areas to different servers • when client requests come, dispatch them to the appropriate server • Problem: changing the association between servers and areas is hard • Solution: shards • shards are copies of areas run on different servers • easy to add and remove shards • problem: players in different shards cannot interact with each other • Darkstar goal: on-the-fly scaling independently of game logic 760

262

Architecting for Scale Darkstar architecture: • separate services available in servers • each service is defined by a small API • services allow application to: – access persistent storage – schedule and run sub-tasks – communicate with client side and virtual world • low coupling: changing one service does not affect others • amenable to open-source development 761

Architecting for Scale Architecture layers: 1. client 2. game server 3. Darkstar stack 4. Darkstar metaservices 762

Architecting for Scale • a client can connect to any server • Darkstar stacks coordinated by metaservices that: – ensure all servers running, replacing any that fail – balance load between servers – add new servers to maintain performance 763

Architecting for Scale Darkstar stack has: 1. Data service 2. Task service 3. Client session service 4. Channel service 5. Other services 764

263

Architecting for Scale Data Service: • stores, retrieves, and manipulates all persistent data • any data that outlives a single task is persistent — almost all data is persistent • unifies separate copies to maintain a single (conceptual) virtual world • all copies (appear to) access the same data • not a database: use a specialized structure 765

Architecting for Scale Task service: • schedule and perform tasks in response to events • tasks typically read data, manipulate it, and communicate • tasks can spawn other tasks • some tasks run periodically • maximum time for a task is 100 milliseconds (configurable) • many tasks run in parallel 766

Architecting for Scale Data contention: • concurrent tasks lead to data contention and inconsistencies • solution: a task is a transaction • either all operations of a task complete, or none do • communication is transactional: messages sent to client only when task commits 767

264

Architecting for Scale Session service: • mediates communication between client and server • servers listen for client message and parse to choose task • clients listen for server messages • both endpoints are hidden: no waiting for messages • order of messages must be maintained for each client 768

Architecting for Scale Channel service: • channels provide one-to-many communication • any number of client can join a channel • channel messages sent to all registered clients • messages validated to prevent cheating • client modification should be detectable • transactional semantics: messages sent only from committed tasks 769

Architecting for Scale Portability: • tasks are written in Java or can be translated to JVM bytecodes • all servers have a JVM • tasks can run on any server, even if hardware is different • metaservices allocating clients to servers provides fault-tolerance • tasks are persistent objects: if a server fails, its tasks can be passed to another server 770

265

Architecting for Scale Latency: • game folklore: keep everything in main memory to minimize latency • Darkstar: — all data is persistent and stored off-line between tasks — use modern database and caching techniques to keep latency down • side-effect: information about player interactions is available — use it to schedule interacting players on the same server • interacting players must be in the same geographical area 771

Architecting for Scale Programming Darkstar: • benefits of transactional tasks: — no locking — no synchronization — no semaphores • programmers must minimize global structures — first game used a “coordinator” — all state changes accessed the coordinator — this effectively serialized all the tasks!

— very poor performance 772

Architecting for Scale Darkstar status: • Sun Labs is no longer supporting Darkstar: http://www.projectdarkstar.com/ • Development has been taken over by the open-source Red Dwarf project: http://www.reddwarfserver.org/ •

“RedDwarf Server is a horizontally scalable application server for low latency applications such as online games, virtual worlds, and social networking applications. It is the official community fork for Project Darkstar, previously sponsored by Sun Microsystems, Inc. RedDwarf is a server side technology written in Java that radically simplifies the development of online games and lowers the barrier to entry into the MMOG market.”

773

266

42.3

Object-Oriented versus Functional

Beautiful Architecture The following slides are based on: Beautiful Architecture Diomedis Spinellis and Georgios Goustos (editors) O’Reilly, 2009 Next up: Software Architecture: Object-Oriented versus Functional Bertrand Meyer 774

Object-Oriented versus Functional Programming

Bertrand Meyer 775

Object-Oriented versus Functional Programming Bertrand Meyer: • designer of Eiffel, an early (1985) OO language • owns and manages Eiffel Software (California) • Professor of Software Engineering at ETH Zürich • has written widely on OO software techniques 776

267

Object-Oriented versus Functional Programming Functional Programming • technique of programming using only mutually recursive functions • “pure” functional programming: no side-effects • “hybrid” functional programming: side-effects allowed but minimized • 1956: LISP (McCarthy) • 1977: Scheme (Steele) • 1978: SASL and combinator reduction (Turner) • 1990: Haskell (committee) • 1996: OCaml (Leroy et al.)

777

Haskell A simple definition of factorial: fac1 n = if n < 2 then 1 else n * fac(n-1) A more idiomatic factorial: fac 0 = 1 fac n = n * fac(n-1) 778

Haskell The natural numbers: nats = from 1 where from n = n : from (n+1) The first five natural numbers: take 5 (from 1) take is defined by cases: take 0 _ = [] take _ [] = [] take n (x:xs) = x : take (n-1) xs 779

268

Haskell Primes: factor m n = mod n m == 0 nomul n = filter (not . factor n) sieve (n:ns) = n : sieve (nomul n ns) primes = sieve [2..] take 6 primes ==> [2,3,5,7,11,13] 780

Haskell type Picture = [[Char]] horse :: Picture horse = [".......##...", " ......... ##..#..", "...##. ........ #.", "..#. ............ #.", "..#...#. .... #.", "..#. .....###.#.", ".#....#..##.", "..#...#......... ", "...#...#. ...... ", "....#..#. ...... ", ".....#.#. ...... ", "......##. ....... "] 781

Haskell Reflect picture top to bottom: flipH x = reverse x flipH = reverse Reflect picture left to right: flipV = map reverse Rotate picture through 180◦: rotate = flipH . flipV 782

269

Haskell Another way of rotating: altRotate = flipV . flipH rotate and altRotate have the same effect. To prove this, we have to prove that reverse . map reverse = map reverse . reverse Two pictures with the same width can be stacked vertically: above = (++) Two pictures with the same height can be placed side by side: beside = zipWith (++) 783

Haskell Definitions of some standard functions: reverse [] = [] reverse (x:xs) = reverse xs ++ [x] map f [] = [] map f (x:xs) = f x : map xs (f . g) x = f (g x) 784

Haskell Proof that reverse .

map reverse = map reverse .

reverse:

(map reverse) . rev [] = (map reverse) (reverse []) = map reverse [] = [] = reverse [] = reverse (map reverse []) = reverse . (map reverse) [] 785

Haskell How do we get input and output? printPicture :: Picture -> IO () printPicture = putStr . concat . map (++ "\n") 786 270

Functional Programming • referential transparency =⇒ can manipulate programs algebraically • no side-effects =⇒ easy to exploit concurrency E.g., evaluate x, y, and z concurrently in f (x, y, z) • higher order functions allow combining program fragments • naive implementation is slow but serious optimization feasible • functional programming leads to good modular design • Microsoft Language Integrated Query (LINQ) incorporates many functional techniques 787

Object-Oriented versus Functional Programming Bertrand Meyer’s arguments • “Beauty” is a slogan, not an objective criterion • objective criteria: – reliability – extendibility – reusability 788

Object-Oriented versus Functional Programming Difficulties of comparison: • few data points • lack of detail • specific focus (on modularity) • experimenter bias (Meyer and OOP) 789

Object-Oriented versus Functional Programming OO side is based on Eiffel and assumes: • multiple inheritance (not in Java or C]) • genericity (recently added to Java and C]) • contracts (Eiffel only) • agents (not in Java) • no static functions or overloading (which threaten stability of OOP) 790

271

Object-Oriented versus Functional Programming • functional programming approach: – introduce T types for domain objects – introduce F operations acting on domain objects – write T × F definitions for “combinators” • To add a combinator: add F definitions, one for each operation • To add an operation: add T definitions, one for each combinator • This approach does not scale to large T and F 791

Object-Oriented versus Functional Programming Example (from a critique of OCaml [Steingold 2007]): You cannot easily modify the behaior of a module outside of it. Suppose you use a Time module defining Time.dateOfString, which parses ISO 8601 basic format ("YYYYMMDD"), but you want to recognize ISO 8601 extended format ("YYYY-MM-DD"). Tough luck: you have to get the module maintainer to edit the original function — you cannot redefine the function yourself in your module.

792

Object-Oriented versus Functional Programming Example from Finance: • European options have a single date on which the option must be exercised • American options have a range of dates for exercising the option • In Haskell, these are distinguished by type signatures: Date -> Contract -> Contract (Date, Date) -> Contract -> Contract • Haskell keeps the two kinds of contract separate • OOP would allow definition by variation: – American options are a special case of European options – Both kinds of option inherit from a common base option • Problem: FP defines concepts in terms of an implementation • OOP allows abstraction 793

272

Object-Oriented versus Functional Programming Claim for functional programming (Hughes 1998): Programs can be modularized in new ways, and thereby greatly simplified. This is the key to functional programming’s power — it allows greatly improved modularization. It is also the goal for which functional programmers must strive — smaller and simpler and more general modules, glued together with the new glues we shall describe.

794

Object-Oriented versus Functional Programming • Example of “new glue”: sqrt a0 eps n = within eps (repeat (next n) a0) √ • Explanation: find N with tolerance ϵ (eps) using a0 as the first approximation and next n to find a better approximation.

• Claim: modular because within, repeat, and next can be modified independently • Problem (Meyer): the definition within eps (a:b:tail) = if abs(a-b) <= eps then b else within eps (b:tail) assumes that differences |a − b| are decreasing and eventually |a − b| ≤ ϵ • Need preconditions, postconditions, etc. (not found in FP) 795

Object-Oriented versus Functional Programming Claimed advantages of FP: • concise notation • elegance of combinators (cf. pictures above) • ability to manipulate expressions mathematically • lazy evaluation (cf. natural numbers above) 796

Object-Oriented versus Functional Programming Concise notation: • not critical: could use FP for design, OOP for implementation • in practice, notation is more complex than simple examples suggest • programmers have difficulty with functions returning functions 797

273

Object-Oriented versus Functional Programming Elegance of combinators: • combinators hide explicit construction: above = (++) instead of new picture.makeAbove(a, b) • but OOP can do this, e.g., with “factory methods” 798

Object-Oriented versus Functional Programming Manipulation: • this is where FP has had most effect on mainstream programming • can be simulated in OOP with “agents” (functional objects) 799

Object-Oriented versus Functional Programming Lazy evaluation: • Example: repeat f a = a : repeat f (f a) produces the “infinite” list a, f (a), f (f (a)), f (f (f (a))), etc.

• elegant idea • two observations: 1. correctness: ease of writing “infinite” programs may mask subtleties of termination 2. effect of laziness can be achieved by suitable abstraction (Meyer gives an examples based on Eiffel lists) 800

Object-Oriented versus Functional Programming State: • Q: How do functional programmers change a light bulb?

• A: They don’t — they buy a new cable, a new socket, and a new bulb (and perhaps a new house) • FP models state using monads — higher order functions that pass state around implicitly • programmers have difficulty understanding and working with monads • this is not a serious objection: new generations of programmers always have to assimilate new ideas 801

274

Object-Oriented versus Functional Programming State: • simple state-changing operations (e.g., assignment) have a simple mathematical model • complex state-changing operations do not seem to be significantly simpler to reason about in FP than in OOP • referential transparency can be largely achieved without FP • Eiffel distinguishes commands and queries: queries are referentially transparent (cf. C++ const) 802

The OOP Perspective • combinators are good, types are better • contracts and genericity provide extendibility and reusability • modularize by merging types and classes • inheritance captures commonalities • polymorphism and dynamic binding permit growth • agents (“delegates” in C]) simulate functional techniques 803

Object-Oriented versus Functional Programming My opinion: • every programmer should have done some functional programming • writing functional programs improves programming ability in non-functional languages • FP is the best approach for some problems • FP techniques will be used more and more • FP will never become the mainstream of programming 804

The Future • What will become the mainstream of programming?

• Process-oriented programming (POP) • multithreaded objects lead to unmanageable complexity • processes exploit concurrency better than objects

275

• processes have lower coupling than objects You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

Joe Armstrong (Erlang) 805

276