Software EngineeringSoftware Engineering

Mostafa M. Aref

2011

Text Book: Software Engineering, 8th Edition, Ian Sommerville, University of St. Andrews, United Kingdom , ISBN-

10: 0321313798, Addison-Wesley, 2006.

Table of Contents Chapter 11: Chapter 11: Architectural DesignArchitectural Design Chapter 13: Chapter 13: Application ArchitecturesApplication Architectures Chapter 14: Chapter 14: Object-oriented DesignObject-oriented Design Chapter 16: Chapter 16: User Interface DesignUser Interface Design Chapter 17: Chapter 17: Rapid Software DevelopmentRapid Software Development Chapter 18: Chapter 18: Software ReuseSoftware Reuse Chapter 23: Chapter 23: Software TestingSoftware Testing

Chapter 11: Chapter 11: Architectural DesignArchitectural Design Objectives

– To introduce architectural design and to discuss its importance– To explain the architectural design decisions that have to be

made– To introduce three complementary architectural styles

covering organisation, decomposition and control– To discuss reference architectures are used to communicate

and compare architectures Topics covered

– Architectural Design Decisions– System Organisation– Decomposition Styles– Control Styles– Reference Architectures

3

Software architecture Architectural Design

– Stakeholder Communication– System Analysis– Large-scale Reuse

System Characteristics– Performance, Security, Safety, Availability, Maintainability

Architectural conflicts System structuring Box and line diagrams Architectural design decisions

Visionsystem

Objectidentification

system

Armcontroller

Grippercontroller

Packagingselectionsystem

Packingsystem

Conveyorcontroller

Architectural design decisions– Is there a generic application architecture that can be used?– How will the system be distributed?– What architectural styles are appropriate?– What approach will be used to structure the system?– How will the system be decomposed into modules?– What control strategy should be used?– How will the architectural design be evaluated?– How should the architecture be documented?

Architecture reuse Architectural styles Architectural models

– Static structural, Dynamic process, Interface, Relationships, Distribution

Architectural models The repository model

Client-server model

Projectrepository

Designtranslator

Programeditor

Designeditor

Codegenerator

Designanalyser

Reportgenerator

Catalogueserver

Librarycatalogue

Videoserver

Film clipfiles

Pictureserver

Digitisedphotographs

Web server

Film andphoto info.

Client 1 Client 2 Client 3 Client 4

Internet

Architectural models (2) Abstract machine (layered) model

Object models

Configuration management system layer

Database system layer

Operating system layer

Object management system layer

issue ()sendReminder ()acceptPayment ()sendReceipt ()

invoice#dateamountcustomer

invoice#dateamountcustomer#

invoice#dateamountcustomer#

customer#nameaddresscredit period

Customer

Payment

Invoice

Receipt

Architectural models (3) Function-oriented Pipelining

Control Styles– Call-return model

Read issuedinvoices

Identifypayments

Issuereceipts

Findpayments

due

Receipts

Issuepaymentreminder

Reminders

Invoices Payments

Routine 1.2Routine 1.1 Routine 3.2Routine 3.1

Routine 2 Routine 3Routine 1

Mainprogram

Architectural models (4) Control Styles

– Real-time system control

– Event-driven systems

– Broadcast model

Systemcontroller

Userinterface

Faulthandler

Computationprocesses

Actuatorprocesses

Sensorprocesses

Sub-system1

Event and message handler

Sub-system2

Sub-system3

Sub-system4

Architectural models (5)– Interrupt-driven control

– OSI reference model

– The ECMA reference model

Handler1

Handler2

Handler3

Handler4

Process1

Process2

Process3

Process4

Interrupts

Interruptvector

Presentation

Session

Transport

Network

Data link

Physical

7

6

5

4

3

2

1

Communications medium

Network

Data link

Physical

Application

Presentation

Session

Transport

Network

Data link

Physical

Application

Toolslots

Messageservices

Task management services

User interface services

Data repository services

Data integration services

Key points– The software architecture is the fundamental framework for

structuring the system.– Architectural design decisions include decisions on the

application architecture, the distribution and the architectural styles to be used.

– Different architectural models such as a structural model, a control model and a decomposition model may be developed.

– System organisational models include repository models, client-server models and abstract machine models.

– Modular decomposition models include object models and pipelining models.

– Control models include centralised control and event-driven models.

– Reference architectures may be used to communicate domain-specific architectures and to assess and compare architectural designs.

Chapter 13: Chapter 13: Application ArchitecturesApplication Architectures Objectives

– To explain the organisation of two fundamental models of business systems - batch processing and transaction processing systems

– To describe the abstract architecture of resource management systems

– To explain how generic editors are event processing systems– To describe the structure of language processing systems

Topics covered– Data processing systems– Transaction processing systems– Event processing systems– Language processing systems

12

Application Type ExamplesApplication Type Examples Data processing systems

– Billing systems;

– Payroll systems. Transaction processing systems

– E-commerce systems;

– Reservation systems. Event processing systems

– Word processors;

– Real-time systems. Language processing systems

– Compilers;

– Command interpreters.

Data Processing SystemsData Processing Systems Input-process-output model

Salary payment DFD

System

Input Process OutputPrinter

Database

Read employeerecord

Read monthlypay data

Computesalary

Write taxtransactions

Monthly paydata

Taxtables

Taxtransactions

Pension data

Validateemployee data

Write pensiondata

Write banktransaction

Write socialsecurity data

Employeerecords

Monthly payrates

Banktransactions

Social securitydata

Print payslipPRINTER

Decodedemployee

record

Pay information

Validemployee record

Tax deduction + SSnumber + tax office

Pensiondeduction +SS number

Empoyee data+ deductions

Net payment + bankaccount info.

Social securitydeduction + SS number

Transaction processing systemsTransaction processing systems Transaction processing

ATM system organization

Transaction processing middleware

I/Oprocessing

Applicationlogic

Transactionmanager Database

Get customeraccount id

Validate card

Input

Query account

Update account

Print details

Return card

Dispense cash

Process Output

Select service

ATM Database ATM

Serialisedtransactions

Teleprocessingmonitor

Accountsdatabase

ATMs and terminals

Account queriesand updates

Information Systems ArchitectureInformation Systems Architecture

LIBSYS architecture

Layered resource allocation

User interface

Information retrieval and modification

DatabaseTransaction management

User communications Web browser interface

Distributedsearch Accounting

LIBSYSlogin

Forms andquery manager

Library index

Documentretrieval

DB1 DB2 DB3 DB4 DBn

Rightsmanager

Printmanager

User interface

Resourcemanagement

Resource policycontrol

Resourceallocation

Userauthentication

Querymanagement

Resource database

Resourcedelivery

Transaction management

E-commerce System ArchitectureE-commerce System Architecture

Event processing systems– Editing system architecture

Webbrowser Web server Application

serverDatabase

server

File System

SaveOpen

Editor data

Editingcommands

Ancillary data

Ancillarycommands

Command

Interpret

Screen

Refresh

Display

Update

Event

Process

A Language Processing SystemA Language Processing System

Data-flow model of a compiler

Repository model of a compiler

Translator

Check syntaxCheck semanticsGenerate

Interpreter

FetchExecute

Abstract m/cinstructions

Data Results

Instructions

Lexicalanalysis

Syntacticanalysis

Semanticanalysis

Codegeneration

Symbol table

Syntax tree

Syntaxanalyser

Lexicalanalyser

Semanticanalyser

Abstractsyntax tree

Grammardefinition

Symboltable

Outputdefinition

Pretty-printer

Editor

Optimiser

Codegenerator

Repository

Key pointsKey points Generic models of application architectures help us understand

and compare applications. Important classes of application are data processing systems,

transaction processing systems, event processing systems and language processing system.

Data processing systems operate in batch mode and have an input-process-output structure.

Transaction processing systems allow information in a database to be remotely accessed and modified by multiple users.

Event processing systems include editors and real-time systems. In an editor, user interface events are detected and an in-store

data structure is modified. Language processing systems translate texts from one language to

another and may interpret the specified instructions.

Chapter 14: Chapter 14: Object-oriented DesignObject-oriented Design Objectives

– To explain how a software design may be represented as a set of interacting objects that manage their own state and operations

– To describe the activities in the object-oriented design process– To introduce various models that can be used to describe an object-oriented design– To show how the UML may be used to represent these models

Topics covered– Objects and object classes

– An object-oriented design process

– Design evolution Object-oriented development

– Object-oriented analysis, design and programming are related but distinct.

– OOA is concerned with developing an object model of the application domain.

– OOD is concerned with developing an object-oriented system model to implement requirements.

– OOP is concerned with realising an OOD using an OO programming language such as Java or C++. 20

Characteristics of OODCharacteristics of OOD– Objects are abstractions of real-world or system entities and manage

themselves.

– Objects are independent and encapsulate state and representation information.

– System functionality is expressed in terms of object services.

– Shared data areas are eliminated. Objects communicate by message passing.

– Objects may be distributed and may execute sequentially or in parallel.

Interacting objects

state o3

o3:C3

state o4

o4: C4

state o1

o1: C1

state o6

o6: C1

state o5

o5:C5

state o2

o2: C3

ops1() ops3 () ops4 ()

ops3 () ops1 () ops5 ()

Advantages of OODAdvantages of OOD– Easier maintenance. Objects may be understood as stand-alone entities.

– Objects are potentially reusable components.

– For some systems, there may be an obvious mapping from real world entities to system objects.

Objects and object classes– Objects are entities in a software system which represent instances of real-world

and system entities.

– Object classes are templates for objects. They may be used to create objects.

– Object classes may inherit attributes and services from other object classes.

– An object is an entity that has a state and a defined set of operations which operate on that state. The state is represented as a set of object attributes. The operations associated with the object provide services to other objects (clients) which request these services when some computation is required.

– Objects are created according to some object class definition. An object class definition serves as a template for objects. It includes declarations of all the attributes and services which should be associated with an object of that class.

The Unified Modelling LanguageThe Unified Modelling Language– Several different notations for describing object-oriented designs were proposed

in the 1980s and 1990s.

– The Unified Modeling Language is an integration of these notations.

– It describes notations for a number of different models that may be produced during OO analysis and design.

– It is now a de facto standard for OO modelling.

– Employee object class (UML)

Object communication– Conceptually, objects communicate by message passing.

– Messages The name of the service requested by the calling object; Copies of the information required to execute the service

and the name of a holder for the result of the service.

– In practice, messages are often implemented by procedure calls Name = procedure name; Information = parameter list.

Employee

name: stringaddress: stringdateOfBirth: DateemployeeNo: integersocialSecurityNo: stringdepartment: Deptmanager: Employeesalary: integerstatus: {current, left, retired}taxCode: integer. . .

join ()leave ()retire ()changeDetails ()

Message examplesMessage examples

Generalisation and inheritance

– Objects are members of classes that define attribute types and operations.

– Classes may be arranged in a class hierarchy where one class (a super-class) is a generalisation of one or more other classes (sub-classes).

– A sub-class inherits the attributes and operations from its super class and may add new methods or attributes of its own.

– Generalisation in the UML is implemented as inheritance in OO programming languages.

A Generalisation Hierarchy Advantages of Inheritance

– It is an abstraction mechanism which may be used to classify entities.

– It is a reuse mechanism at both the design and the programming level.

– The inheritance graph is a source of organisational knowledge

about domains and systems.

// Call a method associated with a buffer object that returns the next value in the bufferv = circularBuffer.Get () ;

// Call the method associated with a thermostat object that sets the temperature to be maintainedthermostat.setTemp (20) ;

Employee

Programmer

projectprogLanguages

Manager

ProjectManager

budgetsControlled

dateAppointed

projects

Dept.Manager

StrategicManager

dept responsibilities

Problems with InheritanceProblems with Inheritance– Object classes are not self-contained. they cannot be understood without

reference to their super-classes.

– Designers have a tendency to reuse the inheritance graph created during analysis. Can lead to significant inefficiency.

– The inheritance graphs of analysis, design and implementation have different functions and should be separately maintained.

UML Associations– Objects and object classes participate in relationships with other objects and

object classes.

– In the UML, a generalised relationship is indicated by an association.

– Associations may be annotated with information that describes the association.

– Associations are general but may indicate that an attribute of an object is an associated object or that a method relies on an associated object.

An association ModelAn association Model Concurrent Objects

– The nature of objects as self-contained entities make them suitable for concurrent implementation.

– The message-passing model of object communication can be implemented directly if objects are running on separate processors in a distributed system.

Servers and Active Objects– Servers: The object is implemented as a parallel process (server) with entry points corresponding

to object operations. If no calls are made to it, the object suspends itself and waits for further requests for service.

– Active objects: Objects are implemented as parallel processes and the internal object state may be changed by the object itself and not simply by external calls.

Active Transponder Object– Active objects may have their attributes modified by operations but may also

update them autonomously using internal operations.

– A Transponder object broadcasts an aircraft’s position. The position may be updated using a satellite positioning system. The object periodically update the position by triangulation from satellites.

An active transponder objectAn active transponder object

Java threads– Threads in Java are a simple construct for implementing concurrent objects.

– Threads must include a method called run() and this is started up by the Java run-time system.

– Active objects typically include an infinite loop so that they are always carrying out the computation.

An Object-oriented Design Process– Structured design processes involve developing a number of different system

models.– They require a lot of effort for development and maintenance of these models

and, for small systems, this may not be cost-effective.– However, for large systems developed by different groups design models are an

essential communication mechanism.

class Transponder extends Thread {

Position currentPosition ;

Coords c1, c2 ;

Satellite sat1, sat2 ;

Navigator theNavigator ;

public Position givePosition ()

{return currentPosition ;}

public void run ()

{while (true)

{ c1 = sat1.position () ;

c2 = sat2.position () ;

currentPosition = theNavigator.compute (c1,

c2) ;} } } //Transponder

Process StagesProcess Stages– Highlights key activities without being tied to any proprietary process such as

the RUP (Rational Unified Process). Define the context and modes of use of the system; Design the system architecture; Identify the principal system objects; Develop design models; Specify object interfaces.

System context and models of use– Develop an understanding of the relationships between the software being

designed and its external environment

– System context A static model that describes other systems in the environment. Use a subsystem model to show

other systems. Following slide shows the systems around the weather station system.

– Model of system use A dynamic model that describes how the system interacts with its environment. Use use-cases

to show interactions

Use-case ModelsUse-case Models– Use-case models are used to represent each interaction with the

system.

– A use-case model shows the system features as ellipses and the interacting entity as a stick figure.

Architectural design– Once interactions between the system and its environment have been

understood, you use this information for designing the system architecture.

– A layered architecture as discussed in Chapter 11 is appropriate for the weather station

Interface layer for handling communications; Data collection layer for managing instruments; Instruments layer for collecting data.

– There should normally be no more than 7 entities in an architectural model.

Object IdentificationObject Identification– Identifying objects (or object classes) is the most difficult part of

object oriented design.– There is no 'magic formula' for object identification. It relies on

the skill, experience and domain knowledge of system designers.– Object identification is an iterative process. You are unlikely to get

it right first time. Approaches to identification

– Use a grammatical approach based on a natural language description of the system (used in Hood OOD method).

– Base the identification on tangible things in the application domain.

– Use a behavioural approach and identify objects based on what participates in what behaviour.

– Use a scenario-based analysis. The objects, attributes and methods in each scenario are identified.

Design ModelsDesign Models– Design models show the objects and object classes and

relationships between these entities.

– Static models describe the static structure of the system in terms of object classes and relationships.

– Dynamic models describe the dynamic interactions between objects.

Examples of design models– Sub-system models that show logical groupings of objects into

coherent subsystems.– Sequence models that show the sequence of object interactions.– State machine models that show how individual objects change

their state in response to events.– Other models include use-case models, aggregation models,

generalisation models, etc.

Subsystem ModelsSubsystem Models– Shows how the design is organised into logically related groups of

objects.

– In the UML, these are shown using packages - an encapsulation construct. This is a logical model. The actual organisation of objects in the system may be different.

Sequence models– Sequence models show the sequence of object interactions that

take place Objects are arranged horizontally across the top; Time is represented vertically so models are read top to bottom; Interactions are represented by labelled arrows, Different styles of arrow

represent different types of interaction; A thin rectangle in an object lifeline represents the time when the object is

the controlling object in the system.

StatechartsStatecharts– Show how objects respond to different service requests and the

state transitions triggered by these requests If object state is Shutdown then it responds to a Startup() message; In the waiting state the object is waiting for further messages; If reportWeather () then system moves to summarising state; If calibrate () the system moves to a calibrating state; A collecting state is entered when a clock signal is received.

Object interface specification– Object interfaces have to be specified so that the objects and other

components can be designed in parallel.– Designers should avoid designing the interface representation but

should hide this in the object itself.– Objects may have several interfaces which are viewpoints on the

methods provided.– The UML uses class diagrams for interface specification but Java

may also be used.

Key pointsKey points– OOD is an approach to design so that design components have their own private

state and operations.

– Objects should have constructor and inspection operations. They provide services to other objects.

– Objects may be implemented sequentially or concurrently.

– The Unified Modeling Language provides different notations for defining different object models.

– A range of different models may be produced during an object-oriented design process. These include static and dynamic system models.

– Object interfaces should be defined precisely using e.g. a programming language like Java.

– Object-oriented design potentially simplifies system evolution.

Chapter 16: Chapter 16: User Interface DesignUser Interface Design Objectives

– To suggest some general design principles for user interface design– To explain different interaction styles and their use– To explain when to use graphical and textual information

presentation– To explain the principal activities in the user interface design

process– To introduce usability attributes and approaches to system

evaluation Topics covered

– Design issues– The user interface design process– User analysis– User interface prototyping– Interface evaluation 35

The user interfaceThe user interface– User interfaces should be designed to match the skills, experience

and expectations of its anticipated users.– System users often judge a system by its interface rather than its

functionality.– A poorly designed interface can cause a user to make catastrophic

errors.– Poor user interface design is the reason why so many software

systems are never used. Human factors in interface design

– Limited short-term memory People can instantaneously remember about 7 items of information. If you present more than

this, they are more liable to make mistakes.– People make mistakes

When people make mistakes and systems go wrong, inappropriate alarms and messages can increase stress and hence the likelihood of more mistakes.

– People are different People have a wide range of physical capabilities. Designers should not just design for their

own capabilities.– People have different interaction preferences

Some like pictures, some like text.

UI design principlesUI design principles– UI design must take account of the needs, experience and capabilities of the

system users.– Designers should be aware of people’s physical and mental limitations (e.g.

limited short-term memory) and should recognise that people make mistakes.– UI design principles underlie interface designs although not all principles are

applicable to all designs.

User familiarity

The interface should use terms and concepts which are drawn from the experience of the people who will make most use of the system.

Consistency The interface should use terms and concepts which are drawn from the experience of the people who will make most use of the system.

Minimal surprise

Users should never be surprised by the behaviour of a system.

Recoverability The interface should include mechanisms to allow users to recover from errors.

User guidance The interface should provide meaningful feedback when errors occur and provide context-sensitive user help facilities.

User diversity The interface should provide appropriate interaction facilities for different types of system user.

Design principlesDesign principles– User familiarity

The interface should be based on user-oriented terms and concepts rather than computer concepts. For example, an office system should use concepts such as letters, documents, folders etc. rather than directories, file identifiers, etc.

– Consistency The system should display an appropriate level of consistency. Commands and menus should

have the same format, command punctuation should be similar, etc.

– Minimal surprise If a command operates in a known way, the user should be able to predict the operation of

comparable commands

– Recoverability The system should provide some resilience to user errors and allow the user to recover from

errors. This might include an undo facility, confirmation of destructive actions, 'soft' deletes, etc.

– User guidance Some user guidance such as help systems, on-line manuals, etc. should be supplied

– User diversity Interaction facilities for different types of user should be supported. For example, some users

have seeing difficulties and so larger text should be available

Design issues in UIsDesign issues in UIs– Two problems must be addressed in interactive systems design

How should information from the user be provided to the computer system? How should information from the computer system be presented to the user?

– User interaction and information presentation may be integrated through a coherent framework such as a user interface metaphor.

Interaction styles– Direct manipulation

– Menu selection

– Form fill-in

– Command language

– Natural language

Interaction stylesInteraction styles Interaction

styleMain advantages

Main disadvantages

Application examples

Direct manipulation

Fast and intuitive interactionEasy to learn

May be hard to implement.Only suitable where there is a visual metaphor for tasks and objects.

Video games CAD systems

Menu selection Avoids user errorLittle typing required

Slow for experienced users.Can become complex if many menu options.

Most general-purpose systems

Form fill-in Simple data entryEasy to learnCheckable

Takes up a lot of screen space.Causes problems where user options do not match the form fields.

Stock control, Personal loan processing

Command language

Powerful and flexible

Hard to learn.Poor error management.

Operating systems, Command and control systems

Natural language Accessible to casual users Easily extended

Requires more typing.Natural language understanding systems are unreliable.

Information retrieval systems

Multiple user interfacesMultiple user interfaces LIBSYS interaction

– Document search Users need to be able to use the search

facilities to find the documents that they need.

– Document request Users request that a document be delivered

to their machine or to a server for printing.

Web-based interfaces– Many web-based systems have interfaces based on web forms.

– Form field can be menus, free text input, radio buttons, etc.

– In the LIBSYS example, users make a choice of where to search from a menu and type the search phrase into a free text field.

Linux operating system

X-windows GUImanager

Graphical userinterface

(Gnome/KDE)

Commandlanguageinterpreter

Unix shellinterface(ksh/csh)

LIBSYS Search FormLIBSYS Search Form Information Presentation

– Information presentation is concerned with presenting system information to system users.

– The information may be presented directly (e.g. text in a word processor) or may be transformed in some way for presentation (e.g. in some graphical form).

– The Model-View-Controller approach is a way of supporting multiple presentations of data.

LIBSYS: Search

Choose collection

Keyword or phrase

Search using

Adjacent words

Search Reset Cancel

All

Title

Yes No

Information tobe displayed

Presentationsoftware

Display

Model-View-ControllerModel-View-Controller Information presentation

– Static information Initialised at the beginning of a session. It does not change during the session. May be either numeric or textual.

– Dynamic information Changes during a session and the changes must be communicated to the

system user. May be either numeric or textual.

Information display factors– Is the user interested in precise information or data relationships?– How quickly do information values change?

Must the change be indicated immediately?– Must the user take some action in response to a change?– Is there a direct manipulation interface?– Is the information textual or numeric? Are relative values

important?

Model methods

Controller methods View methods

Userinputs

view modificationmessages

Model edits

Model queriesand updates

Controller state View state

Model state

Alternative information presentationsAlternative information presentations Analogue or digital presentation?

– Digital presentation Compact - takes up little screen space; Precise values can be communicated.

– Analogue presentation Easier to get an 'at a glance' impression of a value; Possible to show relative values; Easier to see exceptional data values.

Presentation methods Displaying relative values

0

1000

2000

3000

4000

Jan Feb Mar April May June

Jan2842

Feb2851

Mar3164

April2789

May1273

June2835

1

3

4 20 10 20

Dial with needle Pie chart Thermometer Horizontal bar

0 100 200 300 400 0 25 50 75 100

Pressure Temperature

Data visualisationData visualisation– Concerned with techniques for displaying large amounts of information.– Visualisation can reveal relationships between entities and trends in the data.– Possible data visualisations are:

Weather information collected from a number of sources; The state of a telephone network as a linked set of nodes; Chemical plant visualised by showing pressures and temperatures in a linked set of tanks and

pipes; A model of a molecule displayed in 3 dimensions; Web pages displayed as a hyperbolic tree.

Colour displays– Colour adds an extra dimension to an interface and can help the

user understand complex information structures.– Colour can be used to highlight exceptional events.– Common mistakes in the use of colour in

interface design include: The use of colour to communicate meaning; The over-use of colour in the display.

Colour use guidelinesColour use guidelines– Limit the number of colours used and be conservative in their use.– Use colour change to show a change in system status.– Use colour coding to support the task that users are trying to

perform.– Use colour coding in a thoughtful and consistent way.– Be careful about colour pairings.

Error messages– Error message design is critically important.

Poor error messages can mean that a user rejects rather than accepts a system.

– Messages should be polite, concise, consistent and constructive.

– The background and experience of users should be the determining factor in message design.

Design factors in message wordingDesign factors in message wording Factor Description

Context Wherever possible, the messages generated by the system should reflect the current user context. As far as is possible, the system should be aware of what the user is doing and should generate messages that are relevant to their current activity.

Experience As users become familiar with a system they become irritated by long, ‘meaningful’ messages. However, beginners find it difficult to understand short terse statements of a problem. You should provide both types of message and allow the user to control message conciseness.

Skill level Messages should be tailored to the user’s skills as well as their experience. Messages for the different classes of user may be expressed in different ways depending on the terminology that is familiar to the reader.

Style Messages should be positive rather than negative. They should use the active rather than the passive mode of address. They should never be insulting or try to be funny.

Culture Wherever possible, the designer of messages should be familiar with the culture of the country where the system is sold. There are distinct cultural differences between Europe, Asia and America. A suitable message for one culture might be unacceptable in another.

User errorUser error– Assume that a nurse misspells the name of a patient whose records

he is trying to retrieve.

– Good and bad message design

The UI design process– UI design is an iterative process involving close liaisons between

users and designers.– The 3 core activities in this process are:

User analysis. Understand what the users will do with the system; System prototyping. Develop a series of prototypes for experiment; Interface evaluation. Experiment with these prototypes with users.

Please type the patient’s name in the box then click on OK

MacDonald, R.

OK Cancel

Patient’s name

Error #27

Invalid patient id

OK Cancel

System-oriented error messageUser-oriented error message

R. MacDonald is not a reg istered patient

Click on Patients for a list of patientsClick on Retry to re-input the patient’s nameClick on Help for more information

Patients Help Retry Cancel

The design processThe design process User analysis

– If you don’t understand what the users want to do with a system, you have no realistic prospect of designing an effective interface.

– User analyses have to be described in terms that users and other designers can understand.

– Scenarios where you describe typical episodes of use, are one way of describing these analyses.

Executableprototype

Designprototype

Produce paper-based design

prototype

Producedynamic design

prototype

Evaluate designwith end-users

Implementfinal userinterface

Evaluate designwith end-users

Analyse andunderstand

user activities

User interaction scenarioUser interaction scenario Requirements from the scenario

– Users may not be aware of appropriate search terms so need a way of helping them choose terms.

– Users have to be able to select collections to search.

– Users need to be able to carry out searches and request copies of relevant material.

Analysis techniques– Task analysis

Models the steps involved in completing a task.

– Interviewing and questionnaires Asks the users about the work they do.

– Ethnography Observes the user at work.

Hierarchical task analysisHierarchical task analysis

Interviewing– Design semi-structured interviews based on open-ended questions.

– Users can then provide information that they think is essential; not just information that you have thought of collecting.

– Group interviews or focus groups allow users to discuss with each other what they do.

Retrieve picturesfrom remote

libraries

Discoverpossiblesources

Establishsearchterms

Search forpictures

Requestphotocopies

of found items

1 2 3 4.

Selectlibrary

Log in tocatalogue

Search forpictures

Modifysearch terms

Recordrelevantitems

3.1 3.2 3.3 3.4 3.5

Enter searchterms

Initiatesearch

Reviewresults

3.3.1 3.3.2 3.3.3

do 1, 2,3 until pictures found, 4

do 3.1, 3.2,3.3 until pictures found,3.4 if necessary, 3.5

do 3.3.1, 3.3.2, 3.3.3

EthnographyEthnography– Involves an external observer watching users at work and

questioning them in an unscripted way about their work.

– Valuable because many user tasks are intuitive and they find these very difficult to describe and explain.

– Also helps understand the role of social and organisational influences on work.

User interface prototyping– The aim of prototyping is to allow users to gain direct experience

with the interface.– Without such direct experience, it is impossible to judge the

usability of an interface.– Prototyping may be a two-stage process:

Early in the process, paper prototypes may be used; The design is then refined and increasingly sophisticated automated

prototypes are then developed.

Paper prototypingPaper prototyping– Work through scenarios using sketches of the interface.

– Use a storyboard to present a series of interactions with the system.

– Paper prototyping is an effective way of getting user reactions to a design proposal.

Prototyping techniques– Script-driven prototyping

Develop a set of scripts and screens using a tool such as Macromedia Director. When the user interacts with these, the screen changes to the next display.

– Visual programming Use a language designed for rapid development such as Visual Basic. See

Chapter 17.

– Internet-based prototyping Use a web browser and associated scripts.

User interface evaluationUser interface evaluation– Some evaluation of a user interface design should be carried out to

assess its suitability.– Full scale evaluation is very expensive and impractical for most

systems.– Ideally, an interface should be evaluated against a usability

specification. However, it is rare for such specifications to be produced.

Usability attributesAttribute DescriptionLearnability How long does it take a new user to become productive with the system?

Speed of operation How well does the system response match the user’s work practice?

Robustness How tolerant is the system of user error?

Recoverability How good is the system at recovering from user errors?

Adaptability How closely is the system tied to a single model of work?

Simple evaluation techniquesSimple evaluation techniques– Questionnaires for user feedback.

– Video recording of system use and subsequent tape evaluation.

– Instrumentation of code to collect information about facility use and user errors.

– The provision of code in the software to collect on-line user feedback.

Key points– User interface design principles should help guide the design of

user interfaces.– Interaction styles include direct manipulation, menu systems form

fill-in, command languages and natural language.– Graphical displays should be used to present trends and

approximate values. Digital displays when precision is required.– Colour should be used sparingly and consistently.– The user interface design process involves user analysis, system

prototyping and prototype evaluation.– The aim of user analysis is to sensitise designers to the ways in

which users actually work.– UI prototyping should be a staged process with early paper

prototypes used as a basis for automated prototypes of the interface.

– The goals of UI evaluation are to obtain feedback on how to improve the interface design and to assess if the interface meets its usability requirements.

Chapter 17: Chapter 17: Rapid Software Rapid Software DevelopmentDevelopment

Objectives– To explain how an iterative, incremental development process

leads to faster delivery of more useful software– To discuss the essence of agile development methods– To explain the principles and practices of extreme programming– To explain the roles of prototyping in the software process

Topics covered– Agile methods

– Extreme programming

– Rapid application development

– Software prototyping

57

Rapid software developmentRapid software development– Because of rapidly changing business environments, businesses

have to respond to new opportunities and competition.– This requires software and rapid development and delivery is not

often the most critical requirement for software systems.– Businesses may be willing to accept lower quality software if rapid

delivery of essential functionality is possible.

Requirements– Because of the changing environment, it is often impossible to

arrive at a stable, consistent set of system requirements.

– Therefore a waterfall model of development is impractical and an approach to development based on iterative specification and delivery is the only way to deliver software quickly.

Characteristics of RAD processesCharacteristics of RAD processes– The processes of specification, design and implementation are

concurrent. There is no detailed specification and design documentation is minimised.

– The system is developed in a series of increments. End users evaluate each increment and make proposals for later increments.

– System user interfaces are usually developed using an interactive development system.

An iterative development process

Validateincrement

Build systemincrement

Specify systemincrement

Design systemarchitecture

Define systemdeliverables

Systemcomplete?

Integrateincrement

Validatesystem

Deliver finalsystem

YES

NO

Advantages of incremental Advantages of incremental developmentdevelopment

– Accelerated delivery of customer services. Each increment delivers the highest priority functionality to the customer.

– User engagement with the system. Users have to be involved in the development which means the system is more likely to meet their requirements and the users are more committed to the system.

Problems with incremental development– Management problems

Progress can be hard to judge and problems hard to find because there is no documentation to demonstrate what has been done.

– Contractual problems The normal contract may include a specification; without a specification, different forms of

contract have to be used.

– Validation problems Without a specification, what is the system being tested against?

– Maintenance problems Continual change tends to corrupt software structure making it more expensive to change and

evolve to meet new requirements.

PrototypingPrototyping– For some large systems, incremental iterative development and

delivery may be impractical; this is especially true when multiple teams are working on different sites.

– Prototyping, where an experimental system is developed as a basis for formulating the requirements may be used. This system is thrown away when the system specification has been agreed.

Incremental development and prototyping

Incrementaldevelopment

Throw-awayprototyping

Delivered system

Executable prototype +System specification

Outlinerequirements

Conflicting objectivesConflicting objectives– The objective of incremental development is to deliver a working

system to end-users. The development starts with those requirements which are best understood.

– The objective of throw-away prototyping is to validate or derive the system requirements. The prototyping process starts with those requirements which are poorly understood.

Agile methods– Dissatisfaction with the overheads involved in design methods led to the

creation of agile methods. These methods: Focus on the code rather than the design; Are based on an iterative approach to software development; Are intended to deliver working software quickly and evolve this quickly to meet changing

requirements.

– Agile methods are probably best suited to small/medium-sized business systems or PC products.

Principles of agile methodsPrinciples of agile methods

Principle Description

Customer involvement

The customer should be closely involved throughout the development process. Their role is provide and prioritise new system requirements and to evaluate the iterations of the system.

Incremental delivery

The software is developed in increments with the customer specifying the requirements to be included in each increment.

People not process

The skills of the development team should be recognised and exploited. The team should be left to develop their own ways of working without prescriptive processes.

Embrace change

Expect the system requirements to change and design the system so that it can accommodate these changes.

Maintain simplicity

Focus on simplicity in both the software being developed and in the development process used. Wherever possible, actively work to eliminate complexity from the system.

Problems with agile methodsProblems with agile methods– It can be difficult to keep the interest of customers who are

involved in the process.– Team members may be unsuited to the intense involvement that

characterises agile methods.– Prioritising changes can be difficult where there are multiple

stakeholders.– Maintaining simplicity requires extra work.– Contracts may be a problem as with other approaches to iterative

development. Extreme programming

– Perhaps the best-known and most widely used agile method.– Extreme Programming (XP) takes an ‘extreme’ approach to

iterative development. New versions may be built several times per day; Increments are delivered to customers every 2 weeks; All tests must be run for every build and the build is only accepted if tests

run successfully.

The XP release cycleThe XP release cycle

Extreme programming practices 1

Break downstories to tasks

Select userstories for this

releasePlan release

Releasesoftware

Evaluatesystem

Develop/integrate/test software

Incremental planning

Requirements are recorded on Story Cards and the Stories to be included in a release are determined by the time available and their relative priority. The developers break these Stories into development ‘Tasks’.

Small Releases The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release.

Simple Design Enough design is carried out to meet the current requirements and no more.

Test first development

An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented.

Refactoring All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable.

Extreme programming practices 2Extreme programming practices 2

XP and agile principles– Incremental development is supported through small, frequent

system releases.– Customer involvement means full-time customer engagement with

the team.– People not process through pair programming, collective

ownership and a process that avoids long working hours.– Change supported through regular system releases.– Maintaining simplicity through constant refactoring of code.

Pair Programming Developers work in pairs, checking each other’s work and providing the support to always do a good job.

Collective Ownership

The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers own all the code. Anyone can change anything.

Continuous Integration

As soon as work on a task is complete it is integrated into the whole system. After any such integration, all the unit tests in the system must pass.

Sustainable pace Large amounts of over-time are not considered acceptable as the net effect is often to reduce code quality and medium term productivity

On-site Customer A representative of the end-user of the system (the Customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation.

Requirements scenariosRequirements scenarios– In XP, user requirements are expressed as scenarios or user stories.

– These are written on cards and the development team break them down into implementation tasks. These tasks are the basis of schedule and cost estimates.

– The customer chooses the stories for inclusion in the next release based on their priorities and the schedule estimates.

XP and change– Conventional wisdom in software engineering is to design for

change. It is worth spending time and effort anticipating changes as this reduces costs later in the life cycle.

– XP, however, maintains that this is not worthwhile as changes cannot be reliably anticipated.

– Rather, it proposes constant code improvement (refactoring) to make changes easier when they have to be implemented.

Testing in XPTesting in XP– Test-first development.– Incremental test development from scenarios.– User involvement in test development and validation.– Automated test harnesses are used to run all component tests each

time that a new release is built. Task cards for document downloading

Task 1: Implement principal workflow

Task 2: Implement article catalog and selection

Task 3: Implement payment collection

Payment may be made in 3 different ways. The userselects which way they wish to pay. If the userhas a library subscription, then they can input thesubscriber key which should be checked by thesystem. Alternatively, they can input an organisationalaccount number. If this is valid, a debit of the costof the article is posted to this account. Finally, theymay input a 16 digit credit card number and expirydate. This should be checked for validity and, ifvalid a debit is posted to that credit card account.

Test 4: Test credit card validity

Input:A string representing the credit card number and two integers representingthe month and year when the card expiresTests:Check that all bytes in the string are digitsCheck that the month lies between 1 and 12 and theyear is greater than or equal to the current year.Using the first 4 digits of the credit card number,check that the card issuer is valid by looking up thecard issuer table. Check credit card validity by submitting the cardnumber and expiry date information to the cardissuerOutput:OK or error message indicating that the card is invalid

Test-first developmentTest-first development– Writing tests before code clarifies the requirements to be

implemented.– Tests are written as programs rather than data so that they can be

executed automatically. The test includes a check that it has executed correctly.

– All previous and new tests are automatically run when new functionality is added. Thus checking that the new functionality has not introduced errors.

Pair programming– In XP, programmers work in pairs, sitting together to develop

code.– This helps develop common ownership of code and spreads

knowledge across the team.– It serves as an informal review process as each line of code is

looked at by more than 1 person.– It encourages refactoring as the whole team can benefit from this.– Measurements suggest that development productivity with pair

programming is similar to that of two people working independently.

Rapid application developmentRapid application development– Agile methods have received a lot of attention but other

approaches to rapid application development have been used for many years.

– These are designed to develop data-intensive business applications and rely on programming and presenting information from a database.

RAD environment tools– Database programming language

– Interface generator

– Links to office applications

– Report generators

A RAD environment

DBprogramming

language

Interfacegenerator

Officesystems

Reportgenerator

Database management system

Rapid applicationdevelopment environment

Interface generationInterface generation– Many applications are based around complex forms and

developing these forms manually is a time-consuming activity.– RAD environments include support for screen generation

including: Interactive form definition using drag and drop techniques; Form linking where the sequence of forms to be presented is specified; Form verification where allowed ranges in form fields is defined.

Visual programming– Scripting languages such as Visual Basic support visual

programming where the prototype is developed by creating a user interface from standard items and associating components with these items

– A large library of components exists to support this type of development

– These may be tailored to suit the specific application requirements

Visual programming with reuseVisual programming with reuse Problems with visual development

– Difficult to coordinate team-based development.– No explicit system architecture.– Complex dependencies between parts of the program can cause maintainability problems.

COTS reuse– An effective approach to rapid development is to configure and

link existing off the shelf systems.– For example, a requirements management system could be built by

using: A database to store requirements; A word processor to capture requirements and format reports; A spreadsheet for traceability management;

File Edit Views Layout Options Help

GeneralIndex

Menu componentDate component

Range checkingscript

Tree displaycomponent

Draw canvascomponent

User promptcomponent +

script

12th January 2000

3.876

Compound documentsCompound documents– For some applications, a prototype can be created by developing a

compound document.– This is a document with active elements (such as a spreadsheet)

that allow user computations.– Each active element has an associated application which is

invoked when that element is selected.– The document itself is the integrator for the different applications.

Application linking

Word processor Spreadsheet Audio player

Text 1 Text 2 Text 3

Text 5

Table 1 Sound 1

Text 4Table 2 Sound 2

Compound document

Software prototypingSoftware prototyping– A prototype is an initial version of a system used to demonstrate

concepts and try out design options.– A prototype can be used in:

The requirements engineering process to help with requirements elicitation and validation;

In design processes to explore options and develop a UI design; In the testing process to run back-to-back tests.

Benefits of prototyping– Improved system usability.– A closer match to users’ real needs.– Improved design quality.– Improved maintainability.– Reduced development effort.

Back to back testing

Test data

Resultscomparator

Systemprototype

Applicationsystem

Differencereport

The prototyping processThe prototyping process

Throw-away prototypes– Prototypes should be discarded after development as they are not a

good basis for a production system: It may be impossible to tune the system to meet non-functional

requirements; Prototypes are normally undocumented; The prototype structure is usually degraded through rapid change; The prototype probably will not meet normal organisational quality

standards.

Establishprototypeobjectives

Defineprototype

functionality

Developprototype

Evaluateprototype

Prototypingplan

Outlinedefinition

Executableprototype

Evaluationreport

Key points– An iterative approach to software development leads to faster

delivery of software.– Agile methods are iterative development methods that aim to

reduce development overhead and so produce software faster.– Extreme programming includes practices such as systematic

testing, continuous improvement and customer involvement.– The approach to testing in XP is a particular strength where

executable tests are developed before the code is written.– Rapid application development environments include database

programming languages, form generation tools and links to office applications.

– A throw-away prototype is used to explore requirements and design options.

– When implementing a throw-away prototype, start with the requirements you least understand; in incremental development, start with the best-understood requirements.

Chapter 18: Chapter 18: Software ReuseSoftware Reuse Objectives

– To explain the benefits of software reuse and some reuse problems– To discuss several different ways to implement software reuse– To explain how reusable concepts can be represented as patterns or embedded

in program generators– To discuss COTS reuse– To describe the development of software product lines

Topics covered– The reuse landscape

– Design patterns

– Generator based reuse

– Application frameworks

– Application system reuse77

Software reuseSoftware reuse– In most engineering disciplines, systems are designed by

composing existing components that have been used in other systems.

– Software engineering has been more focused on original development but it is now recognised that to achieve better software, more quickly and at lower cost, we need to adopt a design process that is based on systematic software reuse.

Reuse-based software engineering– Application system reuse

The whole of an application system may be reused either by incorporating it without change into other systems (COTS reuse) or by developing application families.

– Component reuse Components of an application from sub-systems to single objects may be

reused. Covered in Chapter 19.– Object and function reuse

Software components that implement a single well-defined object or function may be reused.

Reuse benefitsReuse benefits Increased dependability

Reused software, that has been tried and tested in working systems, should be more dependable than new software. The initial use of the software reveals any design and implementation faults. These are then fixed, thus reducing the number of failures when the software is reused.

Reduced process risk

If software exists, there is less uncertainty in the costs of reusing that software than in the costs of development. This is an important factor for project management as it reduces the margin of error in project cost estimation. This is particularly true when relatively large software components such as sub-systems are reused.

Effective use of specialists

Instead of application specialists doing the same work on different projects, these specialists can develop reusable software that encapsulate their knowledge.

Standards compliance

Some standards, such as user interface standards, can be implemented as a set of standard reusable components. For example, if menus in a user interfaces are implemented using reusable components, all applications present the same menu formats to users. The use of standard user interfaces improves dependability as users are less likely to make mistakes when presented with a familiar interface.

Accelerated development

Bringing a system to market as early as possible is often more important than overall development costs. Reusing software can speed up system production because both development and validation time should be reduced.

Reuse problemsReuse problems Increased maintenance costs

If the source code of a reused software system or component is not available then maintenance costs may be increased as the reused elements of the system may become increasingly incompatible with system changes.

Lack of tool support CASE toolsets may not support development with reuse. It may be difficult or impossible to integrate these tools with a component library system. The software process assumed by these tools may not take reuse into account.

Not-invented-here syndrome

Some software engineers sometimes prefer to re-write components as they believe that they can improve on the reusable component. This is partly to do with trust and partly to do with the fact that writing original software is seen as more challenging than reusing other people’s software.

Creating and maintaining a component library

Populating a reusable component library and ensuring the software developers can use this library can be expensive. Our current techniques for classifying, cataloguing and retrieving software components are immature.

Finding, understanding and adapting reusable components

Software components have to be discovered in a library, understood and, sometimes, adapted to work in a new environment. Engineers must be reasonably confident of finding a component in the library before they will make routinely include a component search as part of their normal development process.

The reuse landscapeThe reuse landscape– Although reuse is often simply thought of as the reuse of system

components, there are many different approaches to reuse that may be used.

– Reuse is possible at a range of levels from simple functions to complete application systems.

– The reuse landscape covers the range of possible reuse techniques.

Designpatterns

Component-baseddevelopment

Componentframeworks

Service-orientedsystems

COTSintegration

Applicationproduct lines

Legacy systemwrapping

Programlibraries

Programgenerators

Aspect-orientedsoftware development

Configurable verticalapplications

Reuse approachesReuse approaches

Design patterns Generic abstractions that occur across applications are represented as design patterns that show abstract and concrete objects and interactions.

Component-based development

Systems are developed by integrating components (collections of objects) that conform to component-model standards. This is covered in Chapter 19.

Application frameworks

Collections of abstract and concrete classes that can be adapted and extended to create application systems.

Legacy system wrapping

Legacy systems (see Chapter 2) that can be ‘wrapped’ by defining a set of interfaces and providing access to these legacy systems through these interfaces.

Service-oriented systems

Systems are developed by linking shared services that may be externally provided.

Application product lines

An application type is generalised around a common architecture so that it can be adapted in different ways for different customers.

COTS integration Systems are developed by integrating existing application systems.

Configurable vertical applications

A generic system is designed so that it can be configured to the needs of specific system customers.

Program libraries Class and function libraries implementing commonly-used abstractions are available for reuse.

Program generators A generator system embeds knowledge of a particular types of application and can generate systems or system fragments in that domain.

Aspect-oriented software development

Shared components are woven into an application at different places when the program is compiled.

Reuse planning factorsReuse planning factors– The development schedule for the software.– The expected software lifetime.– The background, skills and experience of the development team.– The criticality of the software and its non-functional requirements.– The application domain.– The execution platform for the software.

Concept reuse– When you reuse program or design components, you have to

follow the design decisions made by the original developer of the component.

– This may limit the opportunities for reuse.– However, a more abstract form of reuse is concept reuse when a

particular approach is described in an implementation independent way and an implementation is then developed.

– The two main approaches to concept reuse are: Design patterns; Generative programming.

Design patternsDesign patterns– A design pattern is a way of reusing abstract knowledge about a

problem and its solution.– A pattern is a description of the problem and the essence of its

solution.– It should be sufficiently abstract to be reused in different settings.– Patterns often rely on object characteristics such as inheritance and

polymorphism. Pattern elements

– Name: A meaningful pattern identifier.– Problem description.– Solution description: Not a concrete design but a template for a

design solution that can be instantiated in different ways.– Consequences: The results and trade-offs of applying the pattern.

The Observer patternThe Observer pattern– Description: Separates the display of object state from the object

itself.– Problem description: Used when multiple displays of state are

needed.– Solution description: See slide with UML description.– Consequences: Optimisations to enhance display performance are

impractical. Generator-based reuse

– Program generators involve the reuse of standard patterns and algorithms.

– These are embedded in the generator and parameterised by user commands. A program is then automatically generated.

– Generator-based reuse is possible when domain abstractions and their mapping to executable code can be identified.

– A domain specific language is used to compose and control these abstractions.

Types of program generatorTypes of program generator– Types of program generator

Application generators for business data processing; Parser and lexical analyser generators for language processing; Code generators in CASE tools.

– Generator-based reuse is very cost-effective but its applicability is limited to a relatively small number of application domains.

– It is easier for end-users to develop programs using generators compared to other component-based approaches to reuse.

Aspect-oriented development– Aspect-oriented development addresses a major software engineering problem -

the separation of concerns.– Concerns are often not simply associated with application functionality but are

cross-cutting - e.g. all components may monitor their own operation, all components may have to maintain security, etc.

– Cross-cutting concerns are implemented as aspects and are dynamically woven into a program. The concern code is reuse and the new system is generated by the aspect weaver.

Application frameworksApplication frameworks– Frameworks are a sub-system design made up of a collection of

abstract and concrete classes and the interfaces between them.– The sub-system is implemented by adding components to fill in

parts of the design and by instantiating the abstract classes in the framework.

– Frameworks are moderately large entities that can be reused. Framework classes

– System infrastructure frameworks Support the development of system infrastructures such as communications,

user interfaces and compilers.– Middleware integration frameworks

Standards and classes that support component communication and information exchange.

– Enterprise application frameworks Support the development of specific types of application such as

telecommunications or financial systems.

Extending frameworksExtending frameworks– Frameworks are generic and are extended to create a more specific

application or sub-system.– Extending the framework involves

Adding concrete classes that inherit operations from abstract classes in the framework;

Adding methods that are called in response to events that are recognised by the framework.

– Problem with frameworks is their complexity which means that it takes a long time to use them effectively.

Model-view controller– System infrastructure framework for GUI design.– Allows for multiple presentations of an object and separate

interactions with these presentations.– MVC framework involves the instantiation of a number of patterns

(as discussed earlier under concept reuse).

Application system reuseApplication system reuse– Involves the reuse of entire application systems either by

configuring a system for an environment or by integrating two or more systems to create a new application.

– Two approaches covered here: COTS product integration; Product line development.

COTS product reuse– COTS - Commercial Off-The-Shelf systems.– COTS systems are usually complete application systems that offer

an API (Application Programming Interface).– Building large systems by integrating COTS systems is now a

viable development strategy for some types of system such as E-commerce systems.

– The key benefit is faster application development and, usually, lower development costs.

COTS design choicesCOTS design choices– Which COTS products offer the most appropriate functionality?

There may be several similar products that may be used.

– How will data be exchanged? Individual products use their own data structures and formats.

– What features of the product will actually be used? Most products have more functionality than is needed. You should try to

deny access to unused functionality.

COTS products reused– On the client, standard e-mail and web browsing programs are

used.

– On the server, an e-commerce platform has to be integrated with an existing ordering system.

This involves writing an adaptor so that they can exchange data. An e-mail system is also integrated to generate e-mail for clients. This also

requires an adaptor to receive data from the ordering and invoicing system.

COTS system integration problemsCOTS system integration problems– Lack of control over functionality and performance

COTS systems may be less effective than they appear– Problems with COTS system inter-operability

Different COTS systems may make different assumptions that means integration is difficult

– No control over system evolution COTS vendors not system users control evolution

– Support from COTS vendors COTS vendors may not offer support over the lifetime of the product

Software product lines– Software product lines or application families are applications with generic

functionality that can be adapted and configured for use in a specific context.

– Adaptation may involve: Component and system configuration; Adding new components to the system; Selecting from a library of existing components; Modifying components to meet new requirements.

COTS product specialisationCOTS product specialisation– Platform specialisation

Different versions of the application are developed for different platforms.– Environment specialisation

Different versions of the application are created to handle different operating environments e.g. different types of communication equipment.

– Functional specialisation Different versions of the application are created for customers with different

requirements.– Process specialisation

Different versions of the application are created to support different business processes.

COTS configuration– Deployment time configuration

A generic system is configured by embedding knowledge of the customer’s requirements and business processes. The software itself is not changed.

– Design time configuration A common generic code is adapted and changed according to the

requirements of particular customers.

ERP systemsERP systems– An Enterprise Resource Planning (ERP) system is a generic

system that supports common business processes such as ordering and invoicing, manufacturing, etc.

– These are very widely used in large companies - they represent probably the most common form of software reuse.

– The generic core is adapted by including modules and by incorporating knowledge of business processes and rules.

Design time configuration– Software product lines that are configured at design time are

instantiations of generic application architectures as discussed in Chapter 13.

– Generic products usually emerge after experience with specific products.

Product line architecturesProduct line architectures– Architectures must be structured in such a way to separate

different sub-systems and to allow them to be modified.– The architecture should also separate entities and their descriptions

and the higher levels in the system access entities through descriptions rather than directly.

Product instance development– Elicit stakeholder requirements

Use existing family member as a prototype– Choose closest-fit family member

Find the family member that best meets the requirements– Re-negotiate requirements

Adapt requirements as necessary to capabilities of the software– Adapt existing system

Develop new modules and make changes for family member– Deliver new family member

Document key features for further member development

Key points– Advantages of reuse are lower costs, faster software development

and lower risks.– Design patterns are high-level abstractions that document

successful design solutions.– Program generators are also concerned with software reuse - the

reusable concepts are embedded in a generator system.– Application frameworks are collections of concrete and abstract

objects that are designed for reuse through specialisation.– COTS product reuse is concerned with the reuse of large, off-the-

shelf systems.– Problems with COTS reuse include lack of control over

functionality, performance, and evolution and problems with inter-operation.

– ERP systems are created by configuring a generic system with information about a customer’s business.

– Software product lines are related applications developed around a common core of shared functionality.

Chapter 23: Chapter 23: Software TestingSoftware Testing Objectives

– To discuss the distinctions between validation testing and defect testing

– To describe the principles of system and component testing

– To describe strategies for generating system test cases

– To understand the essential characteristics of tool used for test automation

Topics covered– System testing

– Component testing

– Test case design

– Test automation100

The testing processThe testing process– Component testing

Testing of individual program components; Usually the responsibility of the component developer (except sometimes for critical

systems); Tests are derived from the developer’s experience.

– System testing Testing of groups of components integrated to create a system or sub-system; The responsibility of an independent testing team; Tests are based on a system

Testing phases Defect testing

– The goal of defect testing is to discover defects in programs– A successful defect test is a test which causes a program to behave

in an anomalous way– Tests show the presence not the absence of defects

Componenttesting

Systemtesting

Software developer Independent testing team

Testing process goalsTesting process goals– Validation testing

To demonstrate to the developer and the system customer that the software meets its requirements;

A successful test shows that the system operates as intended.

– Defect testing To discover faults or defects in the software where its behaviour is incorrect or not in

conformance with its specification; A successful test is a test that makes the system perform incorrectly and so exposes a

defect in the system.

Testing policies

– Only exhaustive testing can show a program is free from defects. However, exhaustive testing is impossible,

– Testing policies define the approach to be used in selecting system tests: All functions accessed through menus should be tested; Combinations of functions accessed through the same menu should be tested; Where user input is required, all functions must be tested with correct and incorrect

input.

Design testcases

Prepare testdata

Run programwith test data

Compare resultsto test cases

Testcases

Testdata

Testresults

Testreports

System testingSystem testing– Involves integrating components to create a system or sub-system.– May involve testing an increment to be delivered to the customer.– Two phases:

Integration testing - the test team have access to the system source code. The system is tested as components are integrated.

Release testing - the test team test the complete system to be delivered as a black-box.

Integration testing– Involves building a system from its components and testing it for

problems that arise from component interactions.– Top-down integration

Develop the skeleton of the system and populate it with components.– Bottom-up integration

Integrate infrastructure components then add functional components.– To simplify error localisation, systems should be incrementally

integrated.

Incremental integration testingIncremental integration testing Testing approaches

– Architectural validation Top-down integration testing is better at discovering errors in the system architecture.

– System demonstration Top-down integration testing allows a limited demonstration at an early stage in the development.

– Test implementation Often easier with bottom-up integration testing.

– Test observation Problems with both approaches. Extra code may be required to observe tests.

Release testing– The process of testing a release of a system that will be distributed

to customers.– Primary goal is to increase the supplier’s confidence that the

system meets its requirements.– Release testing is usually black-box or functional testing

Based on the system specification only; Testers do not have knowledge of the system implementation.

T3

T2

T1

T4

T5

A

B

C

D

T2

T1

T3

T4

A

B

C

T1

T2

T3

A

B

Test sequence 1 Test sequence 2 Test sequence 3

Testing guidelinesTesting guidelines– Testing guidelines are hints for the testing team to help them

choose tests that will reveal defects in the system Choose inputs that force the system to generate all error messages; Design inputs that cause buffers to overflow; Repeat the same input or input series several times; Force invalid outputs to be generated; Force computation results to be too large or too small.

Use cases– Use cases can be a basis for deriving the tests for a system. They

help identify operations to be tested and help design the required test cases.

– From an associated sequence diagram, the inputs and outputs to be created for the tests can be identified.

Performance testingPerformance testing– Part of release testing may involve testing the emergent properties

of a system, such as performance and reliability.– Performance tests usually involve planning a series of tests where

the load is steadily increased until the system performance becomes unacceptable.

Stress testing– Exercises the system beyond its maximum design load. Stressing

the system often causes defects to come to light.

– Stressing the system test failure behaviour.. Systems should not fail catastrophically. Stress testing checks for unacceptable loss of service or data.

– Stress testing is particularly relevant to distributed systems that can exhibit severe degradation as a network becomes overloaded. 106

Component testingComponent testing– Component or unit testing is the process of testing individual

components in isolation.– It is a defect testing process.– Components may be:

Individual functions or methods within an object; Object classes with several attributes and methods; Composite components with defined interfaces used to access their

functionality. Object class testing

– Complete test coverage of a class involves Testing all operations associated with an object; Setting and interrogating all object attributes; Exercising the object in all possible states.

– Inheritance makes it more difficult to design object class tests as the information to be tested is not localised.

Interface testingInterface testing– Objectives are to detect faults due to interface errors or invalid assumptions

about interfaces.– Particularly important for object-oriented development as objects are defined by

their interfaces. Interface types

– Parameter interfaces: Data passed from one procedure to another.

– Shared memory interfaces: Block of memory is shared between procedures or functions.

– Procedural interfaces: Sub-system encapsulates a set of procedures to be called by other sub-systems.

– Message passing interfaces: Sub-systems request services from other sub-systems

Interface errors– Interface misuse

A calling component calls another component and makes an error in its use of its interface e.g. parameters in the wrong order.

– Interface misunderstanding A calling component embeds assumptions about the behaviour of the called component which

are incorrect.– Timing errors

The called and the calling component operate at different speeds and out-of-date information is accessed.

Interface testing guidelinesInterface testing guidelines– Design tests so that parameters to a called procedure are at the

extreme ends of their ranges.– Always test pointer parameters with null pointers.– Design tests which cause the component to fail.– Use stress testing in message passing systems.– In shared memory systems, vary the order in which components

are activated. Test case design

– Involves designing the test cases (inputs and outputs) used to test the system.

– The goal of test case design is to create a set of tests that are effective in validation and defect testing.

– Design approaches: Requirements-based testing; Partition testing; Structural testing.

Requirements based testingRequirements based testing– A general principle of requirements engineering is that

requirements should be testable.

– Requirements-based testing is a validation testing technique where you consider each requirement and derive a set of tests for that requirement.

Partition testing– Input data and output results often fall into different classes where

all members of a class are related.

– Each of these classes is an equivalence partition or domain where the program behaves in an equivalent way for each class member.

– Test cases should be chosen from each partition.

Structural testingStructural testing– Sometime called white-box testing.

– Derivation of test cases according to program structure. Knowledge of the program is used to identify additional test cases.

– Objective is to exercise all program statements (not all path combinations).

Path testing– The objective of path testing is to ensure that the set of test cases is

such that each path through the program is executed at least once.– The starting point for path testing is a program flow graph that

shows nodes representing program decisions and arcs representing the flow of control.

– Statements with conditions are therefore nodes in the flow graph.

Test automationTest automation– Testing is an expensive process phase. Testing workbenches

provide a range of tools to reduce the time required and total testing costs.

– Systems such as Junit support the automatic execution of tests.

– Most testing workbenches are open systems because testing needs are organisation-specific.

– They are sometimes difficult to integrate with closed design and analysis workbenches.

Testing workbench adaptation– Scripts may be developed for user interface simulators and

patterns for test data generators.

– Test outputs may have to be prepared manually for comparison.

– Special-purpose file comparators may be developed.

Key points– Testing can show the presence of faults in a system; it cannot

prove there are no remaining faults.– Component developers are responsible for component testing;

system testing is the responsibility of a separate team.– Integration testing is testing increments of the system; release

testing involves testing a system to be released to a customer.– Use experience and guidelines to design test cases in defect

testing.– Interface testing is designed to discover defects in the interfaces of

composite components.– Equivalence partitioning is a way of discovering test cases - all

cases in a partition should behave in the same way.– Structural analysis relies on analysing a program and deriving tests

from this analysis.– Test automation reduces testing costs by supporting the test

process with a range of software tools.