Approaches to software development

Transcription

1 Approaches to software deveopment

2 About this free course This free course is an adapted extract from the Open University course TM354 Software engineering: This version of the content may incude video, images and interactive content that may not be optimised for your device. You can experience this free course as it was originay designed on OpenLearn, the home of free earning from The Open University Approaches to software deveopment There you aso be abe to track your progress via your activity record, which you can use to demonstrate your earning. Copyright 2018 The Open University Inteectua property Uness otherwise stated, this resource is reeased under the terms of the Creative Commons Licence v4.0 Within that The Open University interprets this icence in the foowing way: Copyright and rights faing outside the terms of the Creative Commons Licence are retained or controed by The Open University. Pease read the fu text before using any of the content. We beieve the primary barrier to accessing high-quaity educationa experiences is cost, which is why we aim to pubish as much free content as possibe under an open icence. If it proves difficut to reease content under our preferred Creative Commons icence (e.g. because we can t afford or gain the cearances or find suitabe aternatives), we wi sti reease the materias for free under a persona enduser icence. This is because the earning experience wi aways be the same high quaity offering and that shoud aways be seen as positive even if at times the icensing is different to Creative Commons. When using the content you must attribute us (The Open University) (the OU) and any identified author in accordance with the terms of the Creative Commons Licence. The Acknowedgements section is used to ist, amongst other things, third party (Proprietary), icensed content which is not subject to Creative Commons icensing. Proprietary content must be used (retained) intact and in context to the content at a times. The Acknowedgements section is aso used to bring to your attention any other Specia Restrictions which may appy to the content. For exampe there may be times when the Creative Commons Non- Commercia Shareaike icence does not appy to any of the content even if owned by us (The Open University). In these instances, uness stated otherwise, the content may be used for persona and noncommercia use. We have aso identified as Proprietary other materia incuded in the content which is not subject to Creative Commons Licence. These are OU ogos, trading names and may extend to certain photographic and video images and sound recordings and any other materia as may be brought to your attention. Unauthorised use of any of the content may constitute a breach of the terms and conditions and/or inteectua property aws. We reserve the right to ater, amend or bring to an end any terms and conditions provided here without notice. A rights faing outside the terms of the Creative Commons icence are retained or controed by The Open University. Head of Inteectua Property, The Open University 2 of 56 Monday 18 June 2018

3 Contents Introduction 4 Learning Outcomes 5 1 Software and software engineering What is a system? The nature of software Characteristics of a software system Maintainabiity and other software probems Divide and conquer? Architecture Summary of Section An introduction to software deveopment Software deveopment as an engineering activity The roe of deveopment processes Choosing an appropriate process Traceabiity Summary of Section Modeing in software deveopment Importance of modeing Modes iustrate points of view Introducing the Unified Process Activities and artefacts in the deveopment process Summary of Section 3 53 Concusion 54 References 54 Acknowedgements 56 3 of 56 Monday 18 June 2018

4 Introduction Introduction This free course, Approaches to software deveopment, presents an engineering approach to the deveopment of software systems a software engineering approach, paying particuar attention to issues of software quaity, in terms of both product (what is buit) and process (how we buid it). The materia is organised in a distinctive way. We adopt an object-oriented approach to software deveopment and assume you are famiiar with the basic concepts of objects. This approach uses a fairy standard set of deveopment techniques. We take a broad view, and techniques are discussed fairy independenty of exacty where and when they woud be used. There has aways been debate in the computing industry about just how usefu any particuar deveopment technique is. We beieve that the techniques introduced over the ast 30 years or so, and many others currenty being researched, are important because they address fundamenta issues concerning software quaity. You are probaby aready famiiar with some of the techniques used in this course. Studying these techniques is more about how to use them to address the quaity issues of what you are deveoping and how you are deveoping it, rather than about how to use them in practice. In this course you wi see a precise way of appying techniques, but we wi aso discuss, in parae, a more ight-weight approach to software deveopment. You wi become famiiar with the purpose of utiising these techniques and wi aso deveop an understanding of when their systematic use may or may not be appropriate. With experience you wi be abe to make decisions on which is the right combination of techniques for a particuar project. Software systems are buit to meet requirements. (This eads to the deveoper s mantra, Software must be deivered on time, to budget and to specification. You may know it in another form.) A successfu software project must: resove the diverse and possiby conficting needs of users in a discipined way satisfy the users expectations have been deveoped and deivered in a timey and economica manner be resiient to the changes that wi be introduced during its operationa ifetime demonstrate good overa system quaity. This is a daunting prospect for those deveoping and maintaining software. A centra aim of this course is to give you the inteectua toos to cope with the chaenge. This course provides an introduction to software engineering. Assuming you aready have some experience of software deveopment, some of this materia wi be famiiar to you, though your existing knowedge wi be consoidated and wi begin to be extended to more advanced areas. We discuss some of the ideas that underpin software deveopment in Section 1, and consider the basic activities of software deveopment in Section 2. Section 3 ooks at the roe of modes and modeing anguages, introduces a we-known software deveopment process. This OpenLearn course is an adapted extract from the Open University course TM354 Software engineering. 4 of 56 Monday 18 June 2018

5 Learning Outcomes After studying this course you shoud be abe to: describe the essentia characteristics, and identify, using exampes, the connections between the characteristics of a good software system describe the eements of a basic software deveopment process and iustrate the variety of different ife cyces understand the motivation for, and best practices of, an agie approach to software deveopment expain the benefits of the Unified Modeing Language (UML) as a standard notation for modeing identify the different kinds of mode used in the deveopment of software and describe the reationship between modes, viewpoints and software deveopment.

6 1 Software and software engineering 1 Software and software engineering This section describes the basic characteristics of a good software system, and considers how such software systems may be deveoped. Once buit, software rarey remains static and can change on a reguar basis, so maintaining software is a key activity in software engineering. 1.1 What is a system? The word system is in reguar everyday use. We tak about the socia-security system, the teephone system, computing systems and even The System. The troube is that our everyday anguage is often imprecise, and peope use the same word to mean different things (that is one reason why software deveopment can be an arduous process). The word system is derived from the Greek word meaning to set up. Definition We define a system as an assemby of components that are connected together in an organised way. The term organised is important here. For exampe, it tes us that components are affected by being part of a system. Exampe 1 A pie of od teephones, exchange-switching gear and wiring that are awaiting disposa may once have been a system. But heaped together, they are not a system. Both the organisation and the connections have been ost. A system, therefore, is greater than the sum of its parts, and it has properties that cannot be deduced or predicted by examining any one of its components in isoation (or even a of its components, if they are not organised and connected). From the above exampe, coud you deduce the properties of the teephone system by examining a singe, disconnected teephone (or even a big pie of disconnected teephones)? No, because it no onger works as expected, even though it has not changed physicay (it is not broken). The assemby of components that forms a system does something, it carries out some process. This process wi work on inputs, carry out transformations and produce outputs in order to achieve a goa. If you view your body as a system, it consists of organs, it takes oxygen and food as inputs, and does transformations that keep you aive. As a system, it has a we-defined boundary and a contro mechanism that wi keep it adapting to changes in the environment. Software systems This course is specificay about software systems, systems where software pays a major roe. However, software does not do anything without the hardware where it is instaed and running, and software systems are usuay part of a much wider context that invoves not ony other technica components, but aso peope, organisations and other socia structures. The whoe of a these components is aso known as a sociotechnica 6 of 56 Monday 18 June 2018

7 1 Software and software engineering system. Sociotechnica systems are compex systems that need to be understood as a whoe rather than as a sum of their isoated components. In focusing on the software we wi therefore be ignoring many other components of the whoe system in which software is just a part. However, as a software engineer you wi need to be aware of how software is used and the interactions with hardware, peope and organisations. The popuar press is fu of reports of software faiures, many of which may reate directy to probems with the software but may aso reate to other issues of the wider sociotechnica systems context, as in Exampe 2. Exampe 2 You may find it interesting to read about other exampes of software faiures, such as the Therac 25 software-controed radiation therapy machine, which was responsibe for the death of severa patients in the ate 1980s (Leveson and Turner, 1993). One we-studied case is that of the unmanned European Ariane 5 rocket, which faied on its aunching fight due to a software probem. During the aunch one of its computers stopped working due to a variabe exceeding a imit a data conversion resuted in an overfow software exception. There is some controversy about where the exact bame shoud fa for the probems that occurred, but there is an agreement that they were reated to the reuse of a modue from a previous rocket without proper enforcement of constraints. This case became we known due to the huge expense of the rocket ($500 miion), the amount of time it took to deveop (10 years) and what it meant for European space projects (Lions, 1996). Viewpoints A system can be, and often is, a persona ordering of reaity, the resut of seeing some degree of ordery interconnectedness in some part of the word. So a system can be many different kinds of system simutaneousy, depending on who is studying it and why. Different viewpoints of a system correspond to different sets of users and therefore different purposes. In this sense, it is a subjective ordering of reaity. Exampe 3 A teephone system is a communications system to its users. For the engineers who set it up and maintain it, it is a technica system (that is inked to an empoyment system a job in their view). Simiary someone who designs teephone switches considers each switch as a system in its own right a switch can record usage data as we as route your cas. As Exampe 3 shows, there is a notion of what is incuded within a system, and what is excuded. Naturay this notion depends on the stakehoders invoved in the modeing and deveopment of the system and the viewpoints that they have over it. Identifying the scope of a system is an essentia step in the deveopment process. System boundaries The system boundary is a conceptua ine that divides the system that you want to study from everything ese. It is usefu to think of a system s environment as being made up of those things that are not part of the system, but can either affect the system or be affected 7 of 56 Monday 18 June 2018

8 1 Software and software engineering by it. Exampe 4 takes you into a particuar area of interest, which is known as a domain, to ook at system boundaries and how they can change. Exampe 4 A hospita is a domain where software is put to a variety of uses. A hospita might, for exampe, join together a series of patient-monitoring systems with the database management system that manages medica records, creating a arger system with a different scope. A forward-ooking hospita might wish to go further and add weatherforecasting software. This extension woud aow panners to dea with the variations in fow of patients that arise according to the season. Beds may be aocated and other resources, such as drugs, bought in preparation. Activity 1 Combining systems Aow approximatey 10 minutes. In Exampe 4, we suggested that two systems, for patient monitoring and managing medica records, might be combined into a singe system. Suggest an additiona function that might be possibe with the combined system that woud not have been possibe with either of the two origina systems aone. What can you say about the boundary of the combined system compared with the boundaries of the origina separate systems? Answer Suppose the monitoring system detected that a patient taking a common drug had a heart probem. If the two systems were combined, it woud be possibe to automaticay check whether the heart probem might be due to a known aergy recorded in the patient s record. The boundary of the combined system encompasses a wider scope than the combined boundaries of the separate systems because the combination of patient monitoring and medica records supports a wider range of verifications. 1.2 The nature of software Software is often spoken of as being invisibe or intangibe, and hence is thought of as being different from physica artefacts, which can be measured, touched, broken, and so on. This invisibiity can ead to unreaistic expectations concerning the capabiities of software, which in turn may contribute to some of the myths that surround software and its deveopment, for exampe, that accommodating change is straightforward. Software can, and does, contain errors. There are three important characteristics of software that affect its deveopment and the ikeihood of errors: Maeabiity. Software is easy to change (programmers are often tempted to tweak their code). This maeabiity creates a constant pressure for software to be changed rather than repaced. Every change introduces the possibiity of new errors. Compexity. Software is often compex. Compexity can usuay be recognised, but it is ess easy to define. One item of software can be considered more compex than another if it requires more expanation. Part of that compexity arises from the 8 of 56 Monday 18 June 2018

9 1 Software and software engineering potentia variety of pathways between the components of a system. The number of errors is ikey to depend on the compexity of a system. Size. It is ikey that there wi be more errors in a arge piece of software than in a sma one. You have aready encountered an aspect of the intangibe nature of software if you have programmed in, for exampe, Java. The instructions and statements that you write in Java are transated into bytecode, which you do not see. You might think that, because it is invisibe, software is inherenty more difficut to deveop than a physica artefact. However, various techniques can be used to mode software and its behaviour just as an industria designer uses geometric abstractions and other toos to mode a physica product before it is buit. Activity 2 Probems with software systems Aow approximatey 15 minutes. For each of the three characteristics of software mentioned above, expain why errors might arise in a piece of deveoped software. Answer Maeabiity. As change is easy to make, often changes are introduced without thorough consideration of the fu consequences of each new change introduced. Compexity. The more compex a piece of software becomes, the more chances there are of a change affecting other parts of the software. Size. The greater the number of ines of code in a piece of software, the greater the number of ikey errors. 1.3 Characteristics of a software system Having considered the basic terms system and software, we can move on to the notion of a software system. There are two important questions that we want to address. What characteristics shoud we be ooking for in a software system so that we can deveop one that meets the needs of a its users? What attributes shoud a software system have in order to be of high quaity? We deveop a software system in response to an identified need. For the purpose of this course, we assume a software system is to sove a customer s probem this is not aways the case as software can be deveoped without a specific customer, in the hope that someone wi buy or use it in the future. The contract between customer and deveoper, as provider, incudes the requirements specification, which identifies what the software shoud do and the environment in which it must work. We expect a software system to be usefu, as otherwise it cannot meet the needs of its users. To its users, the user interface represents the software system. No matter what functionaity is contained in the software, it cannot be used to its fu potentia if that interface is difficut to use. We expect a software system to be usabe otherwise the user is hindered in their use of the software to carry out tasks. 9 of 56 Monday 18 June 2018

10 1 Software and software engineering We expect a software system to be reiabe, in that errors are minimised, as otherwise its users wi not be abe to perform those tasks that need its support. Whie deveopers are busy constructing a software system, it is probabe that the users needs wi change. In addition new requirements are ikey to be identified once a software system becomes operationa. It is aso possibe that the deveoper may miss a requirement during the specification process. We expect a software system to be fexibe, because it is important to be abe to change it easiy as time goes by. In addition, a fexibe software system makes it easy to correct errors. In order to operate in its target environment, any design soution to a requirements specification must be turned into machine-readabe code. No matter how usefu or usabe a software system might be, we expect it to be avaiabe in the target environment, offering continuay avaiabe services in the customer s environment. The contract between the customer and the deveoper wi aso incude deivery dates and costs. Whatever process is used, the deveoper is expected to meet such contractua constraints. We coud aso say that the deveoper s working practices affect the avaiabiity of a software system, incuding its initia deivery and any subsequent changes. From the customer s point of view, the software system must be affordabe to buy and maintain. From the deveoper s point of view, there must be a way of keeping contro of a project. Labour resources are the most significant component of a deveoper s contract, and often become the two-edged sword that eads to the success or faiure of a software deveopment project. Software deveopment is concerned with the activities that ead to a usefu software system techniques that wi hep you to define a requirements specification and then produce a design soution to the probem contained in the specification. Activity 3 Good software systems Aow approximatey 20 minutes. (a) (b) (c) What is the defining quaity of a good software system, and what are its main characteristics? How might greater fexibiity make a software system more affordabe over its whoe ife? Give two reasons why a deivered software system might not meet its users needs. Answer (a) (b) (c) A good software system is one that meets its users needs. We can characterise a good software system as usefu, usabe, reiabe, fexibe, avaiabe and affordabe. Users needs wi change over time. The time taken to impement the changes in requirements in a fexibe system is ess than for ess fexibe software. As abour costs are the most significant component of software costs, fexibe software is more affordabe. Software systems are usuay out of date even as they are being deveoped because: some needs are often missed during requirements capture users needs change with time. 10 of 56 Monday 18 June 2018

11 1 Software and software engineering 1.4 Maintainabiity and other software probems A software system shoud be both avaiabe, so that users can decide whether or not it sti meets their needs, and fexibe, so that the deveoper can change it to meet its users needs. Maintenance is the key activity for the coordination and contro of changes to a software system. In order to be maintainabe, a software system shoud be written and documented in such a way that changes can readiy be made. This means that we must take into account the process used to deveop a software system. What the deveoper does during deveopment affects the ease with which it can be maintained. If a change is easy to make, the cost of that change (abour) can be minimised so that the software system continues to be affordabe. The maintainabiity of software is greaty infuenced by how software is designed, written and documented. Probems of maintenance aso appy to software that is purchased as an off-the-shef package, or software that is offered as a service by another provider. Exampe 5 For anything you buy and use, there are costs associated with its purchase and with the maintenance required for its continued operation. For exampe, there are costs associated with buying a car and with its continued operation. As the vehice ages, the costs of maintenance rise, and there comes a point when you have to decide whether it woud be preferabe to buy a new car or continue with the existing one. Perhaps surprisingy, there are simiarities between the maintenance of vehices and the maintenance of software. Legacy systems A significant probem reates to software systems that have been in operation for some time. If a particuar software system continues to meet its users needs, there may be itte or no motivation to repace it, especiay if that software is associated with a critica service within a company. Such systems are caed egacy systems and typicay have the foowing characteristics: od arge deveoped using outdated techniques impemented with od programming anguages critica to the business changed a number of times since their inception difficut to understand because of either a ack of documentation about their interna structure or a ack of experience within the group responsibe for them difficut to maintain because of the above factors. One option woud be to repace an ageing software system with a new one. But the change from od to new can have serious impications for the company invoved. It is not just the users who need to be retrained to use the new software. In some companies the whoe interna organisation is based around their major software systems. Changing these may require a costy company-wide reorganisation to refect the new software systems more accuratey. There is aso the issue of maintaining continuity of service 11 of 56 Monday 18 June 2018

12 1 Software and software engineering during the changeover and the risk that the new and therefore unknown system may not work in contrast, the egacy system is a known quantity. There is an additiona twist that makes the probem of egacy systems worse. Staff turnover may mean that there is no one eft in the company that deveoped the software who understands the egacy system enough to continue maintaining it. Even if those who deveoped the origina software system have not eft, they may be working on other projects or be unwiing to ook after an od system. When faced with the choice of working on a new or an od system, many peope prefer to produce something new. There is every chance that tomorrow s egacy systems are being buit today. We might say that today s soutions are tomorrow s probems. Unsuccessfu software systems Unfortunatey, successfu software systems rarey make the news. Exampe 6 iustrates the kind of faiure that does break through into the pubic domain (in this case, the faiure became a series of headine stories). Exampe 6 In 1992, the London ambuance service commissioned a computer-aided dispatch (CAD) system for getting ambuances and their crews to reported incidents. It was intended to repace an existing paper-based system. There were two notabe faiures of the new system in November 1992 that resuted in severe deays in ambuances reaching certain incidents. The fina report on the system faiures (South West Thames Regiona Heath Authority, 1993) identified a number of major management probems with the project. A technica audit reveaed that the CAD system was incompete and not fuy tested. Its abiity to dea with heavy oads had not been tested and nor had a backup service been tested. There were aso outstanding probems with the accuracy of the information needed to initiate each dispatch (South West Thames Regiona Heath Authority, 1993). The London ambuance service had a software system that was acking in usefuness, usabiity, reiabiity and avaiabiity. This discussion of software probems has probaby given you a rather pessimistic view of software deveopment. You must not forget that many software systems work, and work we, given the fact that they are used in every aspect of modern ife. However, the rate at which the roe of software is evoving is so fast that there must be practices invoved in deveoping software that can cope effectivey with this expansion. Activity 4 Maintainabiity Aow approximatey 20 minutes. (a) (b) (c) Suggest a means of measuring the maintainabiity of a software system. What can we earn from egacy systems about deveoping a good software system? Suggest a reason why egacy systems wi aways be a probem. 12 of 56 Monday 18 June 2018

13 1 Software and software engineering Answer (a) (b) (c) We coud measure the effort required by a deveoper to ocate and impement a given change to a software system. That effort can be cassified in two components the effort needed to ocate and fix errors (bugs), and the effort needed to adapt the software system to meet its users needs. A egacy system may have started out with a the characteristics of a good software system, yet those characteristics may have changed over time, resuting in a ess fexibe and maintainabe product. As change is inevitabe, the right processes shoud be in pace to make change happen in a more controed way. This requires the adoption of standards and documentation conventions that hep decision making on changes and how to introduce them. Any changes need to be we documented so that software is sti understandabe and ess dependent on the peope initiay invoved with deveoping and maintaining the software. The inherent maeabiity of software makes it easy to change. You have aready seen that a egacy system is acking in fexibiity as a resut of the number of changes made to it during its operationa ifetime. (The anaogy with metaworking through maeabiity is usefu. Once a backsmith forms some component, usuay in iron, there is a imit to the number of times that it can be heated, formed and cooed before that component becomes britte and hence iabe to faiure.)this expains why our abiity to bot features and fixes onto a egacy system means that it wi eventuay become too fragie, and it wi become precarious to go any further. The staff issues mentioned in (b) compound these probems. 1.5 Divide and conquer? As computing technoogy has improved, we have tried to construct software systems that can dea with arger and more compex probems. In order to provide such soutions, the software systems themseves have become arger and more compex. Unfortunatey there is a imit to how much we can take in and understand at any one time. The Romans had a strategy caed divide et impera divide and rue. However this covered the idea that it was easier to rue over groups in confict with each other. How can we cope with tricky probems or situations where there is just too much information? The main technique for deaing with such messy situations is decomposition. We can decompose a probem into smaer and smaer parts or chunks unti each one can be comprehended or deat with by an individua. In terms of our earier definition of a system, we are ooking for patterns and/or components within a system and creating interna boundaries around them to identify smaer subsystems, sometimes referred to as modues. We wi expose some form of hierarchy in our attempt to simpify a compex system. The concept of decomposition can aso be appied to the way you deveop a software system. As you wi see in Section 2, you can identify a number of different activities or tasks that an individua or group of individuas might perform in a software deveopment project. An individua can successfuy buid sma software systems because it is possibe for that person to understand a that is needed about the probem and its soution. There is a ong history of individuas attempting to deveop more compex systems so-caed heroic 13 of 56 Monday 18 June 2018

14 1 Software and software engineering programming where success has been ess certain. Sometimes the circumstances resuting from poor panning ead to a situation where it is the ony way out to achieve a piece of workabe software. However there are systems that are so arge and compex, such as those that monitor and contro air traffic, that they cannot be buit by a singe individua. The deveopment of such a software system requires a team of peope whose work must be we coordinated and managed. There must be a we-defined process if they are to produce an appropriate soution a software system that is usefu, usabe, reiabe, fexibe, avaiabe and affordabe. In practice, the process of software deveopment is partitioned to enabe individuas to speciaise in different deveopment activities such as anaysis, design and impementation. Probem and soution By dividing one arge probem into a set of smaer sub-probems, we might expect to reach a point where we can capture, understand and describe each sub-probem. But there are two difficuties. How do we know that each identified sub-probem is any easier to understand and sove than the origina probem? How do we know that a of our sub-probems wi fit back together again and recreate that origina probem? The key to finding sub-probems that you recognise and understand is prior knowedge and experience. As a deveoper, you may know how to create a good design or a good program, but you may not be famiiar with the probem domain. As a deveoper, the probem that you face is in the word outside the computing system, where you aim to provide a soution. The software that you construct can provide soutions to probems because they are connected to the word outside, as iustrated in Figure 1. the probem is in the word outside computing system connections between the word and the computing system Figure 1 Separating a probem from its soution The main issue that you as a deveoper shoud focus on is soving the probems identified by the users, rather than worrying about how to write the program code. When projects fai it may be because of mistakes that were made quite eary on in the design stage, often resuting from poor understanding of the probem domain, not because of what happens at the coding stage. Exampe 7 One way to find out whether you have a good soution to a probem is to consider the kinds of compaint you woud receive from users if your software did not work propery. For 14 of 56 Monday 18 June 2018

15 1 Software and software engineering exampe, suppose someone had made a reservation to stay in a hote but when they arrived, the receptionist tod them that there was no reservation in their name. In another case, they might have reserved rooms for six peope ony to find that there was ony room for one. By doing such thought experiments you may often be abe to spot faws in your soution, athough of course there may aways be situations you have overooked, so you can never be competey certain that your soution is comprehensive. Modues and interfaces In software deveopment, there is a ong history of decomposing a system into smaer modues. This moduarisation is the standard technique for deaing with arge and compex systems. The modues partition the system design or code. Some typica exampes of modues are: whoe programs or appications software ibraries casses, in an object-oriented anguage such as Java. Athough modues may appear as sef-contained eements, because they are a parts of a arger whoe there must aways be reationships between them that need to be taken into account, as Exampe 8 shows. These reationships imit the abiity to change one modue without affecting other modues. Exampe 8 In deveoping a software system for a typica manufacturing business, we can identify a number of possibe subsystems areas for deveopment, such as systems to dea with customers, production, accounts (payments) and deiveries. Whie we might want to treat these areas as independent (as partitions), there are connections between them. For exampe, customers are expected to pay for the goods that they have ordered from the business, and the deiveries department is expected to deiver to the customer. Simiary in the production subsystem, the progress of each customer s order woud be tracked through the factory and on to the deivery of the competed goods to the customer. In genera, we say that the interface to a modue defines how other modues can use that modue. Sometimes, you can define more than one interface for a modue to aow yoursef to be more precise about which services wi be offered to different kinds of cient. An interface is the means of connecting one modue to another. It tes you what to expect about the behaviour of a given modue and what services it wi provide, without teing you how those services wi be provided. For exampe, the interface can define how a bank accounts modue wi respond to queries about the baance of an account or the types of accounts avaiabe. The interface of a modue is a description of a the externay visibe operations and what other modues need to know and do to make use of them, but without any detais of how the operations are impemented internay. From an object-oriented point of view, we say that the interface to the bank accounts modue is an encapsuation of what we know about accounts in a bank. A modue that provides services to other modues may in turn need to use the services of yet other modues. These required services are caed its context dependencies. A 15 of 56 Monday 18 June 2018

16 1 Software and software engineering modue s context dependencies and its interface, incuding any requirements that prospective cients need to meet, form a sort of contract with cients. The contract describes what the modue does and what needs to be true for the modue to do it. Cients can assume that if the necessary conditions are met, the modue wi fufi its specified responsibiities. The concept of an interface heps the deveoper to be more productive. If you can rey on the specification contained in another modue s interface, there is ess for you to understand because you do not need to know how it works. Furthermore, you have a better chance of understanding your part of the software system because you can focus on the things you need to perform your task. A side effect of this added understanding is that you are ess ikey to introduce errors. Furthermore, if a modue is hidden behind an interface it is potentiay repaceabe. Once your software system contains a set of modues that are we understood, each with its own interface and context dependencies, you can consider whether any of them can be reused. It may be that a popuar set of modues is adopted as a standard. The abiity for different computing systems to communicate over a network has deveoped because of the adoption of such a standard set of modues. Contro over the compexity of computer communications has been gained by decomposing the probem into a number of ayers. Each ayer has a we-defined interface through which the ayer above it accesses its services. Abstraction Abstraction is a particuar way of viewing a compex probem to arrive at some usefu decomposition of that probem. The idea is to group together simiar objects or situations and, whie ignoring their differences, focus on one particuar and common aspect of the probem that a these objects/situations possess and/or refect. The key task in deveoping a software system is to decide upon the most suitabe abstractions in the probem domain. We can say that we have achieved a usefu abstraction in a particuar modue if the potentia software cients of that modue do not need to know more than is contained in its interface. For exampe, a dedicated modue to dea with date handing is a usefu abstraction. The fact that it may be compex to impement is immateria to cients that use the services defined in its interface. Couping and cohesion As Exampe 8 shows, deveopers need to dea with the dependencies that arise as a resut of their decomposition of a probem and its soution into a number of modues. We say that a modue of a system depends on another if it is possibe that a change to one modue requires a change to another. For exampe, if a business changes its production methods this may cause a consequent change in the way it cacuates the payments required for the goods it produces. A deveoper must not ony dea with the nature of each dependency but aso the number of dependencies. In software engineering, couping is used to refer to the degree of interdependence among the different parts of a system. It is easy to see that certain systems can have chains of interdependent modues where, for exampe, modue A depends on modue B, which depends on modue C, and so on. In some cases these chains may join up and create a circuar dependency, which is a particuar form of strong (or high) couping. 16 of 56 Monday 18 June 2018

17 1 Software and software engineering Deveopers try to construct oosey couped systems because they are easier to understand and maintain. So a good software system has ow couping, which means that changes to one part are ess ikey to propagate through the rest of the system. A further benefit of ow couping is that components are easy to repace and, potentiay, reuse. Whatever the eve of couping in a software system, it is important to know which modues are couped. If there were no records of the couping between modues, a deveoper woud have to spend time working through the modues to determine whether or not each was affected by a change. The resut woud be a ot of effort spent on checking, even if no changes were needed. Exampe 9 iustrates the danger of having more than one modue making use of common or shared data. Exampe 9 Date handing has aways been a probem for software deveopers. For appications of a certain age, the most appicabe storage format for representing a year was a number between 0 and 99. It made sense because 1966 was stored as 66, 1989 as 89, and so on, therefore ess space was needed to store just two digits. Furthermore, if dates were stored as numbers, tasks that invoved sorting by date order were simpe 22 January 1989 stored as , is after 22 December 1966 stored as Unfortunatey, a number of these appications were sti in use as the year 2000 approached, so every modue in every appication that used the short form of year had to be investigated. A major aspect of the probem in Exampe 9 was that different deveopers had different ways of reading and manipuating the vaues stored in variabes that used the six-figure date format. This increased the effort required to resove the so-caed miennium bug. If deveopers had had a consistent way to manipuate dates that did not rey upon the storage format, the miennium bug woud not have been an issue of concern. Cohesion is a way of describing how cosey the activities within a singe modue are reated to each other. Cohesion is a genera concept for exampe, a department in an organisation might have a cohesive set of responsibiities (accounts, say), or not (misceaneous services). In software systems, a highy cohesive modue performs one task or achieves a singe objective do one thing and do it we is a usefu motto to appy. A modue shoud impement a singe ogica task or a singe ogica entity. Low couping and high cohesion are competing goas. If every modue does ony one thing at a ow eve of abstraction, we might need a compex edifice of highy couped modues to perform an activity at higher eves of abstraction. A deveoper shoud try to achieve the best baance between the eves of couping and cohesion for a software system. For exampe, hotes generate income by etting out their rooms to guests. The concept of room is ikey to be represented somewhere in the software system for reservations for a hote. It may be convenient to use a modue or cass representing the concept of room to coect and store data about the income generated by etting rooms. However, a better soution is to have a separate bi or payment modue, because it is more cohesive, especiay when a hote generates income in other ways, for exampe, from serving meas to peope who are not resident guests. Activity 5 Divide and conquer Aow approximatey 20 minutes. (a) Why might you consider spitting up a arge project into smaer chunks? 17 of 56 Monday 18 June 2018

18 1 Software and software engineering (b) (c) (d) (e) (f) (g) (h) (i) (j) How does the compexity of a software system affect the maintenance task? What is a modue? Why does it hep to have ow couping in a software system? Give exampes of the kinds of information that woud be vauabe when considering a change to a given modue. What are the context dependencies of a modue? How do they reate to a modue s interface? What are the benefits of using modues with defined interfaces? Why does it hep to have high cohesion in the modues of a software system? What characteristics shoud a modue dispay that wi hep to ensure that it is easy and cheap to deveop and maintain, and that errors are kept to a minimum? Why is it important to achieve a baance between couping and cohesion? Answer (a) (b) (c) (d) (e) (f) (g) There is a imit to how much one person can understand at any one time. So there is a imit to the size of a software system that any one person can dea with. By spitting a arge project into smaer chunks, it is possibe to identify a number of more manageabe tasks for those invoved. It is essentia to be abe to make a change to a software system without having to know a about that system. Each change becomes difficut when the fow of contro and dependencies within programs are compex. The greater the number and nature of the dependencies, the harder it is to maintain a software system. A modue is any identifiabe part of a software system that is considered separatey. For exampe, modues may be subroutines (in a procedura anguage equivaent to methods), casses (in an object-oriented anguage), ibrary functions or other constructs that may be treated independenty. With ow couping, there are few dependencies between modues. Therefore changes made to one part (one or more modues) of a software system are ess ikey to propagate throughout the whoe system. (A cear record of the dependencies between modues heps you to predict the impact of a proposed change to a software system.) There are two kinds of information that contribute to the anaysis of a proposed change: Which modues are cients of the modue in question? This information indicates how far a change may propagate through the software system. What assumptions have been made in cient modues of the modue in question? An understanding of the expected services of a modue wi hep assess the risks associated with a particuar change. The context dependencies for a modue are the services of other modues that the modue needs in order to work correcty. You can express the context dependencies for a modue in terms of other interfaces. In effect, you can express the responsibiities of a modue in terms of its interface and context dependencies. If the context provides the services that the modue needs and cients meet any conditions specified in the interface, the modue can guarantee the provision of the services described in its interface. The benefits are as foows: 18 of 56 Monday 18 June 2018

19 1 Software and software engineering (h) (i) (j) Deveopers wi need to know ony about the modue s interface (its syntax and what it requires and achieves its semantics), not how it provides those services. Consequenty deveopers can be more productive. Deveopers can understand aspects of the software system more thoroughy, so fewer bugs wi be introduced. It shoud be easier to find bugs, as irreevant modues are avoided. The possibiity of modue reuse is increased once it is known what that modue provides and requires. With high cohesion, a modue carries out a sensibe set of operations or activities. Ideay high cohesion impies just one major abstraction per modue. The interface abstracts away from what a deveoper must know in order to use a modue. This makes it easier for deveopers to understand the purpose of the modue and how to use it. In addition high cohesion tends to make a modue more reusabe in other appications, because it provides a set of operations that sit naturay together. A modue shoud have ow couping and high cohesion, represent a good abstraction, and have a we-defined interface that is an encapsuated abstraction of a we-understood concept. In constructing a system, you may have a choice between a smaer set of oosey couped, ess cohesive modues, or a arger set of tighty couped, more cohesive modues. In the former case each modue may be difficut to understand, whie in the atter case the reationships between them may be over-compex. You need to strike an appropriate baance. 1.6 Architecture In software deveopment the term architecture is associated with the overa structure of a software system or, at a higher eve, a famiy of software systems. For this course, we wi adopt the foowing definition, taken from Bass et a (2012). The software architecture of a system is the set of structures needed to reason about the system, which comprise software eements, reations among them, and properties of both. It is important to understand the software architecture because it tes the deveoper, among other interested parties, about the overa shape of the actua or proposed software system. It expains how the deveopment team can use various technoogies to construct or assembe a software system. Software requirements come in a shapes and sizes, so deveopers need to consider what the most appropriate process to deveop an architecture is for a given context. Choosing a software architecture, or at east part of it, is one of the eariest decisions a deveopment team has to make. There is aways something that can be caed a software architecture, whatever software system is being deveoped. Even a basic software system has an architecture. Architecture serves as a main guide for deveopers but it is aso of importance to other stakehoders in software deveopment, a of whom wi have different concerns about the software. For exampe: 19 of 56 Monday 18 June 2018