Unit 6: Architectural Design Software Engineering

Introduction to Architectural Design

Architectural design in software engineering is about decomposing the system into interacting
components. It is expressed as a block diagram defining an overview of the system structure,
features of the components, and how these components communicate with each other to share
data. It identifies the components that are necessary for developing a computer-based system and
communication between them i.e. relationship between these components. It defines the structure
and properties of the components that are involved in the system and also the interrelationships
between these components. The architectural design process is about identifying the components
i.e. subsystems that makeup the system and structure of the sub-system and they’re
interrelationship. It is an early stage of the system design phase. It acts as a link between
specification requirements and the design process.

System properties of Architectural Design

In software engineering, during the architectural design process, some system properties are
focused. Some of them are as follows:

 Security: The system is secured against malicious users by encryption or any other

security measures. The architectural design process uses a layered architecture with

critical assets in the innermost layers.

 Performance: It is nothing but a meantime taken between request and response of the

page. The performance of a system can be improved by avoiding critical operations and

reducing communication between components. This is possible by using large

components instead of small and fine-grained components.

 Maintainability: Architectural design process uses easily modifiable and replaceable

components. Consider the components in a manner so that it is easy to change them over

time according to the new requirements and build the software with the flexibility to

change or maintain.

 Safety: Avoid critical functionalities in small components of the system.

 Availability: Architectural design process includes redundant components and

corresponding functions for handling the occurrence of any type of errors.

~1~
Unit 6: Architectural Design Software Engineering

Decisions for Architectural Design

In software engineering, the architectural design process differs as the system differs depending

upon the type of system being developed. But still, there are some common decisions that should

be taken care of in any design process are as follows:

 How can the system be distributed across the network?

 Which approach can be used to structure the system?

 Is there a generic application architecture procedure that can be used which can act as a

template for the proposed system that is being designed and developed?

 Which architectural styles are suitable for the proposed system?

 How can software architecture be documented?

 How can the system be decomposed into modules?

 What control strategy must be used to control the operation of the components in the

system?

 How can architectural design be analyzed?

Software Architectural Models

To document the architectural design process, architectural models are used

1. Static type of architectural structural model represents the major system components.

2. Dynamic type of architectural process model represents the process structure of the

system.

3. Distribution type of architectural model represents how the component is distributed

across various computers.

4. Interface type of architectural model represents the interface of the components.

~2~
Unit 6: Architectural Design Software Engineering

5. Relationships type of architectural model represent models such as data flow diagram

to represent the component interrelationship.

Architectural design models are application domain-specific and the most common two types

of domain-specific models are:

1. Generic model: These models are abstractions derived from a number of real systems

and encapsulated the characteristics of these systems. This type of model usually follows

a bottom-up approach.

2. Reference models: These models provide information regarding the class of the system.

They are derived from the application domain rather than from existing systems. It

usually follows the top-down approach. It provides a comparison between different

Software architecture.

Advantages of Architectural Design in Software Engineering

 Architectural design works as a tool for stakeholder communication. It is used as a

support or roadmap in the discussion with system stakeholders

 It is used for system analysis. Architectural design is used to analyze whether the system

will be able to meet its non-functional requirements or not.

 It facilitates large-scale re-use. The software architecture that is the output of the

architectural design process can be reused across a range of the system.

Disadvantages of Architectural Design in Software Engineering

 Architectural design re-use the components, the use of redundant components improves

the availability but makes the security of the system difficult to handle.

~3~
Unit 6: Architectural Design Software Engineering

 Use of large components may improve the performance as large components include all

the related properties and function into one component but it reduces the maintainability

as it becomes difficult to modify and replace the large component. It involves a very

tiresome task.

 Avoiding critical features inside the small components leads to more communication

among the components which in turn degrades the performance.

Architectural views
The views are used to describe the system from the viewpoint of different stakeholders, such as
end-users, developers, system engineers, and project managers. The four views of the model are
logical, development, process and physical view. In addition, selected use cases or scenarios are
used to illustrate the architecture serving as the 'plus one' view. Hence, the model contains 4+1
views:

 Logical view: The logical view is concerned with the functionality that the system
provides to end-users. UML diagrams are used to represent the logical view, and include
class diagrams, and state diagrams.
 Process view: The process view deals with the dynamic aspects of the system, explains
the system processes and how they communicate, and focuses on the run time behavior of
~4~
Unit 6: Architectural Design Software Engineering
the system. The process view addresses concurrency, distribution, integrator,
performance, and scalability, etc. UML diagrams to represent process view include the
sequence diagram, activity diagram.
 Development view: The development view illustrates a system from a programmer's
perspective and is concerned with software management. This view is also known as the
implementation view.
 Physical view: The physical view illustrates the system from a system engineer's point of
view. It is concerned with the topology of software components on the physical layer as
well as the physical connections between these components
 Scenarios: The description of architecture is illustrated using a small set of use cases, or
scenarios, which become a fifth view. The scenarios describe sequences of interactions
between objects and between processes. They are used to identify architectural elements
and to illustrate and validate the architecture design. They also serve as a starting point
for tests of an architecture prototype. This view is also known as the use case view.

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 they are not
useful. Patterns may be represented using tabular and graphical descriptions.

An architectural pattern is a universal solution to a commonly occurring problem within a given

project. Basically, patterns act as templates applied for various architectural designs.
Additionally, they are often applied in software documentation, helping stakeholders
communicate and collaborate with each other.

The major goal of architectural patterns is to address different issues between the software
components. And also ensuring their appropriate relationships and smoothing performance
within a single environment.

Today, software architects utilize multiple patterns, which can significantly enhance project
development. Thus, architectural patterns can benefit the development lifecycle, optimize project
costs, improve user experiences, ease software maintenance, and so on. This helps add the
finishing touches to your product.

Types of Software Architecture Patterns

Model-View-Controller Pattern

MVC (Model-View-Controller) is a pattern in software design commonly used to implement

user interfaces, data, and controlling logic. It emphasizes a separation between the software's

~5~
Unit 6: Architectural Design Software Engineering
business logic and display. This "separation of concerns" provides for a better division of labor
and improved maintenance. Some other design patterns are based on MVC, such as MVVM
(Model-View-Viewmodel), MVP (Model-View-Presenter), and MVW (Model-View-Whatever).

The three parts of the MVC software-design pattern can be described as follows:

Model: Manages data and business logic.

View: Handles layout and display.

Controller: Routes commands to the model and view parts.

Model View Controller example

Imagine a simple shopping list app. All we want is a list of the name, quantity and price of each
item we need to buy this week. Below we'll describe how we could implement some of this
functionality using MVC.

~6~
Unit 6: Architectural Design Software Engineering

The model

The model defines what data the app should contain. If the state of this data changes, then the
model will usually notify the view (so the display can change as needed) and sometimes the
controller (if different logic is needed to control the updated view).

Going back to our shopping list app, the model would specify what data the list items should
contain — item, price, etc. — and what list items are already present.

The View

The view defines how the app's data should be displayed.

In our shopping list app, the view would define how the list is presented to the user, and receive
the data to display from the model.

The Controller

The controller contains logic that updates the model and/or view in response to input from the
users of the app.

So for example, our shopping list could have input forms and buttons that allow us to add or
delete items. These actions require the model to be updated, so the input is sent to the controller,
which then manipulates the model as appropriate, which then sends updated data to the view.

You might however also want to just update the view to display the data in a different format,
e.g., change the item order to alphabetical, or lowest to highest price. In this case the controller
could handle this directly without needing to update the model.

Layered Architecture Pattern

Layered architecture pattern (also known as the n-tier or multi-layered pattern) is one of software
development’s most popular architecture frameworks. This pattern consists of a hierarchy of
separate horizontal layers. Each of layers has distinct advantages but works together as a single
unit of software. Typically, a traditional layered architecture in software engineering is classified
into three tiers and four distinct layers:

 Presentation layer
 Application (Business logic) layer
 Data Access
 Database

The main goal of this pattern is to organize the app components by dividing them into small
pieces so that each of them will contribute to a different part of the overall system. In some

~7~
Unit 6: Architectural Design Software Engineering
cases, you can find the grouped layers, in which the functions and responsibilities of the separate
layers are implemented into a single, combined solution.

Advantages & Usage of Layered Architecture

The pattern is widely used for projects of different scales and industries, from startup
development to large-scale software solutions. In particular, you can find layered architecture in
E-Commerce web front ends, enterprise software solutions, etc. Some of its major usage cases
are:

 Applied for projects that require rapid development

 Fit for simple and small applications, as well as larger projects

 Used for enterprise apps with traditionally established IT departments and standardized

workflows
 Implemented for projects with strict standards of maintainability and testability

 Works for inexperienced developers with little expertise in architecture patterns

Fig: generic layered pattern

~8~
Unit 6: Architectural Design Software Engineering
Example

Web Browser

Login, Role checking, Form and Menu Manager

Data Validation

Security Patient Info Report

Management Manager Generation

Transaction management patient database

Repository Architecture Style/pattern

 Repository architecture is a collection of independent components which operate on

central data structure.

 Information System, Programming Environments, Graphical Editors, AI Knowledge

Bases, Reverse Engineering System are the examples of Repository Architecture Style.

 It includes central data structure.

 Repository architecture style is very important for data integration introduced in a variety

of applications including software development, CAD etc.

 Repository architecture style makes change to the data structure trigger computations.

 This architecture is suitable for applications in which the central issues are establishing

and maintaining a complex central body of information.

~9~
Unit 6: Architectural Design Software Engineering

The above figure shows the repository architecture style. In this architecture, the data store is
passive and the software clients or components of the data store are active which controls the
logic flow and checks the data store for changes.

Advantages of Repository Architecture Style

 Repository Architecture Style provides data integrity, backup and restore features.
 It reduces overhead of transient data between software components.
 It has an efficient way to store large amount of data.
 It has a centralized management which consists of backup, security and concurrency
control.
Disadvantages of Repository Architecture Style
 In repository architecture style, evolution of data is difficult and expensive.
 It has high dependency between data structure of data store and its software components
or clients.

~ 10 ~
Unit 6: Architectural Design Software Engineering

Client-server architecture pattern

Client-server model is a distributed application structure that partitions task or workload
between the providers of a resource or service, called servers, and service requesters called
clients. In the client-server architecture, when the client computer sends a request for data to
the server through the internet, the server accepts the requested process and deliver the data
packets requested back to the client. Clients do not share any of their resources. Examples of
Client-Server Model are Email, World Wide Web, etc.
How the Client-Server Model works?
In this article we are going to take a dive into the Client-Server model and have a look at how
the Internet works via, web browsers. This article will help us in having a solid foundation of
the WEB and help in working with WEB technologies with ease.
 Client: When we talk the word Client, it mean to talk of a person or an organization

using a particular service. Similarly in the digital world a Client is a computer (Host)
i.e. capable of receiving information or using a particular service from the service
providers (Servers).
 Servers: Similarly, when we talk the word Servers, It mean a person or medium that

serves something. Similarly in this digital world a Server is a remote computer which
provides information (data) or access to particular services
How the browser interacts with the servers ?
There are few steps to follow to interacts with the servers a client.
 User enters the URL(Uniform Resource Locator) of the website or file. The Browser

then requests the DNS(DOMAIN NAME SYSTEM) Server.

 DNS Server lookup for the address of the WEB Server.

 DNS Server responds with the IP address of the WEB Server.

 Browser sends over an HTTP/HTTPS request to WEB Server’s IP (provided by DNS

server).
 Server sends over the necessary files of the website.

 Browser then renders the files and the website is displayed. This rendering is done with

the help of DOM (Document Object Model) interpreter, CSS interpreter and JS
Engine collectively known as the JIT or (Just in Time) Compilers.

~ 11 ~
Unit 6: Architectural Design Software Engineering

Fig: client-server architecture pattern for film library.

Piper and filter Architecture
Pipe and Filter is a simple architectural style that connects a number of components that process
a stream of data, each connected to the next component in the processing pipeline via a Pipe.

The Pipe and Filter architecture is inspired by the UNIX technique of connecting the output of an
application to the input of another via pipes on the shell.

The pipe and filter architecture consists of one or more data sources. The data source is
connected to data filters via pipes. Filters process the data they receive, passing them to other
filters in the pipeline. The final data is received at a Data Sink:

Fig: Pipe and Filter Architecture

Pipe and Filter are used commonly for application that perform a lot of data processing such as
data analytics, data transformation, metadata extraction, and soon.

The filter can be running on the same machine, and they use actual UNIX pipes or shared
memory for communication. However, in large systems, these usually run on separate machines.

In summary, the Pipe and Filter architecture literally describes the software as a pipeline, where

data from a source flows in a linear path through filters that operate on the data, and pipes that are

~ 12 ~
Unit 6: Architectural Design Software Engineering

the connections between filters, eventually ending up in the data sink.The architecture is highly

extendible and parallelizable, but is only limited to specific use-cases.

Application architecture

Application architecture describes the patterns and techniques used to design and build an
application. The architecture gives you a roadmap and best practices to follow when building an
application, so that you end up with a well-structured app.

Software design patterns can help you to build an application. A pattern describes a repeatable
solution to a problem.

Patterns can be linked together to create more generic application architectures. Instead of
completely creating the architecture yourself, you can use existing design patterns, which also
ensure that things will work the way they’re supposed to.

As part of application architecture, there will be both front-end and back-end services. Front-end
development is concerned with the user experience of the app, while back-end development
focuses on providing access to the data, services, and other existing systems that make the app
work.

The architecture is a starting point or roadmap for building an application, but you’ll need to
make implementation choices not captured in architecture. For example, a first step is to choose
a programming language in which to write the application.

There are many programming languages used for software development. Certain languages may
be used to build certain types of applications, such as Swift for mobile apps or JavaScript for
front-end development.

JavaScript used with HTML and CSS is currently 1 of the more popular programming languages
for web application development.

Other popular programming languages include Ruby, Python, Swift, TypeScript, Java, PHP, and
SQL, among others. The language used when building an application will depend on the type of
application, available development resources, and the requirements.

Historically, applications were written as a single unit of code, where the components all share
the same resources and memory space. This style of architecture is referred to as a monolith.

Modern application architectures are more often loosely coupled, using micro-services
and application programming interfaces (APIs) to connect services, which provide the
foundation for cloud-native applications.

~ 13 ~
Unit 6: Architectural Design Software Engineering
Cloud-native development is a way to speed up how you build new applications, optimize
existing ones, and provide a consistent development and automated management experience
across private, public, and hybrid clouds.

Choosing an application architecture

When deciding which application architecture to use for a new application, or when evaluating
your current architecture, start by determining your strategic goals.

Then you can design the architecture that supports your goals, instead of choosing architecture
first and trying to make an application fit within that structure.

Consider how frequently you want to release updates to meet customer or operational needs, as
well as what functionality is required by either business objectives or development needs.

The ability to rapidly provide new services and new functionality to customers is one of the key
competitive differentiators a company can offer. And faster development lets businesses release
new features more often, and roll out updates as soon as vulnerability is discovered.

There are many different types of application architectures, but the most prominent today, based
on the relationships between the services are: monoliths and N-tier architecture (tightly coupled),
micro-services (decoupled), and event-driven architecture and service-oriented architecture
(loosely coupled).

Introduction to Decomposition and Modularity

To design system is to determine a set of components and inter component interface that satisfy
a specified set of requirements. Basically there are many methods to create good designs,
however very design method involves some kind of decomposition starting with a high level
depiction of the system key elements and creating lower level looks at how the system feature
and functions will fit together.

Wasserman has suggested that designs can be created in five ways:

1. Modular Decomposition: This construction is based on assigning functions to components.

Here the designer begins with a high level description of the functions that are to be implemented
and builds lower level explanations of how each component will be organized and related to
other components.

2. Data oriented Decomposition: This design is based on external data structures. The high
level descriptions depict general data structures and lower level descriptions provide detail on
what data elements will be involved and how they are related.

3. Event oriented Decomposition: This design is based on events that the system must handle
and uses information about how event changes the system state. The high

~ 14 ~
Unit 6: Architectural Design Software Engineering
level description catalogs the various states and lower level description describe how
state transformation take place.

4. Outside in Design: This approach his based on use inputs to the system. The high level
description lists all possible inputs a user can make and lower level descriptions address, what is
done with input and what outputs are produced.

5. Object oriented Design: This design identifies classes of objects and their interrelationships.
at the highest level each object type is described. At lower levels, the object attributes and
actions are discussed and the design explains how objects are related to one another.

~ 15 ~