Page 215 -

198 Chapter 7 Design and implementation

for embedded systems, where the target is usually a single computer. However, for
distributed systems, you need to decide on the specific platforms where the compo-
nents will be deployed. Issues that you have to consider in making this decision are:

1. The hardware and software requirements of a component If a component is
designed for a specific hardware architecture, or relies on some other software
system, it must obviously be deployed on a platform that provides the required
hardware and software support.

2. The availability requirements of the system High-availability systems may
require components to be deployed on more than one platform. This means that,
in the event of platform failure, an alternative implementation of the component
is available.
3. Component communications If there is a high level of communications traffic
between components, it usually makes sense to deploy them on the same plat-
form or on platforms that are physically close to one other. This reduces
communications latency, the delay between the time a message is sent by one
component and received by another.

You can document your decisions on hardware and software deployment using UML
deployment diagrams, which show how software components are distributed across
hardware platforms.
If you are developing an embedded system, you may have to take into account
target characteristics, such as its physical size, power capabilities, the need for real-
time responses to sensor events, the physical characteristics of actuators, and its real-
time operating system. I discuss embedded systems engineering in Chapter 20.

7.4 Open source development

Open source development is an approach to software development in which the
source code of a software system is published and volunteers are invited to partici-
pate in the development process (Raymond, 2001). Its roots are in the Free Software
Foundation (http://www.fsf.org), which advocates that source code should not be
proprietary but rather should always be available for users to examine and modify as
they wish. There was an assumption that the code would be controlled and devel-
oped by a small core group, rather than users of the code.
Open source software extended this idea by using the Internet to recruit a much
larger population of volunteer developers. Many of them are also users of the code.
In principle at least, any contributor to an open source project may report and fix
bugs and propose new features and functionality. However, in practice, successful
open source systems still rely on a core group of developers who control changes to
the software.