UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

Architectural design

Once the interactions between the software system and the system’s environment
have been defined, you use this information as a basis for designing the system
architecture. You identify the major components that make up the system and their
interactions, and then may organize the components using an architectural pattern.

The high-level architectural design for the weather station software is shown in
Figure 23. The weather station is composed of independent subsystems that
communicate by broadcasting messages on a common infrastructure, shown as the
Communication link in Figure 23. Each subsystem listens for messages on that
infrastructure and picks up the messages that are intended for them.

Figure 23: High-level architecture of the weather station

Figure 24 shows the architecture of the data collection subsystem, which is

included in Figure 23. The Transmitter and Receiver objects are concerned
with managing communications and the Weather Data object encapsulates the
information that is collected from the instruments and transmitted to the weather
information system.
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

Figure 24: Architecture of data collection system

Architectural Design Decisions

Architectural design is a creative process where you try to establish a system
organ- isation that will satisfy the functional and non-functional system
requirements.
Because it is a creative process, the activities within the process differ
radically depending on the type of system being developed, the background
and experience of the sys- tem architect, and the specific requirements for
the system.
It is therefore more useful to think of the architectural design process from a
decision perspective rather than from an activity perspective. During the
architectural design process, system architects have to make a number of
fundamental decisions that profoundly affect the system and its development
process.

Based on their knowledge and experience, they have to answer the

following fundamental questions:

1. Is there a generic application architecture that can act as a template

for the sys- tem that is being designed?
2. How will the system be distributed across a number of processors?
3. What architectural style or styles are appropriate for the system?
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

4. What will be the fundamental approach used to structure the system?

5. How will the structural units in the system be decomposed into modules?
6. What strategy will be used to control the operation of the units in the
system?
7. How will the architectural design be evaluated?
8. How should the architecture of the system be documented?

Although each software system is unique, systems in the same application domain
often have similar architectures that reflect the fundamental domain concepts.

These application architectures can be fairly generic, such as the architecture of

information management systems, or much more specific.

For example, application product lines are applications that are built around a core
architecture with variants that satisfy specific customer requirements. When
designing a system architecture, you have to decide what your system and broader
application classes have in common, and decide how much knowledge from these
application architectures you can reuse.

The architecture of a software system may be based on a particular

architectural model or style. An architectural style is a pattern of system
organisation (Garlan and Shaw, 1993) such as a client–server organisation
or a layered architecture. An awareness of these styles, their applications,
and their strengths and weaknesses is important.

However, the architectures of most large systems do not conform to a

single style. Different parts of the system may be designed using different
architectural styles. In some cases, the overall system architecture may be
a composite architecture that is created by combining different
architectural styles.

Garlan and Shaw’s notion of an architectural style covers the next three
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

design questions. You have to choose the most appropriate structure, such
as client–server or layered structuring,that will allow you to meet the
system requirements. To decompose structural system units into modules,
you decide on the strategy for decomposing sub- systems into their
components or modules.

The approaches that you can use allow different types of architecture to be
implemented. Finally, in the control modelling process, you make
decisions about how the execution of sub-systems is controlled. You
develop a general model of the control relationships between the parts of
the system established.

Evaluating an architectural design is difficult because the true test of an

architecture is in how well it meets its functional and non-functional
requirements after it has been deployed. However, in some cases, you can
do some evaluation by com- paring your design against reference or
generic architectural models.

The product of the architectural design process is an architectural design

document. This may include a number of graphical representations of the
system along with associated descriptive text. It should describe how the
system is structured into sub-systems, the approach adopted and how each
sub-system is structured into modules.

The graphical models of the system present different perspectives on the

architecture. Architectural models that may be developed may include:

1. A static structural model that shows the sub-systems or components

that are to be developed as separate units.
2. A dynamic process model that shows how the system is organised
into processes at run-time. This may be different from the static
model.
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

3. An interface model that defines the services offered by each sub-

system through its public interface.
4. Relationship models that show relationships, such as data flow,
between the sub-systems.
5. A distribution model that shows how sub-systems may be
distributed across computers.
Architectural views
Each architectural model only shows one view or perspective of the system. It
might show how a system is decomposed into modules, how the run-time processes
interact or the different ways in which system components are distributed across a
network. For both design and documentation, you usually need to present multiple
views of the software architecture.
4+1 view model of software architecture:

• A logical view, which shows the key abstractions in the system as objects
or object classes.
• A process view, which shows how, at run-time, the system is composed of
interacting processes.
• A development view, which shows how the software is decomposed for
development.
• A physical view, which shows the system hardware and how software
components are distributed across the processors in the system.
• Related using use cases or scenarios (+1).

Architectural patterns
Patterns are a means of representing, sharing and reusing knowledge. An
architectural pattern is a stylized description of a good design practice, which has
been tried and tested in different environments. Patterns should include information
about when they are and when the are not useful. Patterns may be represented using
tabular and graphical descriptions.
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

System Organisation
The organisation of a system reflects the basic strategy that is used to
structure a system. You have to make decisions on the overall organisational
model of a sys- tem early in the architectural design process.

The system organisation may be directly reflected in the sub-system structure.

However, it is often the case that the sub-system model includes more detail
than the organisational model, and there is not always a simple mapping
from sub-systems to organisational structure.

In this section, I discuss three organisational styles that are very widely
used. These are a shared data repository style, a shared services and servers
style and an abstract machine or layered style where the system is organised
as a tier of functional layers.

These styles can be used separately or together. For example, a sys- tem may
be organised around a shared data repository but may construct layers around
this to present a more abstract view of the data.

The Repository Model

Sub-systems making up a system must exchange information so that they
can work together effectively. There are two fundamental ways in which
this can be done.

1. All shared data is held in a central database that can be accessed by all
sub- systems. A system model based on a shared database is sometimes called a repos- itory
model.
2. Each sub-system maintains its own database. Data is interchanged with
other sub-systems by passing messages to them.

The majority of systems that use large amounts of data are organised around
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

a shared database or repository. This model is therefore suited to

applications where data is generated by one sub-system and used by another.

Figure 11.2 The Design Code

architecture of an editor
integrated CASE toolset

Design Project Program

editor

Design Report

Figure 11.2 The architecture of an integrated CASE toolset system include

command and control systems, management information systems, CAD
systems and CASE toolsets.

Figure 11.2 is an example of a CASE toolset architecture based on a shared

repository. The first shared repository for CASE tools was probably
developed in the early 1970s by a UK company called ICL to support their
operating system development (McGuffin, et al., 1979).

This model became more widely known when Buxton (Buxton, 1980) made
proposals for the Stoneman environment to support the development of
systems written in Ada. Since then, many CASE toolsets have been
developed around a shared repository.

The advantages and disadvantages of a shared repository are as follows:

1. It is an efficient way to share large amounts of data. There is no need to

transmit data explicitly from one sub-system to another.
2. However, sub-systems must agree on the repository data model.
Inevitably, this is a compromise between the specific needs of each tool.
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

Performance may be adversely affected by this compromise. It may be

difficult or impossible to integrate new sub-systems if their data models do
not fit the agreed schema.
3. Sub-systems that produce data need not be concerned with how that data
is used by other sub-systems.
4. However, evolution may be difficult as a large volume of information is
generated according to an agreed data model. Translating this to a new
model will certainly be expensive; it may be difficult or even impossible.
5. Activities such as backup, security, access control and recovery from
error are centralised. They are the responsibility of the repository manager.
Tools can focus on their principal function rather than be concerned with
these issues.
6. However, different sub-systems may have different requirements for
security, recovery and backup policies. The repository model forces the
same policy on all sub-systems.

7. The model of sharing is visible through the repository schema. It is

straight- forward to integrate new tools given that they are compatible with
the agreed data model.
8. However, it may be difficult to distribute the repository over a number of
machines. Although it is possible to distribute a logically centralised
repository, there may be problems with data redundancy and inconsistency.

In the above model, the repository is passive and control is the responsibility
of the sub-systems using the repository. An alternative approach has been
derived for AI systems that use a ‘blackboard’ model, which triggers sub-
systems when particular data become available. This is appropriate when the
form of the repository data is less well structured. Decisions about which
tool to activate can only be made when the data has been analysed. This
model is described by Nii (Nii, 1986), and Bosch (Bosch, 2000) includes a
good discussion of how this style relates to system quality attributes.

The Layered Model

 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

The layered model of an architecture (sometimes called an abstract machine

model) organises a system into layers, each of which provide a set of
services. Each layer

Figure 11.4 Layered model of a

version management system

Figure 11.4 Layered model of a version management system can be thought

of as an abstract machine whose machine language is defined by the
services provided by the layer.

This ‘language’ is used to implement the next level of abstract machine. For
example, a common way to implement a language is to define an ideal
‘language machine’ and compile the language into code for this machine.

A further translation step then converts this abstract machine code to real
machine code.

An example of a layered model is the OSI reference model of network

proto- cols (Zimmermann, 1980), Another influential example was proposed
by Buxton (Buxton, 1980), who suggested a three-layer model for an Ada
Programming Support Environment (APSE).

Figure 11.4 reflects the APSE structure and shows how a configuration
management system might be integrated using this abstract machine
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

approach.

The configuration management system manages versions of objects and

provides general configuration management facilities, as discussed in
Chapter 29.

To sup- port these configuration management facilities, it uses an object

management sys- tem that provides information storage and management
services for configuration items or objects.

This system is built on top of a database system to provide basic data

storage and services such as transaction management, rollback and recovery,
and access control. The database management uses the underlying operating
sys- tem facilities and file store in its implementation.

The layered approach supports the incremental development of systems. As

a layer is developed, some of the services provided by that layer may be
made avail- able to users. This architecture is also changeable and portable.
So long as its interface is unchanged, a layer can be replaced by another,
equivalent layer.

Furthermore, when layer interfaces change or new facilities are added to a

layer, only the adjacent layer is affected. As layered systems localise
machine dependencies in inner layers, this makes it easier to provide multi-
platform implementations of an application system. Only the inner,
machine-dependent layers need be reimplemented to take account of the
facilities of a different operating system or database.

A disadvantage of the layered approach is that structuring systems in this

way can be difficult. Inner layers may provide basic facilities, such as file
management, that are required at all levels.

Services required by a user of the top level may there- fore have to ‘punch
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

through’ adjacent layers to get access to services that are pro- vided several
levels beneath it. This subverts the model, as the outer layer in the system
does not just depend on its immediate predecessor.

Performance can also be a problem because of the multiple levels of

command interpretation that are sometimes required. If there are many
layers, a service request from a top layer may have to be interpreted several
times in different layers before it is processed.

To avoid these problems, applications may have to communicate directly

with inner layers rather than use the services provided by the adjacent layer.

Client–server architectures

I have already introduced the concept of client–server architectures in

Chapter 11. In a client–server architecture, an application is modelled as a
set of services that are pro- vided by servers and a set of clients that use
these services (Orfali and Harkey, 1998).

Clients need to be aware of the servers that are available but usually do not
know of the existence of other clients. Clients and servers are separate
processes, as shown in Figure 12.2, which is a logical model of a distributed
client–server architecture.

Several server processes can run on a single server processor so there is not
necessarily a 1:1 mapping between processes and processors in the system.
Figure 12.3 shows the physical architecture of a system with six client
computers and two server computers. These can run the client and server
processes shown in Figure 12.2.

When I refer to clients and servers, I mean these logical processes rather
than the physical computers on which they execute. The design of client–
server systems should reflect the logical structure of the application that is
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

being developed.

One way to look at an application is illustrated in Figure 12.4, which shows

an application structured into three layers. The presentation layer is
concerned with presenting information to the user and with all user
interaction. The application processing layer is concerned with
implementing the logic of the application, and the data management layer is
concerned with all database operations.

In centralised systems, these need not be clearly separated. However, when

you are designing a distributed system, you should make a clear distinction
between them, as it then becomes possible to distribute each layer to a
different computer.

c2 c3 c4
Client process

c1

c5

c9 Server process

c6
c7 c8

Figure 12.2 A client–server system

Figure 12.3 Computers in a client–server network

The simplest client–server architecture is called a two-tier client–server

architecture, where an application is organised as a server (or multiple identical
servers) and a set of clients. As illustrated in Figure 12.5, two-tier client–server
architectures can take two forms:

1. Thin-client model In a thin-client model, all of the application processing and

data management is carried out on the server. The client is simply responsible for
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

running the presentation software.

2. Fat-client model In this model, the server is only responsible for data
management. The software on the client implements the application logic and the
interactions with the system user.

A thin-client, two-tier architecture is the simplest approach to use when centralised

legacy systems, as discussed in Chapter 2, are evolved to a client–server
architecture.

c1 c2

Server computer

Network

Client computer

c10, c11, c12

Pipe and Filter Architecture

• Functional transformations process their inputs to produce outputs.
• May be referred to as a pipe and filter model (as in UNIX shell).
• Variants of this approach are very common. When transformations are
sequential, this is a batch sequential model which is extensively used in
data processing systems.
• Not really suitable for interactive systems.
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

Name Pipe and filter

The processing of the data in a system is organized so that each
processing component (filter) is discrete and carries out one type of
Description
data transformation. The data flows (as in a pipe) from one
component to another for processing.
Commonly used in data processing applications (both batch- and
When used transaction-based) where inputs are processed in separate stages to
generate related outputs.
Easy to understand and supports transformation reuse. Workflow
style matches the structure of many business processes. Evolution by
Advantages
adding transformations is straightforward. Can be implemented as
either a sequential or concurrent system.
The format for data transfer has to be agreed upon between
communicating transformations. Each transformation must parse its
Disadvantages input and unparse its output to the agreed form. This increases
system overhead and may mean that it is impossible to reuse
functional transformations that use incompatible data structures.
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

DESIGN AND IMPLEMENTATION

Object-oriented design using the UML

An object-oriented system is made up of interacting objects that maintain their
own local state and provide operations on that state. The representation of the
state is private and cannot be accessed directly from outside the object. Object-
oriented design processes involve designing object classes and the relationships
between these classes.

These classes define the objects in the system and their interactions. When the
design is realized as an executing program, the objects are created dynamically
from these class definitions.

Object-oriented systems are easier to change than systems developed using

functional approaches. Objects include both data and operations to manipulate
that data. They may therefore be understood and modified as stand-alone entities.
Changing the implementation of an object or adding services should not affect
other system objects.

Because objects are associated with things, there is often a clear mapping between
real-world entities (such as hardware components) and their controlling objects in
the system. This improves the understandability, and hence the maintainability, of
the design.

To develop a system design from concept to detailed, object-oriented design, there

are several things that you need to do:
• Understand and define the context and the external interactions with the
system.
• Design the system architecture.
• Identify the principal objects in the system.
• Develop design models.
• Specify interfaces.

System context and interactions

 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

The first stage in any software design process is to develop an understanding of

the relationships between the software that is being designed and its external
environment. This is essential for deciding how to provide the required system
functionality and how to structure the system to communicate with its
environment. Understanding of the context also lets you establish the boundaries
of the system.

System context models and interaction models present complementary views of

the relationships between a system and its environment:

• A system context model is a structural model that demonstrates the other

systems in the environment of the system being developed.
• An interaction model is a dynamic model that shows how the system
interacts with its environment as it is used.
•
The context model of a system may be represented using associations.
Associations simply show that there are some relationships between the entities
involved in the association. The nature of the relationships is now specified. You
may therefore document the environment of the system using a simple block
diagram, showing the entities in the system and their associations.

This is illustrated in Figure 21, which shows that the systems in the environment
of each weather station are a weather information system, an onboard satellite
system, and a control system. The cardinality information on the link shows that
there is one control system but several weather stations, one satellite, and one
general weather information system.
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

Figure 21: System context for the weather station

When you model the interactions of a system with its environment you should use
an abstract approach that does not include too much detail. One way to do this is
to use a use case model. The use case model for the weather station is shown in
Figure 22.

This shows that the weather station interacts with the weather information system
to report weather data and the status of the weather station hardware. Other
interactions are with a control system that can issue specific weather station
control commands.

Object class identification

 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

There have been various proposals made about how to identify object classes in
object-oriented systems:

• Use a grammatical analysis of a natural language description of the system to

be constructed.
• Use tangible entities (things) in the application domain such as aircraft,
roles such as manager or doctor, events such as requests, interactions such
as meetings, locations such as offices, organizational units such as
companies, and so on.
• Use a scenario-based analysis where various scenarios of system use are
identified and analyzed in turn. As each scenario is analyzed, the team
responsible for the analysis must identify the required objects, attributes,
and operations.

In the wilderness weather station, object identification is based on the tangible

hardware in the system. Five object classes are shown in Figure 25. The Ground
thermometer, Anemometer, and Barometer objects are application domain
objects, and the Weather Station and Weather Data objects have been identified
from the system description and the scenario (use case) description:

• The Weather Station object class provides the basic interface of the weather
station with its environment. I use a single object class to encapsulate all of
these interactions, but in other designs you could design the system
interface as several different classes.

• The Weather Data object class is responsible for processing the report
weather command. It sends the summarized data from the weather station
instruments to the weather information system.

• The Ground thermometer, Anemometer, and Barometer object classes are

directly related to instruments in the system. They reflect tangible hardware
entities in the system and the operations are concerned with controlling that
hardware.

• These objects operate autonomously to collect data at the specified

 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

frequency and store the collected data locally. This data is delivered to the
Weather Data object on request.

You use knowledge of the application domain to identify other objects,

attributes, and services. We know that weather stations are often located in
remote places and include various instruments that sometimes go wrong.
Instrument failures should be reported automatically.

This implies that you need attributes and operations to check the correct
functioning of the instruments. There are many remote weather stations so each
weather station should have its own identifier.

Figure 25: Weather station objects

Design Models

Design or system models, show the objects or object classes in a system. They
also show the associations and relationships between these entities. These models
are the bridge between the system requirements and the implementation of a
system.
They have to be abstract so that unnecessary detail doesn’t hide the relationships
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

between them and the system requirements.

When you use the UML to develop a design, you will normally develop two kinds
of design model:
• Structural models: which describe the static structure of the system using
object classes and their relationships. Important relationships that may be
documented at this stage are generalization (inheritance) relationships,
uses/used-by relationships, and composition relationships.

• Dynamic models: which describe the dynamic structure of the system and
show the interactions between the system objects. Interactions that may be
documented include the sequence of service requests made by objects and
the state changes that are triggered by these object interactions.

In the early stages of the design process, I think there are three models that are
particularly useful for adding detail to use case and architectural models:

• Subsystem models: which that show logical groupings of objects into

coherent subsystems. These are represented using a form of class diagram
with each subsystem shown as a package with enclosed objects. Subsystem
models are static (structural) models.

• Sequence models: which show the sequence of object interactions. These

are represented using a UML sequence or a collaboration diagram.
Sequence models are dynamic models.

• State machine model: which show how individual objects change their
state in response to events. These are represented in the UML using state
diagrams. State machine models are dynamic models.
A subsystem model is a useful static model as it shows how a design is organized
into logically related groups of objects. I have already shown this type of model in
Figure 23 to show the subsystems in the weather mapping system.

Sequence models are dynamic models that describe, for each mode of interaction,
the sequence of object interactions that take place.
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

When documenting a design, you should produce a sequence model for each
significant interaction. Figure 26 is an example of a sequence model, shown as a
UML sequence diagram.

This diagram shows the sequence of interactions that take place when an external
system requests the summarized data from the weather station. You read sequence
diagrams from top to bottom:

• The SatComms object receives a request from the weather information

system to collect a weather report from a weather station. It acknowledges
receipt of this request. The stick arrowhead on the sent message indicates
that the external system does not wait for a reply but can carry on with
other processing.

• SatComms sends a message to WeatherStation, via a satellite link, to create

a summary of the collected weather data. Again, the stick arrowhead
indicates that SatComms does not suspend itself waiting for a reply.

• WeatherStation sends a message to a Commslink object to summarize the

weather data. In this case, the squared-off style of arrowhead indicates that
the instance of the WeatherStation object class waits for a reply.

• Commslink calls the summarize method in the object WeatherData and waits
for a reply.
• The weather data summary is computed and returned to WeatherStation via
the Commslink object.

• WeatherStation then calls the SatComms object to transmit the summarized

data to the weather information system, through the satellite
communications system.
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

Figure 26: Sequence diagram describing data collection

Figure 27 is a state diagram for the weather station system that shows how it
responds to requests for various services. You can read this diagram as follows:

• If the system state is Shutdown then it can respond to a restart(), a

reconfigure(), or a powerSave() message. The unlabeled arrow with the
black blob indicates that the Shutdown state is the initial state. A restart()
message causes a transition to normal operation. Both the powerSave() and
reconfigure() messages cause a transition to a state in which the system
reconfigures itself. The state diagram shows that reconfiguration is only
allowed if the system has been shut down.

• In the Running state, the system expects further messages. If a shutdown()

message is received, the object returns to the shutdown state.

• If a reportWeather() message is received, the system moves to the

UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

Summarizing state. When the summary is complete, the system moves to a

Transmitting state where the information is transmitted to the remote
system. It then returns to the Running state.

• If a reportStatus() message is received, the system moves to the Testing

state, then the Transmitting state, before returning to the Running state.

• If a signal from the clock is received, the system moves to the Collecting
state, where it collects data from the instruments. Each instrument is
instructed in turn to collect its data from the associated sensors.

• If a remoteControl() message is received, the system moves to a controlled

state in which it responds to a different set of messages from the remote
control room. These are not shown on this diagram.

Figure 27: Weather station state diagram

 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

Interface Specification
An important part of any design process is the specification of the interfaces
between the components in the design. You need to specify interfaces so that
objects and subsystems can be designed in parallel. Once an interface has been
specified, the developers of other objects may assume that interface will be
implemented.

Interface design is concerned with specifying the detail of the interface to an

object or to a group of objects. This means defining the signatures and semantics
of the services that are provided by the object or by a group of objects.

Interfaces can be specified in the UML using the same notation as a class
diagram. However, there is no attribute section and the UML stereotype
‹‹interface›› should be included in the name part. The semantics of the interface
may be defined using the object constraint language (OCL).

Figure 28 shows two interfaces that may be defined for the weather station. The
left-hand interface is a reporting interface that defines the operation names that
are used to generate weather and status reports. These map directly to operations
in the Weather Station object.

The remote control interface provides four operations, which map onto a single
method in the Weather Station object. In this case, the individual operations are
encoded in the command string associated with the remote Control method,
shown in Figure25.
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

Figure 28: Weather station interfaces

Design Patterns
The pattern is a description of the problem and the essence of its solution, so that
the solution may be reused in different settings. The pattern is not a detailed
specification.

Rather, you can think of it as a description of accumulated wisdom and

experience, a well-tried solution to a common problem.
Patterns and Pattern Languages are ways to describe best practices, good designs,
and capture experience in a way that it is possible for others to reuse this
experience.

The four essential elements of design patterns are:

• A name that is a meaningful reference to the pattern.
• A description of the problem area that explains when the pattern may be
applied.
• A solution description of the parts of the design solution, their
relationships, and their responsibilities.
• A statement of the consequences—the results and trade-offs—of applying
the pattern. This can help designers understand whether or not a pattern can
be used in a particular situation.

Pattern can be used in situations where different presentations of an object’s state

are required. It separates the object that must be displayed from the different
forms of presentation. This is illustrated in Figure 29, which shows two graphical
presentations of the same data set.
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

Figure 29: Multiple displays

Implementation Issues
The three different issues that need to be considered during software
implementation are:

• Reuse: Most modern software is constructed by reusing existing

components or systems. When you are developing software, you should
make as much use as possible of existing code.

• Configuration management: During the development process, many

different versions of each software component are created. If you don’t
keep track of these versions in a configuration management system, you
are liable to include the wrong versions of these components in your system.

• Host-target development: Production software does not usually execute

on the same computer as the software development environment. Rather,
you develop it on one computer (the host system) and execute it on a
separate computer (the target system).
The host and target systems are sometimes of the same type but, often they
are completely different.
 UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

Reuse
From the 1960s to the 1990s, most new software was developed from scratch, by
writing all code in a high-level programming language. The only significant reuse
or software was the reuse of functions and objects in programming language
libraries.

Consequently, an approach to development based around the reuse of existing

software emerged and is now generally used for business systems, scientific
software, and, increasingly, in embedded systems engineering.

Software reuse is possible at a number of different levels:

• The abstraction level: At this level, you don’t reuse software directly but
rather use knowledge of successful abstractions in the design of your
software.

• The object level: At this level, you directly reuse objects from a library
rather than writing the code yourself. To implement this type of reuse, you
have to find appropriate libraries and discover if the objects and methods
offer the functionality that you need.

• The component level: Components are collections of objects and object

classes that operate together to provide related functions and services. You
often have to adapt and extend the component by adding some code of your
own.

• The system level: At this level, you reuse entire application systems. This
usually involves some kind of configuration of these systems. This may be
done by adding and modifying code or by using the system’s own
configuration interface.

As the reused software has been tested in other applications, it should be more
reliable than new software. However, there are costs associated with reuse:
UNIT – 4 ARCHITECTURAL DESIGN , DESIGN AND IMPLEMENTATION

• The costs of the time spent in looking for software to reuse and assessing
whether or not it meets your needs.
• Where applicable, the costs of buying the reusable software.
• The costs of adapting and configuring the reusable software components or
systems to reflect the requirements of the system that you are developing.
• The costs of integrating reusable software elements with each other (if you
are using software from different sources) and with the new code that you
have developed.

• How to reuse existing knowledge and software should be the first thing you
should think about when starting a software development project.