Unit 4

Architectural Design
Architectural design is concerned with understanding how a software
system should be organized and designing the overall structure of that
system.

Architectural design is the critical link between design and requirements

engineering, as it identifies the main structural components in a system and
the relationships between them.

The output of the architectural design process is an architectural model that

describes how the system is organized as a set of communicating
components.

Agility and architecture

It is generally accepted that an early stage of agile processes is to design

an overall systems architecture.

Incremental development of an architecture is not usually successful

Refactoring the system architecture is usually expensive because it affects

so many components in the system

Unit 4 1
 Architectural abstraction:

1. Architecture in the small is concerned with the architecture of individual

programs. At this level, we are concerned with the way that an individual
program is decomposed into components. This chapter is mostly
concerned with program architectures.

2. Architecture in the large is concerned with the architecture of complex

enterprise systems that include other systems, programs, and program
components. These enterprise systems may be distributed over different
computers, which may be owned and managed by different companies.

Advantages of explicit architecture

1. Stakeholder communication:
The architecture is a high-level presentation of the system that may be
used as a focus for discussion by a range of different stakeholders.

2. System Analysis:
Means that analysis of whether the system can meet its non-functional
requirements is possible.

3. Large-scale reuse:

The architecture may be reusable across a range of systems

Product-line architectures may be developed.

Architectural Representations

Simple, informal block diagrams showing entities and relationships are the
most frequently used method for documenting software architectures.

But these have been criticised because they lack semantics, do not show
the types of relationships between entities nor the visible properties of
entities in the architecture.

Depends on the use of architectural models.

The requirements for model semantics depends on how the models are
used.

Box and Line Diagrams

Very abstract - they do not show the nature of component relationships nor
the externally visible properties of the sub-systems.

Unit 4 2
 However, useful for communication with stakeholders and for project
planning.

Use of Architectural Models

As a way of facilitating discussion about the system design

A high-level architectural view of a system is useful for communication

with system stakeholders and project planning because it is not
cluttered with detail.

Stakeholders can relate to it and understand an abstract view of the

system, allowing them to discuss the system as a whole without being
confused by detail.

As a way of documenting an architecture that has been designed

The aim is to produce a complete system model that shows the different
components in a system, their interfaces, and their connections.

Architectural design decisions

Architectural design is a creative process so the process differs depending
on the type of system being developed.

Architecture design is a creative process in which you design a system

organization that will satisfy the functional and non-functional requirements
of a system.

There is no formulaic architectural design process.

It depends on the type of system being developed, the background and

experience of the system architect, and the specific requirements for the
system.

However, a number of common decisions span all design processes and

these decisions affect the non-functional characteristics of the system

Unit 4 3
 Systems in the same domain often have similar architectures that reflect
domain concepts.

Architecture Reuse

Application product lines are built around a core architecture with variants
that satisfy particular customer requirements.

The architecture of a system may be designed around one or more

architectural patterns or 'styles.'

These patterns capture the essence of an architecture and can be

instantiated in different ways.

Architecture and System Characteristics

Performance

If performance is a critical requirement, the architecture should be

designed to localize critical operations within a small number of
components, with these components deployed on the same computer
rather than distributed across the network.

Security

If security is a critical requirement, a layered structure for the

architecture should be used, with the most critical assets protected in

Unit 4 4
 the innermost layers and a high level of security validation applied to
these layers.

Safety

If safety is a critical requirement, the architecture should be designed

so that safety-related operations are co-located in a single component
or in a small number of components.

Availability

If availability is a critical requirement, the architecture should be

designed to include redundant components so that it is possible to
replace and update components without stopping the system.

Maintainability

If maintainability is a critical requirement, the system architecture

should be designed using fine-grain, self-contained components that
may readily be changed.

Architectural views
What views or perspectives are useful when designing and documenting a
system’s architecture?

What notations should be used for describing architectural models?

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.

Unit 4 5
 4 + 1 view model of software architecture

A logical view, which shows the key abstractions in the system as objects
or object classes. It should be possible to relate the system requirements to
entities in this logical view.

A process view, which shows how, at run-time, the system is composed of

interacting processes. This view is useful for making judgments about non-
functional system characteristics such as performance and availability.

A development view, which shows how the software is decomposed for

development; that is , it shows the breakdown of the software into
components that are
implemented by a single developer or development team. This view is
useful for
software managers and programmers.

A physical view, which shows the system hardware and how software
components are distributed across the processors in the system. This view
is useful for systems engineers planning a system deployment

Related using use cases or scenarios (+1)

Representing architectural views

Some people argue that the Unified Modeling Language (UML) is an

appropriate notation for describing and documenting system architectures.

I disagree with this as I do not think that the UML includes abstractions
appropriate for high-level system description.

Unit 4 6
 Architectural description languages (ADLs) have been developed but are
not widely used.

Architectural patterns
Patterns are a means of representing, sharing, and reusing knowledge.

An architectural pattern is a stylized description of good design practice,

which has been tried and tested in different environments.

Patterns should include information about when they are and when they are
not useful.

Patterns may be represented using tabular and graphical descriptions.

The model view controller(MVC) pattern

The organization of the MVC

Unit 4 7
 The Web application architecture using MVC pattern

Layered Architecture
Used to model the interfacing of sub-systems.

Organises the system into a set of layers (or abstract machines) each of
which provide a set of services.

Supports the incremental development of sub-systems in different

layers. When a layer interface changes, only the adjacent layer is affected.

However, often artificial to structure systems in this way.

The Layered architecture pattern

Unit 4 8
 A generic layered Architecture

The architecture of the iLearn system

Unit 4 9
 Repository architecture
Sub-systems must exchange data. This may be done in two ways:

Shared data is held in a central database or repository and may be

accessed by all sub-systems.

Each sub-system maintains its own database and passes data explicitly
to other sub-systems.

When large amounts of data are to be shared, the repository model of

sharing is most commonly used as it is an efficient data sharing
mechanism.

Unit 4 10
 Client-server architecture
Distributed system model showing how data and processing are
distributed across a range of components.

Can be implemented on a single computer.

Set of stand-alone servers providing specific services (e.g., printing, data

management).

Unit 4 11
 Set of clients calling on these services.

Network allowing clients to access servers.

Pipe and filter architecture

Functional transformations process inputs to produce outputs.

Often referred to as a pipe and filter model (as in UNIX shell).

Unit 4 12
 Variants of this approach are common. When transformations are
sequential, this is a batch sequential model, widely used in data
processing systems.

Not really suitable for interactive systems.

Application Architectures
Application architectures

Application systems are designed to meet an organizational need.

As businesses share many similarities, their application systems often

have a common architecture reflecting these requirements.

Unit 4 13
 A generic application architecture is a type of software architecture that
can be configured and adapted to meet specific requirements.

Use of application architectures

As a starting point for architectural design.

As a design checklist.

As a way of organizing the work of the development team.

As a means of assessing components for reuse.

As a vocabulary for talking about application types.

Application type examples

Transaction processing systems:

E-commerce systems

Reservation systems

Language processing systems:

Compilers

Command interpreters

Unit 4 14
Unit 4 15
 Design and implementation
Design and implementation

Software design and implementation is the stage where an executable

software system is developed.

Design and implementation activities are inter-leaved and occur together.

Software design is a creative activity where software components and

their relationships are identified based on the customer's requirements.

Implementation is the process of realizing the design as a program.

Unit 4 16
 Build or buy

In many domains, it is possible to buy off-the-shelf systems (COTS) that

can be adapted to meet users' requirements.

Example: For a medical records system, an existing package used in

hospitals can be purchased, which may be cheaper and faster than
developing a new system in a conventional programming language.

When using an existing system, the design process focuses on how to

configure the system's features to meet the system's requirements.

Object-oriented design using the UML

An object-oriented design process

Structured object-oriented design processes involve developing several

different system models.

These processes require significant effort for development and

maintenance of models, which may not be cost-effective for small
systems.

However, for large systems developed by different groups, design models

are an important communication mechanism.

Process stages

Various object-oriented design processes exist depending on the

organization using the process.

Common activities include:

Define the context and modes of use of the system.

Design the system architecture.

Identify principal system objects.

Develop design models.

Specify object interfaces.

System context and interactions

Understanding the relationships between the software and its external

environment is essential for:

Unit 4 17
 Deciding how to provide the required system functionality.

Structuring the system to communicate with its environment.

Understanding the context helps establish the boundaries of the system,

deciding what features belong to the system and what belongs to other
associated systems.

Context and interaction models

A system context model is a structural model that shows 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 during use.

Architectural design

Once interactions between the system and its environment are understood,
the information is used to design the system architecture.

Identify the major components of the system and their interactions, then
organize components using an architectural pattern (e.g., layered or
client-server model).

The weather station is composed of independent subsystems that

communicate by broadcasting messages on a common infrastructure.

Object class identification

Unit 4 18
 Identifying object classes is often a difficult part of object-oriented
design.

There is no 'magic formula' for object identification; it relies on the skill,

experience, and domain knowledge of system designers.

Object identification is an iterative process; it is unlikely to be perfect

the first time.

Approaches to identification

Grammatical approach: Based on a natural language description of the

system.

Tangible approach: Based on tangible things in the application domain.

Behavioural approach: Identify objects based on what participates in

specific behaviours.

Scenario-based analysis: Identify objects, attributes, and methods in each

scenario.

Weather station object classes

Object class identification in the weather station system could be based on

tangible hardware and data in the system:

Ground thermometer, Anemometer, Barometer: Hardware objects

related to the instruments in the system.

Weather station: The basic interface of the weather station to its

environment, reflecting interactions from the use-case model.

Weather data: Encapsulates the summarized data from the instruments.

Design models

Design models show objects and object classes and the relationships
between them.

There are two kinds of design models:

Structural models: Describe the static structure of the system in terms

of object classes and relationships.

Dynamic models: Describe the dynamic interactions between objects.

Examples of design models

Unit 4 19
 Subsystem models: Show logical groupings of objects into coherent
subsystems.

Sequence models: Show the sequence of object interactions.

State machine models: Show how individual objects change state in

response to events.

Other models include use-case models, aggregation models,

generalisation models, etc.

Subsystem models

Show how the design is organized into logically related groups of objects.

In the UML, these are shown using packages, which are an encapsulation
construct. This is a logical model, and the actual organization may differ.

Sequence models

Show the sequence of object interactions that take place.

Objects are arranged horizontally across the top.

Time is represented vertically, with models read from top to bottom.

Interactions are represented by labelled arrows; different arrow styles

represent different types of interactions.

A thin rectangle in an object's lifeline represents the time when the

object is the controlling object in the system.

Unit 4 20
 State diagrams

State diagrams are used to show how objects respond to different service
requests and the state transitions triggered by these requests.

State diagrams are useful high-level models of a system or an object’s run-

time behavior.

You don’t usually need a state diagram for all of the objects in the system.
Many of the objects in a system are relatively simple and a state model
adds unnecessary detail to the design.

Interface specification

Object interfaces have to be specified so that the objects and other

components can be designed in parallel.

Designers should avoid designing the interface representation but should

hide this in the object itself.

Objects may have several interfaces which are viewpoints on the methods
provided.

The UML uses class diagrams for interface specification but Java may also
be used.

Unit 4 21
 Design patterns
Design patterns

A design pattern is a way of reusing abstract knowledge about a problem

and its solution.

A pattern is a description of the problem and the essence of its solution.

It should be sufficiently abstract to be reused in different settings.

Pattern descriptions usually make use of object-oriented characteristics

such as inheritance and polymorphism.

Patterns

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.

Pattern elements

Name: A meaningful pattern identifier.

Problem description: Describes the problem that needs to be solved.

Solution description: Not a concrete design but a template for a design

solution that can be instantiated in different ways.

Consequences: The results and trade-offs of applying the pattern.

The Observer pattern

Unit 4 22
 Name: Observer.

Description: Separates the display of object state from the object itself.

Problem description: Used when multiple displays of state are needed.

Solution description: See slide No. 91.

Consequences: Optimizations to enhance display performance are

impractical.

Unit 4 23
 Design problems

To use patterns in your design, you need to recognize that any design
problem you are facing may have an associated pattern that can be applied.

Observer pattern: Tell several objects that the state of some other
object has changed.

Façade pattern: Tidy up the interfaces to a number of related objects

that have often been developed incrementally.

Iterator pattern: Provide a standard way of accessing the elements in a

collection, irrespective of how that collection is implemented.

Decorator pattern: Allow for the possibility of extending the

functionality of an existing class at run-time.

Implementation issues
Implementation issues

Focus here is not on programming, although this is obviously important,

but on other implementation issues that are often not covered in
programming texts:

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.

Unit 4 24
 Configuration management: During the development process, you
have to keep track of the many different versions of each software
component in a configuration management 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).

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 of software was the reuse of functions and
objects in programming language libraries.

Costs and schedule pressure mean that this approach became increasingly
unviable, especially for commercial and Internet-based systems.

An approach to development based around the reuse of existing software

emerged and is now generally used for business and scientific software.

Reuse levels

The abstraction level: At this level, you don’t reuse software directly but
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.

The component level: Components are collections of objects and object

classes that you reuse in application systems.

The system level: At this level, you reuse entire application systems.

Unit 4 25
 Reuse costs

Time spent in searching and assessing reusable software: The time spent
looking for software to reuse and evaluating whether it meets the system's
requirements.

Costs of buying reusable software: For large off-the-shelf systems, these

costs can be very high.

Costs of adapting and configuring reusable software: Adapting and

configuring reusable software components to meet the specific
requirements of the system being developed.

Costs of integrating reusable software: The cost of integrating software

from different sources with each other and with the new code developed
for the system.

Configuration management

Definition: Configuration management refers to the general process of

managing a changing software system.

Goal: The aim of configuration management is to support the system

integration process, allowing all developers to access the project code and
documents in a controlled way, track changes, and compile and link
components to create the system.

Configuration management activities

Unit 4 26
 Version management: Supports tracking different versions of software
components and coordinating development among several programmers.

System integration: Helps define which versions of components are used

to create each version of the system, facilitating automatic system builds by
compiling and linking required components.

Problem tracking: Provides support for users to report bugs and issues,
and allows developers to track who is working on problems and when they
are resolved.

Host-target development

Most software is developed on one computer (the host), but runs on a

separate machine (the target).

More generally, we can talk about a development platform and an execution

platform.

A platform is more than just hardware.

It includes the installed operating system plus other supporting software

such as a database management system or, for development platforms, an
interactive development environment.

Development platform usually has different installed software than

execution platform; these platforms may have different architectures.

Unit 4 27
 Development platform tools

An integrated compiler and syntax-directed editing system that allows you

to create, edit, and compile code.

A language debugging system.

Graphical editing tools, such as tools to edit UML models.

Testing tools, such as Junit, that can automatically run a set of tests on a
new version of a program.

Project support tools that help you organize the code for different
development projects.

Integrated development environments (IDEs)

Software development tools are often grouped to create an integrated

development environment (IDE).

An IDE is a set of software tools that supports different aspects of software

development, within some common framework and user interface.

IDEs are created to support development in a specific programming

language, such as Java. The language IDE may be developed specially, or
may be an instantiation of a general-purpose IDE, with specific language-
support tools.

Component/system deployment factors

Unit 4 28
 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.

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.

If there is a high level of communications traffic between components, it

usually makes sense to deploy them on the same platform or on platforms
that are physically close to one another. This reduces the delay between
the time a message is sent by one component and received by another.

Open-source development
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 participate in the development process.

Its roots are in the Free Software Foundation (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.

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.

Open-source systems

The best-known open-source product is, of course, the Linux operating

system, which is widely used as a server system and, increasingly, as a
desktop environment.

Other important open-source products are Java, the Apache web server,
and the mySQL database management system.

Open-source issues

Should the product that is being developed make use of open-source

components?

Should an open-source approach be used for the software’s development?

Unit 4 29
 Open-source business

More and more product companies are using an open-source approach to

development.

Their business model is not reliant on selling a software product but on

selling support for that product.

They believe that involving the open-source community will allow software
to be developed more cheaply, more quickly, and will create a community
of users for the software.

Open source licensing

A fundamental principle of open-source development is that source code

should be freely available, but this does not mean that anyone can do as
they wish with that code.

Legally, the developer of the code (either a company or an individual) still

owns the code. They can place restrictions on how it is used by including
legally binding conditions in an open-source software license.

Some open-source developers believe that if an open-source component is

used to develop a new system, then that system should also be open
source.

Others are willing to allow their code to be used without this restriction. The
developed systems may be proprietary and sold as closed-source systems.

License models

The GNU General Public License (GPL): This is a so-called ‘reciprocal’

license that means that if you use open-source software that is licensed
under the GPL license, then you must make that software open source.

The GNU Lesser General Public License (LGPL): This is a variant of the
GPL license where you can write components that link to open-source code
without having to publish the source of these components.

The Berkley Standard Distribution (BSD) License: This is a non-reciprocal

license, which means you are not obliged to re-publish any changes or
modifications made to open-source code. You can include the code in
proprietary systems that are sold.

License management

Unit 4 30
 Establish a system for maintaining information about open-source
components that are downloaded and used.

Be aware of the different types of licenses and understand how a

component is licensed before it is used.

Be aware of evolution pathways for components.

Educate people about open source.

Have auditing systems in place.

Participate in the open source community.

Unit 4 31