CT-365 SOFTWARE ENGINEERING

LECTURE 3

ARCHITECTURAL DESIGN

HUMA TABASSUM
LECTURER
DEPT. OF COMPUTER SCIENCE & INFORMATION TECHNOLOGY
NED UNIVERSITY OF ENGINEERING & TECHNOLOGY
Wrong Approach!

2
Architectural Design
• Architectural design is concerned with understanding how a software
system should be organized, and designing the overall structure of that
system.
• It is the critical link between design and requirements engineering, as it
identifies the main structural components in a system and the relationships
between them.
• 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.
• Architecture in the large is concerned with the architecture of complex
enterprise systems that include other systems, programs, and program
components.
• These enterprise systems are distributed over different computers, which may be
owned and managed by different companies. 3
Architectural Representations
• Simple, informal block diagrams showing entities and relationships
are the most frequently used method for documenting software
architectures.
• But these have been criticized because they lack semantics, do not show the
types of relationships between entities, nor the visible properties of entities
in the architecture.
• Box and line diagrams are very abstract – they do not show the
nature of component relationships, nor the externally visible
properties of the sub-systems.
• However, useful for communication with stakeholders and for project
planning.
4
Architectural Design Decisions

5
Architecture Reuse
• 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 or ‘styles’.
• These capture the essence of an architecture and can be instantiated in
different ways.
6
Architecture and System Characteristics
• 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.

7
Architectural Views

8
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).

9
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
the are not useful.

• Patterns may be represented using tabular and graphical descriptions.

11
Architectural Patterns/Architectural Design
1. Model View Controller:
• Separates presentation and interaction from the system data.
• The system is structured into three logical components that interact
with each other:
• The Model component manages the system data and associated operations
on that data.
• The View component defines and manages how the data is presented to the
user.
• The Controller component manages user interaction (e.g., key presses, mouse
clicks, etc.) and passes these interactions to the View and the Model.

12
• MVC Pattern is used when there are multiple ways to view and interact
with data.
• Also used when the future requirements for interaction and presentation
of data are unknown.
• This pattern allows the data to change independently of its representation
and vice versa.
• Supports presentation of the same data in different ways.

13
MVC in the Real-World
• MVC is helpful when planning your app, because it gives you an
outline of how your ideas should be organized into actual code.
• For instance, let’s imagine you’re creating a To-do list app. This app
will let users create tasks and organize them into lists.
• The Model in a to-do app might define what a “task” is and that a “list” is a
collection of tasks.
• The View code will define what the to-dos and lists looks like, visually.
• The tasks could have large font, or be a certain color.
• Finally, the Controller could define how a user adds a task or marks another
as complete.
• The Controller connects the View’s add button to the Model, so that when you click “add
task,” the Model adds a new task.
14
• MVC is a framework for thinking about programming, and for
organizing your program’s files.
• To signify the idea that your code should be organized by its function,
developers will create folders for each part of MVC. (The idea that
apps should be divided based on the function of each part of the code
is sometimes referred to as separation of concerns.)
• The MVC pattern, separates elements of a system, allowing them to
change independently.
• For example, adding a new view or changing an existing view can be done
without any changes to the underlying data in the model.

15
MVC Architecture Pattern

Benefits Downsides
• Faster development process • Complexity
• Ability to provide multiple views • Cost of frequent updates
• Support for asynchronous • Hard to understand (due to the
technique above mentioned issues)
• Modification does not affect the • Must have strict rules of access
entire model over the reactions to all events
• MVC model returns the data (called methods)
without formatting
• SEO friendly development platform
16
17
Architectural Patterns/Architectural Design
2. Layered Architecture:
• The Layered Architecture pattern is another way of achieving separation
and independence.
• Here, the system functionality is organized into separate layers, and each
layer only relies on the facilities and services offered by the layer
immediately beneath it.
• This approach supports the incremental development of systems.
• As a layer is developed, some of the services provided by that layer may be
made available to users.
• Layered architecture makes it easier to provide multi-platform
implementations of an application system.
• Only the machine dependent layers need be re-implemented to take
account of the facilities of a different operating system or database. 18
• This figure is an example of a layered
architecture with four layers.
• The lowest layer includes system support
software—typically, database and operating
system support.
• The next layer is the application layer,
which includes the components concerned
with the application functionality and utility
components used by other application
components.
• The third layer is concerned with user
interface management and providing user
authentication and authorization, with the
top layer providing user interface facilities.
19
The following figure shows that the iLearn digital learning system,
has a four-layer architecture that follows this pattern.

Figure: The architecture of the iLearn system

20
Layered Architecture Pattern

Benefits Downsides
• Simple and easy to learn and • Scalability is difficult
implement • Maintenance is difficult
• Reduced dependency • Interdependence between layers
• Testing is easier • Lack of parallel processing
• Low cost overheads

21
22
Architectural Patterns/Architectural Design
3. Blackboard Architectural Pattern:
• The Blackboard architectural pattern is useful for problems for which no deterministic
solution strategies are known.
• In Blackboard several specialized subsystems assemble their knowledge to build a
possibly partial or approximate solution.
• The blackboard paradigm defines heterogeneous problem solving representations as
independent modules called knowledge sources.
• Knowledge sources can be seen as specialists in sub-fields of the global application and
are only able to solve sub-problems.
• They read and write relevant data in a blackboard which is a structured global memory
where a solution to the problem under consideration is incrementally constructed.
• When a knowledge source produces a significant change in the blackboard, it generates
an event. 23
For example, Blackboard Architecture in
Multilingual Translation.
• Problem-solving in blackboard architecture begins with the
announcement of a problem and writing initial data onto the
blackboard.
• The specialists are watching the blackboard looking for an
opportunity in order to make a contribution to solution development.
• When a specialist finds this opportunity, they record the contribution
on the blackboard, in the hope that others will use his contribution
for final problem-solving.
• This process continues until the problem is solved.
• The procedure to a solution in the blackboard architecture is assumed
to be unknown in advance. 25
• Knowledge sources: Knowledge sources (KSs) are "independent modules
that contain the knowledge needed for problem-solving".
• Each language specialist in the above example of multilingual translation is a KS.
• KSs need to focus on the progress of solving the current problem – track the
sentences to be translated.
• However, it is not necessary for a KS to communicate with or even know the
existence of other KSs.
• Blackboard: Blackboard is the place where language specialists work
together to develop the translation.
• The formal definition of the blackboard is "a globally accessible memory/database
which is used for intermediate, partial results of problem-solving".
• Each KS can read and write the shared blackboard.
• Controller: The controller decides "which candidate knowledge source to
execute next in runtime for optimal problem solution".
• In the multilingual translation problem, if there are multiple experts in a language
available for a piece of text, Controller is the coordinator to choose who should go
for the translation. 26
Blackboard Architecture Pattern

Benefits Downsides
• Efficient sharing of data • High complexity
• Strategies to complex problems • Lot of effort to fine-tune the
do not need to be pre-planned controller
• Low coupling • Difficult to test
• Knowledge sources do not only • The quality of the solution is not
apply to a specific problem guaranteed due to its non-
• KSs can work concurrently deterministic nature
• Problems might only be partially
• Controller can choose the most solved
suitable knowledge source for
execution • Not optimal if data changes
frequently 27
28
Architectural Patterns/Architectural Design
4. Pipe and Filter Architectural Pattern:
• The Pipe and Filter architecture in system design is a structural pattern that segments a
process into a sequence of discrete steps, called filters, connected by channels, referred
to as pipes.
• Each filter is responsible for a specific processing task, such as transforming, validating,
or aggregating data.
• The data flows through these filters via pipes, which transport the output of one filter to
the input of the next.
• This architecture enhances modularity, as each filter operates independently and focuses
on a single function.
• It also promotes reusability, enabling filters to be reused across different systems or
applications.
• Additionally, the architecture is flexible and scalable; filters can be added, removed, or
rearranged with minimal impact on the overall system, and multiple instances of filters
can run concurrently to handle larger data volumes.
• This organized and systematic approach makes the Pipe and Filter architecture a popular
choice for data processing tasks, compilers, and applications requiring structured and
sequential data transformation. 29
• Pumps: These components at the beginning of the process act as data sources. They push data into the system,
starting the flow through the pipeline.
• Filters: Each filter performs a specific, independent task. Filters can transform, validate, or process the data in some
way before passing it along. In the diagram, there are two levels of filters. The first filter processes the data received
from the pump and passes it to the second filter. The second filter further processes the data and prepares it for the
next stage.
• Pipes: Pipes are the channels through which data flows from one filter to the next. They connect each component in
the sequence, ensuring a smooth and orderly transfer of data. In the diagram, pipes are shown as arrows between
components.
• Sinks: These are the endpoints where the processed data is finally collected or used. After passing through all the
filters, the data reaches the sink, completing its journey through the pipeline.
• Parallel Processing: The diagram also shows a parallel structure where two independent pipelines run side by side.
Each pipeline starts with its own pump, processes the data through a series of filters, and ends at a separate sink. This
indicates that the architecture supports parallel processing, allowing different data streams to be processed
simultaneously without interference. 30
 For Example
• ETL tools use a series of components to
extract data from various sources,
transform it according to business rules,
and load it into target systems.
•A compiler performs language
transformation: Input is in language A
and output is in language B. In order to
do that the input goes through various
stages inside the compiler — these
stages form the pipeline.
• The Pipeline is one of the defining
features of the UNIX shell, and all Unix-
based systems.
• It allows you to tie the output of one
program to the input of another. The benefit
it brings is that you don’t have to save the
results of one program before you can start
processing it with another. The long-term
and even more important benefit is that it
encourages programs to be small and simple. 31
Pipe and Filter Architecture Pattern

Benefits Downsides
• Loose and flexible coupling • Addition of a large number of
• Filters can be changed without independent filters may reduce
modifying other filters performance due to excessive
computational overheads
• Parallel processing
• Not suitable for interactive
• Reusability systems
• Not appropriate for long-running
computations.

32
33
Architectural Patterns/Architectural Design
5. Client-Server Architecture
• In the client-server architecture patterns, there are two main components:
The client, which is the service requester, and the server, which is the
service provider.
• Although both client and server may be located within the same system,
they often communicate over a network on separate hardware.
• The client component initiates certain interactions with the server to
generate the services needed.
• While the client components have ports that describe the needed services,
the servers have ports that describe the services they provide.
• Both components are linked by request/reply connectors.
• Client-Server architecture can be 2-tier, 3-tier,…, up to n-tier. 34
• A classic example of this architecture
pattern is the World Wide Web.
• The client-server pattern is also used
for online applications such as file
sharing and email.
• A simple example is online banking
services.
• When a bank customer accesses online
banking services using a web browser,
the client initiates a request to the
bank's web server.
• In this case, the web browser is the
client, accessing the bank's web server
for data using the customer's login
details.
• The application server interprets this
data using the bank's business logic and
then provides the appropriate output
to the web server.
35
Client-Server Architecture

Benefits Downsides
• Scalability • Single Point of Failure
• Modularity • Network Dependency
• Security • Increased Complexity
• Performance • Scalability Challenges (Load Balancing)
• Limited Offline Functionality
• Cost

36
37
38