Software engineering

UNIT 4

ARCHITECTURAL DESIGN
Architectural design is a process for identifying the sub-systems making up a system and the
framework for sub-system control and communication. The output of this design process is a
description of the software architecture. Architectural design is an early stage of the system
design process. It represents the link between specification and design processes and is often
carried out in parallel with some specification activities. It involves identifying major system
components and their communications.

Architectural design decisions

Architectural design is a creative process so the process differs depending on the type of system
being developed. However, a number of common decisions span all design processes and these
decisions affect the non-functional characteristics of the system:

 Is there a generic application architecture that can be used?

 How will the system be distributed?
 What architectural styles are appropriate?
 What approach will be used to structure the system?
 How will the system be decomposed into modules?
 What control strategy should be used?
 How will the architectural design be evaluated?
 How should the architecture be documented?

Systems in the same domain often have similar architectures that reflect domain concepts.
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 of
more architectural patterns/styles, which capture the essence of an architecture and can be
instantiated in different ways.
The particular architectural style should depend on the non-functional system requirements:

 Performance: localize critical operations and minimize communications. Use large

rather than fine-grain components.
 Security: use a layered architecture with critical assets in the inner layers.
 Safety: localize safety-critical features in a small number of sub-systems.
 Availability: include redundant components and mechanisms for fault tolerance.
 Maintainability: use fine-grain, replaceable components.


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

NIMS BCA DEPT SE NOTES Page 1

 Software engineering

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.
Layered architecture

 Used to model the interfacing of sub-systems.

 Organizes 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.

NIMS BCA DEPT SE NOTES Page 2

 Software engineering

Name Layered architecture

Organizes the system into layers with related functionality associated with each
Description layer. A layer provides services to the layer above it so the lowest-level layers
represent core services that are likely to be used throughout the system.
Used when building new facilities on top of existing systems; when the
When used development is spread across several teams with each team responsibility for a
layer of functionality; when there is a requirement for multi-level security.
Allows replacement of entire layers so long as the interface is maintained.
Advantages Redundant facilities (e.g., authentication) can be provided in each layer to
increase the dependability of the system.
In practice, providing a clean separation between layers is often difficult and a
high-level layer may have to interact directly with lower-level layers rather than
Disadvantages through the layer immediately below it. Performance can be a problem because of
multiple levels of interpretation of a service request as it is processed at each
layer.

Repository architecture

 Sub-systems must exchange data. This may be done in two ways:

o Shared data is held in a central database or repository and may be accessed by
all sub-systems;
o 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 a this is an efficient data sharing mechanism.

NIMS BCA DEPT SE NOTES Page 3

 Software engineering

Name Repository
All data in a system is managed in a central repository that is accessible to all
Description system components. Components do not interact directly, only through the
repository.
You should use this pattern when you have a system in which large volumes of
information are generated that has to be stored for a long time. You may also use
When used
it in data-driven systems where the inclusion of data in the repository triggers an
action or tool.
Components can be independent--they do not need to know of the existence of
other components. Changes made by one component can be propagated to all
Advantages
components. All data can be managed consistently (e.g., backups done at the
same time) as it is all in one place.
The repository is a single point of failure so problems in the repository affect the
Disadvantages whole system. May be inefficiencies in organizing all communication through the
repository. Distributing the repository across several computers may be difficult.

Client-server architecture

 Distributed system model which shows how data and processing is distributed across
a range of components, but can also be implemented on a single computer.
 Set of stand-alone servers which provide specific services such as printing, data
management, etc.
 Set of clients which call on these services.
 Network which allows clients to access servers.

NIMS BCA DEPT SE NOTES Page 4

 Software engineering

Name Client-server
In a client-server architecture, the functionality of the system is organized into
Description services, with each service delivered from a separate server. Clients are users of
these services and access servers to make use of them.
Used when data in a shared database has to be accessed from a range of locations.
When used Because servers can be replicated, may also be used when the load on a system is
variable.
The principal advantage of this model is that servers can be distributed across a
Advantages network. General functionality (e.g., a printing service) can be available to all
clients and does not need to be implemented by all services.
Each service is a single point of failure so susceptible to denial of service attacks
or server failure. Performance may be unpredictable because it depends on the
Disadvantages
network as well as the system. May be management problems if servers are
owned by different organizations.

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.

Name Pipe and filter

The processing of the data in a system is organized so that each processing
Description component (filter) is discrete and carries out one type of data transformation. The
data flows (as in a pipe) from one component to another for processing.

NIMS BCA DEPT SE NOTES Page 5

 Software engineering

Commonly used in data processing applications (both batch- and transaction-

When used
based) where inputs are processed in separate stages to generate related outputs.
Easy to understand and supports transformation reuse. Workflow style matches
Advantages the structure of many business processes. Evolution by 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 input and unparse its output
Disadvantages to the agreed form. This increases system overhead and may mean that it is
impossible to reuse functional transformations that use incompatible data
structures.

DESIGN AND IMPLEMENTATION

Software design and implementation is the stage in the software engineering process at which an
executable software system is developed. Software design is a creative activity in which you
identify software components and their relationships, based on a customer's
requirements. Implementation is the process of realizing the design as a program. These two
activities are invariably inter-leaved.

Object-oriented design using the UML

Structured object-oriented design processes involve developing a number of different system
models. They require a lot of effort for development and maintenance and, for small systems,
this may not be cost-effective. However, for large systems developed by different groups design
models are an important communication mechanism. Common activities in these processes
include:

 Define the context and modes of use of the system;

 Design the system architecture;
 Identify the principal system objects;
 Develop design models;
 Specify object interfaces.

System context and interactions

Understanding the relationships between the software that is being designed and its external
environment 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. Setting the system boundaries helps you decide
what features are implemented in the system being designed and what features are in other
associated systems.

NIMS BCA DEPT SE NOTES Page 6

 Software engineering

A system context is a structural model (e.g., a class diagram) that demonstrates the other
systems in the environment of the system being developed.
An interaction model is a dynamic model (e.g., a use case diagram + structured natural
language description) that shows how the system interacts with its environment as it is used.

System Weather station

Use case Report weather
Actors Weather information system, Weather station
Descriptio The weather station sends a summary of the weather data that has been collected
n from the instruments in the collection period to the weather information system. The

NIMS BCA DEPT SE NOTES Page 7

 Software engineering

data sent are the maximum, minimum, and average ground and air temperatures; the
maximum, minimum, and average air pressures; the maximum, minimum, and
average wind speeds; the total rainfall; and the wind direction as sampled at five-
minute intervals.
The weather information system establishes a satellite communication link with the
Stimulus
weather station and requests transmission of the data.
Response The summarized data is sent to the weather information system.
Weather stations are usually asked to report once per hour but this frequency may
Comments
differ from one station to another and may be modified in the future.

Architectural design
Once interactions between the system and its environment have been understood, you use this
information 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 (e.g. a layered or client-server model).

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. You are
unlikely to get it right first time. Approaches to object identification include:

 Use a grammatical approach based on a natural language description of the system.

 Base the identification on tangible things in the application domain.
 Use a behavioral approach and identify objects based on what participates in what
behavior.

NIMS BCA DEPT SE NOTES Page 8

 Software engineering

 Use a scenario-based analysis. The objects, attributes and methods in each scenario
are identified.

Design models
Design models show the objects and object classes and relationships between these
entities. Static models describe the static structure of the system in terms of object classes and
relationships. Dynamic models describe the dynamic interactions between objects.
Subsystem models 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 show the sequence of object interactions. These are represented using a UML
sequence or a collaboration diagram. Sequence models are dynamic models.

State machine models 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. State diagrams are useful high-level models of a system or an object's run-time behavior.

NIMS BCA DEPT SE NOTES Page 9

 Software engineering

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.

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.
Design pattern elements:
Name
A meaningful pattern identifier
Problem description
A common situation where this pattern is applicable
Solution description

NIMS BCA DEPT SE NOTES Page 10

 Software engineering

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
Example: the Observer pattern

Pattern name Observer

Separates the display of the state of an object from the object itself and allows
Description alternative displays to be provided. When the object state changes, all displays
are automatically notified and updated to reflect the change.
In many situations, you have to provide multiple displays of state information,
such as a graphical display and a tabular display. Not all of these may be known
when the information is specified. All alternative presentations should support
Problem
interaction and, when the state is changed, all displays must be updated.
description
This pattern may be used in all situations where more than one display format for
state information is required and where it is not necessary for the object that
maintains the state information to know about the specific display formats used.
This involves two abstract objects, Subject and Observer, and two concrete
objects, ConcreteSubject and ConcreteObject, which inherit the attributes of the
related abstract objects. The abstract objects include general operations that are
applicable in all situations. The state to be displayed is maintained in
ConcreteSubject, which inherits operations from Subject allowing it to add and
Solution
remove Observers (each observer corresponds to a display) and to issue a
description
notification when the state has changed.
The ConcreteObserver maintains a copy of the state of ConcreteSubject and
implements the Update() interface of Observer that allows these copies to be
kept in step. The ConcreteObserver automatically displays the state and reflects
changes whenever the state is updated.
Consequences The subject only knows the abstract Observer and does not know details of the

NIMS BCA DEPT SE NOTES Page 11

 Software engineering

concrete class. Therefore there is minimal coupling between these objects.

Because of this lack of knowledge, optimizations that enhance display
performance are impractical. Changes to the subject may cause a set of linked
updates to observers to be generated, some of which may not be necessary.

Implementation issues

1 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.
Levels of reuse:

 The abstraction level: don't reuse software directly but use knowledge of successful
abstractions in the software design.
 The object level: directly reuse objects from a library rather than writing the code
yourself.
 The component level: components (collections of objects and object classes) are
reused in application systems.
 The system level: entire application systems are reused.

Costs of reuse:

 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. For large off-the-shelf
systems, these costs can be very high.
 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.

2. Configuration management
Configuration management is the name given to the general process of managing a changing
software system.
Configuration management activities include:

 Version management, where support is provided to keep track of the different

versions of software components.
 System integration, where support is provided to help developers define what
versions of components are used to create each version of a system.

NIMS BCA DEPT SE NOTES Page 12

 Software engineering

 Problem tracking, where support is provided to allow users to report bugs and other
problems,

3. Host-target development
Most software is developed on one computer (the host, development platform), but runs on a
separate machine (the target, 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
(IDE). Development platform usually has different installed software than execution platform;
these platforms may have different architectures. Mobile app development (e.g. for Android) is a
good example.
Typical development platform tools include:

 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 proje

NIMS BCA DEPT SE NOTES Page 13