List some possible advantages and disadvantages of building software by plugging together off-the-shelf components.
Advantages:
- Reusing a standard component should be cheaper than developing software from scratch.
- Using off-the-shelf components will allow applications to be developed more quickly.
- Standard components will have been used in many other projects, so their behaviour will be well understood and any bugs are likely to be known.
- Components are pluggable, so it is often possible to replace one component with another providing it has the same interface and behaves in the same way.
Disadvantages:
- Using standard components may restrict what we can do since we have to work with the capability of the components.
- Some additional software is likely to be needed as ‘plumbing’.
- If the interfaces of components are incompatible, adapters will have to be written.
- Creating a system by plugging together off-the-shelf components may not be as simple as it sounds.
What is meant by a ‘provided interface’?
A description of a set of operations a component makes available to other components.
What is meant by a ‘required interface’?
A description of a set of operations a component needs from other components.
Suppose a component is implemented as an instance of a Java class. What corresponds to:
- the provided interface of the component
- the required interface of the component
The provided interface consists of all the public methods in the class.
The required interface consists of all the methods from other classes that the component’s methods make use of.
In object-oriented languages an object belonging to a subclass is allowed to replace an object of the parent class. This is known as substitutability.
In the context of software components, describe a concept that is similar to substitutability.
Components are replaceable: a component can be replaced by another that does the same job.
What would the assume–guarantee contract for a component include and how do the assume and guarantee relate to the component’s provided and required interfaces?
The contract for a component would be:
- the pre- and postcondition of all the operations in the provided interface of the component
- the invariants that apply to any publicly visible properties of the component
- the required interface of the component and all the assumptions of the required interface
- any other assumptions about the environment in which the component will operate.
The assume would be the preconditions of the operations, and items 3 and 4 of the contract above.
The guarantee would be the postcondition of the operations and item 2 of the contract above.
Suppose component X is replaced by component Y, which has different assumptions and guarantees from X. Drawing on your knowledge of design by contract (DbC) suggest what restrictions must apply to the assume and guarantee if Y is to be an acceptable replacement for X. Illustrate your answer with an example.
The assumptions made by Y must be the same as those made by X, or weaker. The guarantee Y makes must be the same as the one X makes, or stronger. In other words Y must not demand more, or deliver less, than X.
For example X might accept up to a million items and promise to process them with 99 per cent accuracy. If Y restricts the maximum to half a million items it is demanding more. If it promises only 90 per cent accuracy it is delivering less.
What are some of the key differences between services and components?
- Communication with components tends to depend on proprietary technologies, which restricts interoperability. Services use standard communication protocols, which allows them to interoperate in a platform- and language-independent way.
- Services are discoverable. Clients can access a repository to find details of available services.
- Components run on computers controlled by the organisation using them and if many organisations use a component it executes in multiple locations. A service in contrast resides on a provider server, typically owned by a different organisation, and executes at a single end-point that all clients communicate with.
- Services should be autonomous and as far as possible independent of other services. So, for example, they do not have a ‘requires’ interface. This is so that they can be more reusable and also more insulated from changes in their operating environment. Not all dependencies can be avoided of course, for example a service may rely on a particular database.
Briefly describe the three kinds of service.
- utility services, which provide some generic functionality useful in a wide range of applications
- business services, which implement a specific business function
- coordination services, which coordinate workflows composed of a number of individual services
What is meant by task-oriented and entity-oriented services?
Task-oriented services are related to business activities (business processes), whereas entity-oriented services are related to business entities (business objects).
What are the advantages of service-oriented architecture (SOA)?
- Agile and flexible response. SOA supports a flexible business model that can respond quickly to changes in customers’ requirements, new business opportunities or competitive threats. Developers can quickly assemble new applications by combining existing services.
- Less duplication. If several parts of a business require the same function, it can be packaged as a service and made available for reuse.
- Integration of legacy applications. Legacy software can be wrapped as a service and made to interoperate with other applications.
- Use of third-party services. Systems can easily incorporate functions, for example credit card validation or online payment, provided as services by external suppliers.
- Language independence. Services written in different languages can interoperate using standard protocols.
From your study of the module, list some other types of reusable solution, apart from design tactics, that are available to software engineers.
- analysis patterns
- requirements patterns
- architectural styles
- design patterns
- language idioms
- components
- services
Write down in your own words what flexibility means in relation to software.
Flexibility is the ability for software to be changed easily.
What concepts introduced in the module relate to flexibility?
- Low coupling so changes don’t have knock-on effects.
- High cohesion so functions that are closely related can get changed together as a unit.
- Hiding implementation behind interfaces and contracts because this keeps coupling as low as possible.
- Use component-based development so components are pluggable/replaceable.
- Delegate details such as object creation to factories so clients don’t need to know them and coupling is kept low.
- Use layers. Low coupling and separation of concerns.
- Wrap legacy software (related to hiding functions behind interfaces).
- Package functions as loosely coupled services.
List as many ways as you can think of to reduce coupling.
- Use components that hide their implementation behind interfaces.
- Use services that hide their implementation behind interfaces.
- Use a layered architecture.
- Use packages to group closely related elements.
- Separate model from presentation.
- Hide legacy software behind wrappers.
- Delegate object creation to factories.
- Use a registry to locate objects or services instead of having to know their location.
In terms of quality attributes, what are tactics?
They are reusable solutions to the problem of achieving particular qualities.
What are the main tactics for performance?
- managing demand
- managing system capacity
- matching resources to demand
What are the main tactics for flexibility?
- minimising coupling
- maximising cohesion
- keeping modules small
- delaying binding as long as possible
