AGILE SoftwareConstruction

Beatrice Åkerblombeatrice@dsv.su.se

2

Outline for the lecture

DesignDesign

PostdeliveryPostdeliveryMaintenanceMaintenance

ImplementationImplementation

DesignDesign

Design

We will look at architectural design, design-by-contract anddesign patterns

PostdeliveryPostdeliveryMaintenanceMaintenanceImplementationImplementation

4

Software architecture

❖ The design process for identifying the sub-systems making up a system and the frameworkfor sub-system control and communication isarchitectural design.

❖ The output of this design process is adescription of the software architecture.

❖ Architectural design:

~ Is done at an early stage of the system designprocess.

~ Represents the link between specification anddesign processes.

~ Often carried out in parallel with somespecification activities.

~ It involves identifying major systemcomponents and their communications.

5

Advantages of explicitarchitecture

❖ Stakeholder communication

~ Architecture may be used as a focus ofdiscussion by system stakeholders.

❖ System analysis

~ Means that analysis of whether the system canmeet its non-functional requirements ispossible.

❖ Large-scale reuse

~ The architecture may be reusable across arange of systems.

6

Architecture and systemcharacteristics

❖ Performance

~ Localise critical operations and minimisecommunications. Use large rather than fine-grain components.

❖ Security

~ Use a layered architecture with critical assetsin the inner layers.

❖ Safety

~ Localise safety-critical features in a smallnumber of sub-systems.

❖ Availability

~ Include redundant components andmechanisms for fault tolerance.

❖ Maintainability

~ Use fine-grain, replaceable components.

7

Architectural conflicts

❖ Using large-grain components improvesperformance but reduces maintainability.

❖ Introducing redundant data improves availabilitybut makes security more difficult.

❖ Localising safety-related features usually meansmore communication, leading to degradedperformance

8

System structuring

❖ Concerned with decomposing the system intointeracting sub-systems.

❖ The architectural design is normally expressedas a block diagram presenting an overview ofthe system structure.

❖ More specific models showing how sub-systemsshare data, are distributed and interface witheach other may also be developed.

9

Box and line diagrams

❖ Very abstract - they do not show the nature ofcomponent relationships nor the externallyvisible properties of the sub-systems.

❖ However, useful for communication withstakeholders and for project planning.

10

Architectural designdecisions

❖ Is there a generic application architecture thatcan be used?

❖ How will the system be distributed?

❖ What architectural styles are appropriate?

❖ What approach will be used to structure thesystem?

❖ How will the system be decomposed intomodules?

❖ What control strategy should be used?

❖ How will the architectural design be evaluated?

❖ How should the architecture be documented?

11

Architectural styles

❖ The architectural model of a system mayconform to a generic architectural model orstyle.

❖ An awareness of these styles can simplify theproblem of defining system architectures.

❖ However, most large systems areheterogeneous and do not follow a singlearchitectural style.

12

Architectural models

❖ Used to document an architectural design.

❖ Static structural model that shows the majorsystem components.

❖ Dynamic process model that shows the processstructure of the system.

❖ Interface model that defines sub-systeminterfaces.

❖ Relationships model such as a data-flow modelthat shows sub-system relationships.

❖ Distribution model that shows how sub-systems are distributed across computers.

13

System organisation

❖ Reflects the basic strategy that is used tostructure a system.

❖ Three organisational styles are widely used:

~ A shared data repository style

~ A shared services and servers style

~ An abstract machine or layered style

14

The repository model

❖ Sub-systems must exchange data. This may bedone in two ways:

~ Shared data is held in a central database orrepository and may be accessed by all sub-systems

~ Each sub-system maintains its own databaseand passes data explicitly to other sub-systems.

❖ When large amounts of data are to be shared,the repository model of sharing is mostcommonly used

15

CASE toolsetarchitecture

16

Repository modelcharacteristics

❖ Advantages

~ Efficient way to share large amounts of data

~ Sub-systems need not be concerned with howdata is produced Centralised managemente.g. backup, security, etc.

~ Sharing model is published as the repositoryschema.

❖ Disadvantages

~ Sub-systems must agree on a repository datamodel. Inevitably a compromise

~ Data evolution is difficult and expensive

~ No scope for specific management policies

~ Difficult to distribute efficiently.

17

Client-server model

❖ Distributed system model which shows howdata and processing is distributed across arange of components.

❖ Set of stand-alone servers which providespecific services such as printing, datamanagement, etc.

❖ Set of clients which call on these services.

❖ Network which allows clients to access servers.

18

Film and picture library

19

Client-servercharacteristics

❖ Advantages

~ Distribution of data is straightforward

~ Makes effective use of networked systems.May require cheaper hardware

~ Easy to add new servers or upgrade existingservers.

❖ Disadvantages

~ No shared data model so sub-systems usedifferent data organisation. Data interchangemay be inefficient

~ Redundant management in each server

~ No central register of names and services - itmay be hard to find out what servers andservices are available.

20

Layered model

❖ Used to model the interfacing of sub-systems.

❖ Organises the system into a set of layers (orabstract machines) each of which provide a setof services.

❖ Supports the incremental development of sub-systems in different layers. When a layerinterface changes, only the adjacent layer isaffected.

❖ However, often artificial to structure systems inthis way.

21

Version managementsystem

22

Modulardecomposition

styles

❖ Styles of decomposing sub-systems intomodules.

❖ No rigid distinction between system organisationand modular decomposition.

23

Modulardecomposition

❖ Another structural level where sub-systems are decomposed intomodules.

❖ Two modular decomposition modelscovered

~ An object model where the system isdecomposed into interacting object;

~ A pipeline or data-flow model wherethe system is decomposed intofunctional modules which transforminputs to outputs.

❖ If possible, decisions aboutconcurrency should be delayed untilmodules are implemented.

24

Object models

❖ Structure the system into a set ofloosely coupled objects with well-defined interfaces.

❖ Object-oriented decomposition isconcerned with identifying objectclasses, their attributes andoperations.

❖ When implemented, objects arecreated from these classes and somecontrol model used to coordinateobject operations.

25

Invoice processingsystem

26

Object modeladvantages

❖ Objects are loosely coupled so theirimplementation can be modified withoutaffecting other objects.

❖ The objects may reflect real-world entities.

❖ OO implementation languages are widely used.

❖ However, object interface changes may causeproblems and complex entities may be hard torepresent as objects.

27

Function-orientedpipelining

❖ Functional transformations processtheir inputs to produce outputs.

❖ May be referred to as a pipe and filtermodel (as in UNIX shell).

❖ Variants of this approach are verycommon.

❖ When transformations are sequential,this is a batch sequential model whichis extensively used in data processingsystems.

❖ Not really suitable for interactivesystems.

28

Invoice processingsystem

29

Pipeline modeladvantages

❖ Supports transformation reuse.

❖ Intuitive organisation for stakeholdercommunication.

❖ Easy to add new transformations.

❖ Relatively simple to implement as either aconcurrent or sequential system.

❖ However, requires a common format for datatransfer along the pipeline and difficult tosupport event-based interaction.

30

Control styles

❖ Are concerned with the control flow betweensub-systems. Distinct from the systemdecomposition model.

❖ Centralised control

~ One sub-system has overall responsibility forcontrol and starts and stops other sub-systems.

❖ Event-based control

~ Each sub-system can respond to externallygenerated events from other sub-systems orthe system’s environment.

31

Centralised control

❖ A control sub-system takes responsibility formanaging the execution of other sub-systems.

❖ Call-return model

~ Top-down subroutine model where controlstarts at the top of a subroutine hierarchy andmoves downwards. Applicable to sequentialsystems.

❖ Manager model

~ Applicable to concurrent systems. One systemcomponent controls the stopping, starting andcoordination of other system processes. Can beimplemented in sequential systems as a casestatement.

32

Call-return model

33

Real-time systemcontrol

34

Broadcast model

❖ Effective in integrating sub-systemson different computers in a network.

❖ Sub-systems register an interest inspecific events.

❖ When these occur, control istransferred to the sub-system whichcan handle the event.

❖ Control policy is not embedded in theevent and message handler. Sub-systems decide on events of interestto them.

❖ However, sub-systems don’t know if orwhen an event will be handled.

35

Selectivebroadcasting

36

Interrupt-drivensystems

❖ Used in real-time systems where fastresponse to an event is essential.

❖ There are known interrupt types witha handler defined for each type.

❖ Each type is associated with amemory location and a hardwareswitch causes transfer to its handler.

❖ Allows fast response but complex toprogram and difficult to validate.

37

Interrupt-drivencontrol

38

Referencearchitectures

❖ Architectural models may be specific to someapplication domain.

❖ Two types of domain-specific model

~ Generic models which are abstractions from anumber of real systems and which encapsulatethe principal characteristics of these systems.

~ Reference models which are more abstract,idealised model. Provide a means ofinformation about that class of system and ofcomparing different architectures.

❖ Generic models are usually bottom-up models --Reference models are top-down models.

39

Referencearchitectures

❖ Reference models are derived from a study ofthe application domain rather than fromexisting systems.

❖ May be used as a basis for systemimplementation or to compare different systems.It acts as a standard against which systems canbe evaluated.

❖ OSI model is a layered model for communicationsystems.

40

OSI reference model

41

Object identification

❖ Identifying objects (or object classes)is the most difficult part of objectoriented design.

❖ There is no 'magic formula' for objectidentification. It relies on the skill,experience and domain knowledge ofsystem designers.

❖ Object identification is an iterativeprocess.

❖ You are unlikely to get it right firsttime.

42

Approaches toidentification

❖ Use a grammatical approach based ona natural language description of thesystem (used in Hood OOD method).

❖ Base the identification on tangiblethings in the application domain.

❖ Use a behavioural approach andidentify objects based on whatparticipates in what behaviour.

❖ Use a scenario-based analysis. Theobjects, attributes and methods ineach scenario are identified.

43

Further objects andobject refinement

❖ Use domain knowledge to identifymore objects and operations

❖ Active or passive objects

~ Objects that are passive act onrequest rather than autonomously.This introduces flexibility at theexpense of controller processingtime.

44

Design models

❖ Design models show the objects andobject classes and relationshipsbetween these entities.

❖ Static models describe the staticstructure of the system in terms ofobject classes and relationships.

❖ Dynamic models describe thedynamic interactions between objects.

45

Examples of designmodels

❖ Sub-system models that show logicalgroupings of objects into coherentsubsystems.

❖ Sequence models that show thesequence of object interactions.

❖ State machine models that show howindividual objects change their statein response to events.

❖ Other models include use-casemodels, aggregation models,generalisation models, etc.

46

Subsystemmodels

❖ Shows how the design is organisedinto logically related groups of objects.

❖ In the UML, these are shown usingpackages - an encapsulationconstruct.

❖ This is a logical model. The actualorganisation of objects in the systemmay be different.

47

Sequence models

❖ Sequence models show the sequenceof object interactions that take place

~ Objects are arranged horizontallyacross the top;

~ Time is represented vertically somodels are read top to bottom;

~ Interactions are represented bylabelled arrows,

~ Different styles of arrow representdifferent types of interaction;

~ A thin rectangle in an object lifelinerepresents the time when the objectis the controlling object in thesystem.

48

Statecharts

❖ Show how objects respond to differentservice requests and the statetransitions triggered by theserequests

~ If object state is Shutdown then itresponds to a Startup() message;

~ In the waiting state the object iswaiting for further messages;

~ If reportWeather () then systemmoves to summarising state;

~ If calibrate () the system moves to acalibrating state;

~ A collecting state is entered when aclock signal is received.

49

Object interfacespecification

❖ Object interfaces have to be specifiedso that the objects and othercomponents can be designed inparallel.

❖ Designers should avoid designing theinterface representation but shouldhide this in the object itself.

❖ Objects may have several interfaceswhich are viewpoints on the methodsprovided.

❖ The UML uses class diagrams forinterface specification but Java mayalso be used.

50

Testing during theDesign Phase

❖ Design must correctly reflectspecifications

❖ Design itself must be correct

❖ Transaction-driven inspections

51

Challenges of theDesign Phase

❖ Design team should not do too much

~ Detailed design should not becomecode

❖ Design team should not do too little

~ It is essential for the design team toproduce a complete detailed design

❖ We need to grow great designers

52

Design by contract

❖ A methodology for designing software❖ Originally in Eiffel❖ Design should include the creation of precise

and checkable interfaces

~ Software entities have obligations to otherentities based upon formalized rules betweenthem

~ Acceptable and unacceptable input values ortypes and their meanings

~ Return values or types and their meanings

~ Error and excxeption conditions values ortypes that can occur, and their meanings

~ Side-effects

~ Preconditions

~ Postconditions

~ Invariants

53

Design patterns –History

❖ Architect Christopher Alexander, late 1970s.

~ “ A Pattern Language”

~ “A Timeless Way of Building”

❖ Quiet until 1987 when patterns appeared againat an OOPSLA conference.

❖ In 1995, Erich Gamma, Richard Helm, RalphJohnson, and John Vlissides published “DesignPatterns: Elements of Reusable Object-OrientedSoftware”

54

Patterns Defined

❖ Patterns are devices that allow programmers toshare knowledge about designs.

❖ When building systems we encounter manyproblems that have occured and will occuragain. Documenting patterns is a way to reusesolutions and possibly share the way to solve aspecific program design problem.

55

Patterns Defined

❖ The general form for documenting patterns isto define items such as:

~ The motivation or context that this patternapplies to.

~ Prerequisites that should be satisfied beforedeciding to use a pattern.

~ A description of the program structure that thepattern will define.

~ List of participants needed to complete apattern.

~ Consequences of using the pattern (bothpositive and negative).

~ Examples

56

Pattern Examles

❖ Delegation pattern

❖ Interface pattern

❖ Proxy pattern

❖ Immutable pattern

ImplementationImplementation

DesignDesign ImplementationImplementation PostdeliveryPostdeliveryMaintenanceMaintenance

58

ImplementationPhase

❖ Programming-in-the-many

❖ Choice of Programming Language

~ Language is usually specified in contract

~ But what if the contract specifies the product isto be implemented in the “most suitable”programming language?

❖ What language should be chosen?

59

Choice ofProgramming

Language (contd)

❖ Example

~ QQQ Corporation has been writing COBOLprograms for over 25 years

~ Over 200 software staff, all with COBOLexpertise

~ What is “most suitable” programminglanguage?

❖ Obviously COBOL

60

Choice ofProgramming

Language (contd)❖ What happens when new language (C++, say) is

introduced

~ New hires

~ Retrain existing professionals

~ Future products in C++

~ Maintain existing COBOL products

~ Two classes of programmers

❖ COBOL maintainers (despised)

❖ C++ developers (paid more)

~ Need expensive software, and hardware to runit

~ 100s of person-years of expertise with COBOLwasted

61

ProgrammingStandards

❖ Can be both a blessing and a curse

❖ Modules of coincidental cohesion arise fromrules like

~ “Every module will consist of between 35 and50 executable statements”

❖  Better

~ “Programmers should consult their managersbefore constructing a module with fewer than35 or more than 50 executable statements”

62

Remarks onProgrammingStandards

❖ No standard can ever be universally applicable

❖ Standards imposed from above will be ignored

❖ Standard must be checkable by machine

63

Remarks onProgramming

Standards (contd)❖ Examples of good programming standards

~ “Nesting of if statements should not exceed adepth of 3, except with prior approval from theteam leader”

~ “Modules should consist of between 35 and 50statements, except with prior approval from theteam leader”

❖ The aim of standards is to make maintenanceeasier

~ If they make development difficult, then theymust be modified

~ Overly restrictive standards arecounterproductive, affecting software quality

64

Comments forevery module

❖ Module name

❖ Brief description of what the module doe

❖ Programmer’s name

❖ Date module was coded

❖ Date module was approved, and by whom

❖ Module parameters

❖ Variable names, in alphabetical order, and uses

❖ Files accessed by this module

65

Comments forevery module

❖ Files updated by this moduleModule i/o

❖ Error handling capabilities

❖ Name of file of test data (for regression testing)

❖ List of modifications made, when, approved bywhom

❖ Known faults, if any

66

Code Walkthroughsand Inspections

❖ Rapid and thorough fault detection

~ Up to 95% reduction in maintenance costs[Crossman, 1982]

67

Implementationand Integration

Phase❖ Common approach: Implementation first,

followed by integration

~ Poor approach

❖ A better way to do it is to combineimplementation and integration methodically.

68

Product with 13Modules

❖ Implementation, Then Integration:

~ Code and test each module separately

~ Link all 13 modules together, test product as awhole

69

Implementation,Then Integration

(contd)❖ Problem 1

~ Stubs and drivers must be written, then thrownaway after module testing is complete

❖ Problem 2

~ Lack of fault isolation

~ A fault could lie in any of 13 modules or 13interfaces

~ In a large product with, say, 103 modules and108 interfaces, there are 211 places where afault might lie

❖ Solution to both problems

~ Combine module and integration testing

~ “Implementation and integration phase”

70

Top-downImplementationand Integration

❖ If module m1 calls module m2, then m1 isimplemented and integrated before m2

❖ One possible top-down ordering is:

~ a, b, c, d, e, f, g, h, i, j, k, l, m

❖ Another possible top-down ordering is:

~ a - [a] b, e, h - [a] c, d, f, i - [a, d] g, j, k, l, m

71

Bottom-upImplementationand Integration

❖ If module m1 calls module m2, then m2 isimplemented and integrated before m1

❖ One possible bottom-up ordering is:  

~ l, m, h, i, j, k, e, f, g, b, c, d, a

❖ Another possible bottom-up ordering is:

~ h, e, b - i, f, c, d - l, m, j, k, g - [b, c, d] a 

PostdeliveryMaintenance

Maintenance:Any change to any component of the product(including the documentation) after it has

passed the acceptance test.

ImplementationImplementation PostdeliveryPostdeliveryMaintenanceMaintenanceDesignDesign

73

Types ofmaintenance

74

Difficulty ofMaintenance

❖ About 67% of the  total cost of aproduct accrues during themaintenance phase

❖ Maintenance is a major income source

❖ Nevertheless, even today manyorganizations assign maintenance to

~ Unsupervised beginners, and

~ Less competent programmers

75

CorrectiveMaintenance

❖ How to minimize regression faults

~ Consult the detailed documentation forproduct as a whole

~ Consult the detailed documentation foreach individual module

❖ What usually happens

~ There is no documentation at all, or

~ The documentation is incomplete, or

~ The documentation is faulty

❖ The programmer must deduce from thesource code itself all the informationneeded to avoid introducing a regressionfault

76

CorrectiveMaintenance

(contd)❖ The programmer changes the source

code

❖ Test that the modification workscorrectly using specially constructed testcaases

❖ Check for regression faults using storedtest data

❖ Add specially constructed test cases tostored test data for future regressiontesting

❖ Document all changes

77

Adaptive andPerfective

Maintenance❖ The maintenance programmer must go

through the phases of

~ Requirements

~ Specifications

~ Design

~ Implementation and integration

❖ Using the existing product as a startingpoint

78

The Rewards ofMaintenance

❖ Maintainers deal with dissatisfied users– if the users were happy, the productwouldn't need maintenance

❖ The user's problems are often caused bythe individuals that developed theproduct, not by the maintainer

❖ Maintenance is despised by manysoftware developers

❖ Unless good maintenance service isprovided, the client will take futuredevelopment business elswhere

79

EnsuringMaintainability

❖ Maintenance is not a one-time effort

❖ We must plan for maintenance duringthe entire software life-cycle

~ Design phase – use information hidingtechniques, etc.

~ Implementation phase – select variablenames that are meaningful to futuremaintenance programmers, etc.

~ Documentation must be complete andcorrect, and reflect current version ofevery module

80

EnsuringMaintainability

(contd)

❖ During the maintenance phase,maintainability must not becompromised

❖ Always be conscious of the inevitablefurther maintenance

❖ Principles leading to maintainability areequally applicable to the maintenancephase itself

81

Size of InheritanceHierarchy

❖ To find out what the result of calling amethod for some specific object does, wemay need to scan the entire inheritancetree

❖ Inheritance tree may be spread over theentire product

❖ A far cry from “independent units”...

82

Consequences ofinheritance

❖ Create new subclass by inheritance

~ Does not affect superclass

~ Does not affect any other subclass

❖ Modify this new subclass

~ Again, no affect

❖ Modify a superclass

~ All descendent subclasses are affected

❖ Inheritance can have positive effect ondevelopment and negative effect onmaintenance

83

Polymorphism andDynamic Binding

❖ Product fails on the invocationmyFile.open ()

~ Which version of open contains thefault?

End of Today’sLecture

Thanks for your attention!