Software Architecture - Architecture Styles and Patterns-1.pdf

457 views 40 slides May 10, 2024
Slide 1
Slide 1 of 40
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19
Slide 20
20
Slide 21
21
Slide 22
22
Slide 23
23
Slide 24
24
Slide 25
25
Slide 26
26
Slide 27
27
Slide 28
28
Slide 29
29
Slide 30
30
Slide 31
31
Slide 32
32
Slide 33
33
Slide 34
34
Slide 35
35
Slide 36
36
Slide 37
37
Slide 38
38
Slide 39
39
Slide 40
40

About This Presentation

présente les styles architecturaux et les patterns architecturaux dans de façon claire et concis.vous y trouverez la différence explicitement présenté entre style et pattern architectural


Slide Content

Régis ATEMENGUE
Software Engineer | Technical Instructor.
@regis_ate | www.regisatemengue.com
Software Architecture:
Architecture Styles and Patterns

Course objectives
Understanding the difference between
architecture Patterns and architecture
Style
1
Understanding Layered Architecture
@regis_ate | www.regisatemengue.com
Understanding C4 concepts

Introduction
Course overview
C4: Context,Containers,Components
and Classes
Architecture-Styles
Architecture-Patterns
2
Layered Architecture
Summary
Common Architecture Design
@regis_ate | www.regisatemengue.com

Introduction
3
@regis_ate | www.regisatemengue.com

Software Architecture Parts
Software Architecture consists of the structure
of the system (denoted as the heavy black lines
supporting the architecture), combined with
architectural characteristics (“-ilities”) the
system must
support, architecture decisions, and finally
design principles.
4
@regis_ate | www.regisatemengue.com
Fig 1 : SA Parts

Software Architecture Parts
5
The structure of the system, as
illustrated in the figure refers to the type
of architecture style (or styles) the
system is implemented in (such as
microservices, layered, or microkernel).
Describing an architecture solely by the
structure does not wholly elucidate an
architecture.
@regis_ate | www.regisatemengue.com
Fig 2 : SA Parts (Structure)

6
@regis_ate | www.regisatemengue.com
Architecture-Styles

Architecture-Style
7
An architectural style is a central, organizing concept for a
system.
Moderne HeimatstilGothique
@regis_ate | www.regisatemengue.com

8
Architecture-Style
An architectural style is a set of features characterizing an
architecture.
An Architectural Style, on the other hand, is just a name given to a
recurrent architectural design. Contrary to a pattern, it doesn't
exist to "solve" a problem.
Architectural Style refers to a set of guidelines or principles for
designing and building software systems.
@regis_ate | www.regisatemengue.com

Architecture-Style
9
Category Styles
Communication SOA, Message Bus etc...
Domain Microservice, Monolithic, etc...
Structure Component-based, Object-Oriented, plug-ins
Deployement Client-Server
@regis_ate | www.regisatemengue.com

10
@regis_ate | www.regisatemengue.com
Architecture-Patterns
An Architectural Pattern is a way of solving a recurring architectural
problem.
An Architectural Pattern is a specific, reusable solution to a common
problem or design issue in software architecture.
Architectural patterns are used to solve problems related to
architectural style. They are similar to design patterns but have a
different gateway. design patterns touch a specific part of the code to
apply a pattern. The level of granularity is the section of the code.
Architectural patterns have a larger level of granularity. It applies to
system components, functionality, and operation.

Architecture-Patterns
11
example: MVC, for instance, solves the problem of separating the UI
from the model. Sensor-Controller-Actuator is a pattern that will help
you with the problem of actuating in the face of several input sense
@regis_ate | www.regisatemengue.com
Fig 3 : SA MVC

12
Common Architecture Design
@regis_ate | www.regisatemengue.com

13
Two-tiered (Client/Server) architectural style
This is one of the most common
styles in distributed systems. It is
charac- terised by division of
components into either clients or
servers: Clients request services from
servers, and servers provide services
to clients, but servers do not require
services from clients. In general there
are a larger number of clients than
servers. Either or both clients/servers
may be composite components.
Fig 4:: Clients and Server
@regis_ate | www.regisatemengue.com

13
Two-tiered (Client/Server) architectural style
Advantages:
Applications can be easily developed and deployed due to simplicity.
The database server and application logic is physically close, which offers higher
performance, provided the users are manageable.
Disadvantages
On the other hand, the 2 tier architecture disadvantages are:
The performance of the application is degraded with increasing users. When
simultaneous client requests are made, application performance degrades rapidly
due to the fact that clients necessitate separate connections and increased CPU
memory.
Since the client holds most of the application logic, difficulties often arise in
controlling software versions and distributing new versions.
It’s often difficult to implement reliable security since users need to have login
information for every data server.
@regis_ate | www.regisatemengue.com

15
N-tiered architectural style
This style is useful for separating
application logic into separate
software packages at different levels.
of platform-specificity, so that
business logic is separated from UI
code and data persistence code. The
tiers or levels correspond to the clean
architecture levels, except that data
storage and UI aspects are typically
in separate tiers, whereas they are
considered to be at the same level in
the clean architecture. The style is
widely used for mobile apps,
enterprise systems, etc.
Fig 5: 3-tiered architectural
@regis_ate | www.regisatemengue.com

16
3-tiered architectural style
A 3 tier architecture refers to a software
architecture in which the user presentation
interface, the business logic and the data
storage server are developed and
maintained as independent modules on
separate hardware platforms. The client
does not directly communicate with the
database server. Instead, the client interacts
with an application server which further
communicates with the data tier which
contains the database server that is used
for query processing and transaction
management. The business tier serves as a
medium for the exchange for partially
processed data between the database
server and the client. A three-tier
architecture often allows any one of the
three tiers to be upgraded or replaced
independently. The three tiers of this
software architecture are:
Fig 6: 3-tiered architectural
@regis_ate | www.regisatemengue.com

17
Three-tiered (Client/Server) architectural style
The 3 tier architecture has the following advantages:
It can scale without degraded performance since no separate connections from
each client are not required.
There is improved data integrity because data corruption from client applications
can be eliminated by passing the data in the business tier for validation.
It’s often easier to implement improved security since client applications don’t have
direct database access.
It’s possible to scale or change the implementation of a tier on its own without
affecting other tiers of the system.
On the other hand, 3 tier architecture disadvantages are:
There is increased complexity of implementation as the communication points are
increased (presentation tier to business tier to the data tier, instead of direct client
tier to data tier communication).
@regis_ate | www.regisatemengue.com

19
Example N-tier architectures: enterprise and mobile
systems
Fig 7: 5-tiered architectural: mobile Systems
@regis_ate | www.regisatemengue.com

Layered Architecture
18
@regis_ate | www.regisatemengue.com

19
Layered Architecture
Components within the layered
architecture pattern are organized
into horizontal layers, each layer
performing a specific role within
the application (e.g., presentation
logic or business logic). Although
the layered architecture pattern
does not specify the number and
types of layers that must exist in
the pattern, most layered architec‐
tures consist of four standard
layers: presentation, business,
persis‐ tence, and database Figure.
Fig 8: Layered architecture
@regis_ate | www.regisatemengue.com

20
Layered Architecture : Description
Presentation layer: This is the layer that interacts with users through screens, forms, menus,
reports, etc. It is the most visible layer of the application. It defines how the application looks.
Business rules layer: This layer contains rules that determine the behavior of the whole
application, such as, “If an invoice is printed, then send an email to the customer, select all items
sold, and decrease their stock in the stock management module.”
The persistence layer is responsible for storing data and files. It gets the data from the database
or the hard drive and sends it back to the business layer which then sends it back to the
presentation layer.
Database layer: This layer contains the tables, indexes, and data managed by the application.
Searches and insert/delete/update operations are executed here.
@regis_ate | www.regisatemengue.com

21
One of the powerful features of the layered architecture pattern is the separation of concerns among
components. Components within a specific layer deal only with logic that pertains to that layer.
Keys Concepts
Fig 9:Layated Architecture
@regis_ate | www.regisatemengue.com

22
Keys Concepts(Closed Layers and request access)
Notice in Figure that each of the layers in the architecture is marked as being closed. This is a very
important concept in the lay‐ ered architecture pattern. A closed layer means that as a request moves
from layer to layer, it must go through the layer right below it to get to the next layer below that one
@regis_ate | www.regisatemengue.com
Fig 10: Layated Architecture

23
Keys Concepts(Layered of Isolation)
The layers of isolation concept means that changes made in one layer of the architecture generally
don’t impact or affect components in other layers
The layers of isolation concept also means that each layer is inde‐ pendent of the other layers, thereby
having little or no knowledge of the inner workings of other layers in the architecture.
Fig 10:Layated Architecture
@regis_ate | www.regisatemengue.com

Example Layered Architecture
24
Fig 12:Layated Architecture
@regis_ate | www.regisatemengue.com

25
There are several advantages to using layered architecture:
Layers are autonomous: A group of changes in one layer does not affect the others. This
is good because we can increase the functionality of a layer, for example, making an
application that works only on PCs to work on phones and tablets, without having to
rewrite the whole application.
Layers allow better system customization.
There are also a few key disadvantages:
Layers make an application more difficult to maintain. Each change requires analysis.
Layers may affect application performance because they create overhead in execution:
each layer in the upper levels must connect to those in the lower levels for each
operation in the system.
Advantages and Disadvantages
@regis_ate | www.regisatemengue.com

26
When Would I Use Layered Architecture?
@regis_ate | www.regisatemengue.com

27
C4: Context,Containers,Components and Classes
@regis_ate | www.regisatemengue.com

28
A C4 diagram is a graphical representation of a software
system's static structure and behavior using a collection of
diagrams. The 'C4' in C4 diagram stands for Context, Container,
Component, and Code, which are the four levels of abstraction
that the diagram illustrates.
C4: Context,Containers,Components and Classes

29
C4: Context,Containers,Components and Classes
If software architecture is about
the structure of a software
system, it’s worth
understanding what the major
building blocks are and how
they fit together at differing
levels of abstraction.
A Common set of abstractions
@regis_ate | www.regisatemengue.com

30
C4: Context,Containers,Components and Classes
@regis_ate | www.regisatemengue.com

31
C4: Context,Containers,Components and Classes
Classes: for most of us in an OO world, classes are the smallest building blocks of
our software systems.

32
C4: Context,Containers,Components and Classes
Components: A component can be
thought of as a logical grouping of
one or more classes. For example, an
audit component or an
authentication service that is used
by other components to determine
whether access is permitted to
specific resource. Components are
typically made up of a number of
collaborating classes, all behind
higher level contract.
@regis_ate | www.regisatemengue.com

34
C4: Context,Containers,Components and Classes
Containers: A container represents something in which components are executed
or where data resides. This could be anything from a web or application server
through to a rich client application or database. Containers are typically executables
that are started as a part of the overall system, but they don’t have to be separate
processes in their own right. For example, I treat each Java EE web application or
.NET website as a separate container regardless of whether they are running in the
same physical web server process. The key thing about understanding a software
system from a containers perspective is that any inter-container communication is
likely to require a remote interface such as a SOAP web service, RESTful interface,
Java RMI, Microsoft WCF, messaging, etc
@regis_ate | www.regisatemengue.com

35
C4: Containers,
@regis_ate | www.regisatemengue.com

C4: Context,Containers,Components and Classes
Systems: a system is the highest level of abstraction
and represents something that delivers value to
somebody. A system is made up of several separate
containers. Examples include a financial risk
management system, an Internet banking system, a
website and so on.
Context: A high-level diagram that sets the scene;
including key system dependencies and actors.
36
@regis_ate | www.regisatemengue.com

37
C4: Systems
@regis_ate | www.regisatemengue.com

38
C4: Abstraction
@regis_ate | www.regisatemengue.com

Next Course: Microservice Architecture
36
@regis_ate | www.regisatemengue.com