Approaches to software development
Approaches to software development

Start this free course now. Just create an account and sign in. Enrol and complete the course for a free statement of participation or digital badge if available.

Free course

Approaches to software development

Modules and interfaces

In software development, there is a long history of decomposing a system into smaller modules. This modularisation is the standard technique for dealing with large and complex systems. The modules partition the system design or code. Some typical examples of modules are:

  • whole programs or applications
  • software libraries
  • classes, in an object-oriented language such as Java.

Although modules may appear as self-contained elements, because they are all parts of a larger whole there must always be relationships between them that need to be taken into account, as Example 8 shows.

These relationships limit the ability to change one module without affecting other modules.

Example 8

In developing a software system for a typical manufacturing business, we can identify a number of possible subsystems – areas for development, such as systems to deal with customers, production, accounts (payments) and deliveries. While we might want to treat these areas as independent (as partitions), there are connections between them. For example, customers are expected to pay for the goods that they have ordered from the business, and the deliveries department is expected to deliver to the customer. Similarly in the production subsystem, the progress of each customer’s order would be tracked through the factory and on to the delivery of the completed goods to the customer.

In general, we say that the interface to a module defines how other modules can use that module. Sometimes, you can define more than one interface for a module to allow yourself to be more precise about which services will be offered to different kinds of client.

An interface is the means of connecting one module to another. It tells you what to expect about the behaviour of a given module and what services it will provide, without telling you how those services will be provided. For example, the interface can define how a bank accounts module will respond to queries about the balance of an account or the types of accounts available.

The interface of a module is a description of all the externally visible operations and what other modules need to know and do to make use of them, but without any details of how the operations are implemented internally. From an object-oriented point of view, we say that the interface to the bank accounts module is an encapsulation of what we know about accounts in a bank.

A module that provides services to other modules may in turn need to use the services of yet other modules. These required services are called its context dependencies. A module’s context dependencies and its interface, including any requirements that prospective clients need to meet, form a sort of contract with clients. The contract describes what the module does and what needs to be true for the module to do it. Clients can assume that if the necessary conditions are met, the module will fulfil its specified responsibilities.

The concept of an interface helps the developer to be more productive. If you can rely on the specification contained in another module’s interface, there is less 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 less likely to introduce errors. Furthermore, if a module is hidden behind an interface it is potentially replaceable.

Once your software system contains a set of modules that are well understood, each with its own interface and context dependencies, you can consider whether any of them can be reused. It may be that a popular set of modules is adopted as a standard.

The ability for different computing systems to communicate over a network has developed because of the adoption of such a standard set of modules. Control over the complexity of computer communications has been gained by decomposing the problem into a number of layers. Each layer has a well-defined interface through which the layer above it accesses its services.

TM354_1

Take your learning further

Making the decision to study can be a big step, which is why you'll want a trusted University. The Open University has 50 years’ experience delivering flexible learning and 170,000 students are studying with us right now. Take a look at all Open University courses.

If you are new to University-level study, we offer two introductory routes to our qualifications. You could either choose to start with an Access module, or a module which allows you to count your previous learning towards an Open University qualification. Read our guide on Where to take your learning next for more information.

Not ready for formal University study? Then browse over 1000 free courses on OpenLearn and sign up to our newsletter to hear about new free courses as they are released.

Every year, thousands of students decide to study with The Open University. With over 120 qualifications, we’ve got the right course for you.

Request an Open University prospectus371