CS5002NT - Software

Engineering
SOFTWARE ARCHITECTURE
WEEK 23
WEEKLY
OBJECTIVE
• Software Architecture

• Importance of Software Architecture

• Different types of Software Architecture

DESIGN MODEL
• Data/Class design

• Architecture design

• Interface design

• Component-Level design
SOFTWARE ARCHITECTURE
• An outline that allows you to express and define a structural schema for all

kinds of software system[blueprint, High level design]

• Reusable solution

• Provides predefined set of subsystems, roles and responsibilities, including

the rules and roadmap for defining relationships

SOFTWARE ARCHITECTURE
• Addresses concerns like performance limitations, high availability[traffic],

and minimizing business risk

• Countless piece of architecture that implies the same pattern[scalability

and maintainability]
IMPORTANCE OF SOFTWARE
ARCHITECTURE
• Defining basic characteristics of an Application

⚬ Knowing each architecture’s characteristics, strengths, and weaknesses

becomes important for choosing the right one to meet your business

objectives

⚬ For instance, some architecture patterns can be naturally used for

highly scalable applications, whereas others can be used for agile

applications
IMPORTANCE OF SOFTWARE
ARCHITECTURE
• Maintaining Quality and Efficiency

⚬ High possibility that any application you build might face quality

issues[bugs, quality issues, performance issues]

⚬ Selecting an architecture pattern can help minimize the quality issues

while simultaneously maintaining efficiency

IMPORTANCE OF SOFTWARE
ARCHITECTURE
• Providing Agility

⚬ Natural for software applications to undergo numerous modifications

and iterations during software development and even after production

⚬ Planning a core software architecture beforehand provides agility to the

application and makes future moderations effortless

IMPORTANCE OF SOFTWARE
ARCHITECTURE
• Problem Solving

⚬ Prior planning and knowledge of a software architecture give a clear

idea of how the application and its components will function

⚬ With an architecture in place, the developing team can adopt the best

practices to resolve complex processes and solve any errors in the

future

⚬ E.g: Error in Development, fix affecting other components.

DIFFERENT TYPES OF SOFTWARE ARCHITECTURE
PATTERN
• Layered Architecture Pattern

• Event-Driven Architecture Pattern

• Microkernel Architecture Pattern

• Microservices Architecture Pattern

LAYERED ARCHITECTURE PATTERN
• Tiered Architecture or N-Tier Architecture[logical divide]

• Most common architecture - usually build around a database

• Code is arranged so the data enters the top layer and works its way down

each layer until it reaches the bottom, which is usually a database

LAYERED ARCHITECTURE PATTERN
• Code is arranged so t4 Distinct Layer

⚬ Presentation[user interface layer ]

⚬ Business

⚬ Persistence

⚬ Database
LAYERED ARCHITECTURE PATTERN
• Stands out - each layer plays a distinct role with the application and is

marked as closed[hidden]

• Eg: Business Layer make process of data, presentation layer user its output only.

• Concepts – layers of isolation – enables you to modify components within

one layer without affecting the other layers[maintain and update]

LAYERED ARCHITECTURE PATTERN
LAYERED ARCHITECTURE PATTERN -
USAGE
• Application that are needed to be build quickly[Simple and structured]

• Enterprise applications that require traditional IT departments and

processes

• Appropriate for teams with inexperienced developers and limited

knowledge of architecture patterns

• Application that require strict standards of maintainability and

testability[layered]
LAYERED ARCHITECTURE PATTERN -
DOWNSIDE
• Performance wise, it can be inefficient sometimes.[multiple layers]

• Skipping previous layers to create tight coupling can lead to a logical mess

full of complex interdependencies

• Basic modification can require a complete redeployment of the application

EVENT DRIVEN ARCHITECTURE PATTERN
• Building a central unit that accepts all data and then delegates it to the

separate modules that handle the particular type

• Made up of decoupled, single-purpose event processing components that

asynchronously receive and process events

• E.g: Event: "Order Placed“-> inventory service, payment service

• e.g: sending a letter through postoffice

EVENT DRIVEN ARCHITECTURE PATTERN
• Consist of two topologies

Mediator - when multiple steps are needed to be orchestrated within an

event bus through a central mediator[controller]

steps (: order → verify → payment → shipment)

Broker - used to chain events together without using a central mediator

EVENT DRIVEN ARCHITECTURE PATTERN
EVENT DRIVEN ARCHITECTURE PATTERN -
USAGE
• Application where individual data blocks interact with only a few modules

• For real time systems and data tracking.[live location, sensor, stock Trading]
EVENT DRIVEN ARCHITECTURE PATTERN -
DOWNSIDE
• Testing individual modules can only be done if they are independent,

otherwise, they need to be tested in a fully functional system

• When several modules are handling the same event, error handling

becomes challenging to structure.

MICROKERNEL ARCHITECTURE PATTERN
• Basically a two component architecture pattern

⚬ a core system

⚬ several plugin modules

• The core system works on minimal functionality to keep the system operational.

• The plug-in modules are independent components with specialized processing.

• E.g Browser like Chrome,

• Cocktail/Mocktail
MICROKERNEL ARCHITECTURE PATTERN
MICROKERNEL ARCHITECTURE PATTERN -
USAGE
• Applications that suits evolutionary design and incremental development.

• E.g : IDE

• Applications that have a fixed set of core routines[System Monitor] and

dynamic set of rules that needs frequent updates[Security updates].

• E.g Antivirus
MICROKERNEL ARCHITECTURE PATTERN -
DOWNFALLS
• The plugin must have good handshaking code so that the microkernel is

aware of the plugin installation and is ready to work.

• Changing a microkernel is almost impossible if there are multiple plugins

depending on it.

• It is difficult to choose the right granularity[which function to choose] for a

kernel function in advance and more complex at a later stage.

MICROSERVICES ARCHITECTURE PATTERN
• Instead of building one big program, the goal is to create a number of

different tiny programs and then create a new little program every time

someone wants to add a new feature

• The components are deployed as separate units through an effective,

streamlined delivery pipeline[separate deploy]

• The pattern’s benefits are enhanced scalability and a high degree of

decoupling within the application[scalable to particular module]

MICROSERVICES ARCHITECTURE PATTERN
• Owing to its decoupled and independent characteristics, the components

are accessed through a remote access protocol[http,gRPC].[own server/

containner, work independently]

• Same components can be separately developed, deployed, and tested

without interdependency on any other service component.

MICROSERVICES ARCHITECTURE PATTERN
MICROSERVICES ARCHITECTURE PATTERN -
USAGE
• For applications where scalability matters. [high traffic handle ]

• Business and web applications that require rapid development and has

remote teams globally.

MICROSERVICES ARCHITECTURE PATTERN -
DOWNFALL
• Designing the right level of granularity for a service component is always a

challenge.[Deciding how big or small each microservice ]

• All applications do not include tasks that can be split into independent

units.[tightly connected features ]

• Performance can be affected when tasks are spread across different

microservices.[network delays or overhead]

THANK YOU
END OF
LECTURE