UNIT–III

• System models: Context models, behavioral models, data models,

object models, structured methods
• Design Engineering: Design process and design quality, design
concepts, the design model, software architecture, Architectural
styles and patterns.
• Introduction to UML: Basic Building Blocks of UML- Things,
Relationships and Diagrams
 SYSTEM MODELS
 Context Models.
 Behavioural Models.
 Data Models.
 Object Models.
 Structured Methods.
 Concept of System Model
The system model is a graphical representation that is used to describe
various processes of the system, the type of input and output of the
system.
These system models not only specify the user requirements but
they also serve as an important element in analysis and design phase.
we can develop the system model using different perspectives and
use of these perspectives gives the categorization of system models into
different models-
Using External Perspective context model of the system can be developed
Using Behavioral Perspective Behavioral model of the system can be developed.
Using Structural Perspective data model of the system can be developed
Using Object Model which is useful for object oriented systems.
 Context Models
Context model is a graphical representation of the system in
which the system boundaries are specified.
It is necessary to take decisions on certain aspects such as overall
cost of the system and time required to analyze such system.

Accounting system Maintenance system

Inventory
Inventory Report generation
control system
monitoring system system

Inventory data Account data base

base

Context model for Inventory control system

 Thus context models are the architectural models in which
environment of the system is shown.
All these defined relationships help in finding the requirements
of the system.
To detail out such architectural model some process model can
be used in conjunction with this.
The process model is again a graphical representation of system
processes.
The order of execution of various events can be understood with
the help of such process models
 Behavioral Models
• Behavioral models are used to describe the overall behavior of a
system. There are two types of models that depict the behavioral of
the system.
• Data Flow Model
• State Chart Diagram
• The data flow model represents the flow of data.
• state chart diagram represent the states that are occurring in the
system.
Data flow Diagram
• The data flow diagram depicts the information flow and the
transforms that are applied on the data as it moves input to output.
• The symbols that are used in data flow diagrams are
 The data flow diagrams are used to represent the system at any level of
abstraction.
The DFD can be partitioned into levels that represent increase in
information flow flow and detailed functionality.
Designing Data Flow Diagrams
The guideline for creating a DFD
1. Level 0 DFD, i.e context level DFD should depict the system as a single
bubble.
2. Primary input and primary output should be carefully identified.
3. While doing the refinement isolate processes, data objects and data
stores to represent the next level.
4. All the bubbles (processes) and arrows should be appropriately named.
5. One bubble at a time should be refined.
6. Information flow contiguity must be maintained from level to level.
Rules for Designing DFD:
1. No process can have only outputs (or) only inputs. The process must
have both input & output.

2. The verb phases in the problem description can be identified as

processes in he system.
3. There should be a direct flow between data stores external entity.
This flow should go through a process.

4. No data should move directly between external entities. The

dataflow should go through a process

Source Sink Source Sink

Don’t use in DFD
1)
External entity
Data store can not directly interact with entities.

2)
Two way communication is not possible
Main Points
• DFD is used to modelling the requirements
• We have to specify unique name
• DFD depicts the flow of data not the order of data
• The decision path represents logical expression should not be
specified.
State chart Diagram
They define different states of an object during its life time and
these states are changed by events.
To understand the design of state chart diagram consider
following example.
Consider an elevator for n floors has n buttons one for each floor.
1. There is a set of buttons called “elevator buttons”. If we want to visit
a particular floor is pressed.
2. There is another set of buttons called ‘floor button’. When a person
on particular floor want to visit another floor then the floor button
has to be pressed.
3. When an elevator has no request it remains at its current floor with
its door is closed.
 Data Models
Data modelling is the basic step in the analysis modelling. In the data
modelling the data objects are examined independently of processing.
The data domain is focused. And a model is created at the customer’s
level of abstraction.
The data model represents how data objects are related with one
another.
Data Model is an abstract model that represents the data objects,
data flow between these data objects, and the interrelationship between
these data objects. It is a way of storing data on a computer so that it can be
used in a more efficient manner for further purposes.
• Data model or data structure consists of following fundamental elements:
• Data Objects
• Attributes
• Relationships
 Data Objects, Attributes and
Relationships
Data Object:
Data object is a set of attributes(data items) that will be
manipulated within the software(system).
Each instance of data object can be identified with the help of
unique identifier.
Eg: A student can be identified by using his roll number.
The system can not perform without accessing to the instances of
object.
Data object is a collection of attributes that act as an aspect,
characteristic, quality, or descriptor of the object.
Elements of Data Model
Data Object: It can be any person, organization, device or software
product that produces or consumes information

Elements of
Data model

Attributes: These are used to

Relationship: These
name data object instance to
represent how data
describe characteristics or to
objects are connected to
make reference to another data
one another
subject object
 Object: vehicle
Attributes:
Make
Model
Color
Owner
Price

Object
The vehicle is a data object which can be defined or viewed with the
help of set of attributes.
What is attributes?
Attributes define properties of data object.
Typically there are three types of attributes-
1. Naming attributes
2. Descriptive attributes
3. Referential attributes
Naming Attributes:
These attributes are used to name an instance of data object.
Eg: In a vehicle data object make and model are naming attributes.
Descriptive attributes:
These attributes are used to describe the characteristics or features
of the data object.
Eg: In a vehicle data object color is a descriptive attributes.
Referential attributes:
These are the attributes that are used in making the reference to
another instance in another table.
Eg: In vehicle data object owner is a referential attribute.
 What is relationship
Relationship represents the connection between the data
objects.
Eg: The relationship between a shopkeeper and a toy is as shown
below.
Orders

Toy Sells Shopkeeper

shows

stocks
 Here the toy and shopkeeper are two objects that share
following relationships-
• Shopkeeper orders toys
• Shopkeeper sells toys
• Shopkeeper shows toys
• Shopkeeper stocks toys
Cardinality:
Cardinality in data modelling, cardinality specifies how the no.of
occurrences of one object is related to the no.of occurrences of
another object.
One to one – One object can relate to only one other object
One to many – One object can relate to many objects.
Many to many – some no.of occurrences of an object can relate to
some other no. of occurrences of another object.
Modality: Modality indicates whether or not a particular data object
must participate in the relationship.
Modality of a relationship is 0 if there is no explicit need for the
relationship to occur or the relationship is optional. The modality is 1 if
an occurrence of the relationship is mandatory.
Ex. Cardinality: Single Cardinality: Many purchase
customer waiting for actions are possible
purchase

Is provided with
Customer Purchase action

Modality: For purchase

action customer is must Modality: It is optional, there
(modality 1) may not be any purchasing
(modality 0)
 Entity Relationship Diagram

• The object relationship pair can be graphically represented by a diagram called

Entity Relationship Diagram(ERD).
• The ERD is mainly used in database applications but now it is more commonly
used in data design.
• The primary purpose of ERD is to represent the relationship between data objects.
• Various components of ERD are-
• Entity – It is an object
• Attributes – The attributes are properties or characteristics of an entity
• Relationship –When two entities share some information then it is denoted by
relationship.
Notations used in ER diagram
ER diagram for the relationship
of student and Teacher
 Object Models
• The object model is created for the systems possessing object
oriented programming approach.
• The object model is a natural representation of real world entities
such which are required in information processing systems. Such as
entities can be student, book, customer.
• These entities are typically called as object classes.
Eg: A car is a class but BMW is an object.
• Object is an executable entity of the class.
Unified Modelling Language (UML):
The unified modelling language popularly known as UML is an
common practice for object modelling.
UML Diagrams – Class diagram, Use-case diagram, sequence diagram,
state chart diagram and component diagram.
An object class in UML is represented by rectangle as shown below
Employee
Class name
Emp_ID
Emp_name
Designation Attributes
salary

Get_details
Show_details Operations

Fig: Object Class

 In this section we will discuss 3 types of models
1. Inheritance model
2. Object aggregation
3. Object Behavior Model
Inheritance Model
• Inheritance is a property by which the child class can inherit some
properties from the parent class.
• In object oriented modelling some classes are identified and if there
are some common attributes and services then inheritance is applied.

Ex. Person is a base class from which two child classes are inherited
student and employee. Further employee acts as a base class and its
child classes are manager, programmer and designer.
The child classes inherit the properties of their parent.
 In UML notation the inheritance is shown by upward arrow. The
inheritance is more specifically called generalization in UML. The inheritance is a
type of relationship. By inheritance the code reusability is used.
Object Aggregation:
One object can be formed by grouping one (or) more objects.

In above example Computer is a class which has screen, Memory and Keyboard.
That means in aggregation relationship one object can be formed by grouping one
or more objects.
The arrow with diamond is used to represent the aggregation relationship.
 Object Behavior Model
The object behavior model is for representing the sequence
of events occurring in the system. Typically it is represented by a
sequence diagram in UML.
Eg: Student registration for some course is given the object and
actors that interact with the system and the events that are taking place
are shown by sequence diagram.
In sequence diagram objects and actors are located at the top of
the diagram and labelled arrows represent the actions. The vertical
rectangle along the line of object represent the span of the
corresponding action. The sequence diagram helps in exposing of
operations of the system.
 Structured Methods
Applying the structured methods means designing different
models to represent that particular system. Various structured models
can be Context models, Process models, Data flow diagrams, state
chart diagrams, Entity relationship diagrams, object models.
The structured modelling provides the systematic framework for
system modelling as a part of requirement elicitation and analysis.
Along with these models documentation is essential in order to provide
line certain guideline in system development. Not only this use of CASE
tool support also helps to generate reports or code generation from the
system model.
 Drawbacks of structured
methods
• Non functional requirements can not be represented effectively using
structured methods.
• It is hard to predict whether the structured methods that are applied to
particular problem are suitable for solving that problem or not. Even it is
not possible to decide whether the structured method is suitable for
particular environment or not.
• Sometimes too much documentation hides the basic requirements of
the system. Unnecessary detailing is done in structured methods.
• The system models are represented in more detail so casual user can not
understand the system because he gets lost in the unnecessary details.
 Design Engineering
Software design is model of software which translates the
requirements into finished software product in which the details about
software data structures, architecture, interfaces and components that are
necessary to implement the system are given.
Design With The Context Of Software Engineering
During software engineering process, the first task is to identify and
analyze the requirements. Based on this analysis the software design is
developed.
This design serves as a basis for code generation and testing. Hence
software design is an intermediate process which translates the analysis
model into design model.
• The four types of elements of Analysis model are scenario based
elements, class based elements, behavioral elements, and flow
oriented elements.
• The class based elements of analysis model are used to create class
diagrams.
• The flow oriented elements and class based elements are used to
create architecture design.
• Software design is very important for assessing the quality of
software.
• Without software design, it is difficult to test the software product.
• Software design used to make the necessary changes without
disturbing other part of the software.
 Design process and design
quality

Software design is an iterative process using which the user

requirements can be translated into the software product.
Characteristics of good Design:
• The good design should implement all the requirements specified by
the customer.
• The design should be simple.
• The design should provide complete picture of the software.
Quality Guideline
The goal of any software design is to produce high quality software.
1. The design architecture should be created using following issues-
• The design should be created using architectural styles and patterns.
• Each component of design should posses good design characteristics
• The implementation of design should be evolutionary, so that testing can be performed at each phase of
implementation.
2. In the design the data, architecture, interfaces and components should be clearly represented.
3. The design should be modular.
4. The data structure should be appropriately chosen for the design of specific problem.
5. The Components should be used in the design so that functional independency can be
achieved in the design.
6. Based on requirement analysis the design should be created.
7. The interface in the design should be such that the complexity between the connected
components of the system gets reduced.
8. Every design of the software system should be convey its meaning appropriately and
effectively.
Quality Attributes:
The design quality attributes popularly known as FURPS (Functionality, Usability, Reliability,
Performance, and Supportability)
Functionality:
It can be checked by assessing the set of features & capabilities of the functions. The functions
should be general and should not work only for particular set of inputs.
Usability:
It can be assessed by knowing the usefulness of the system.
Reliability:
It is a measure of frequency & severity of failure. Reliability refers to the consistency and
repeatability of the measures. The Mean Time To Failure(MTTF) is a metric that is widely used to measure
the product’s performance and reliability.
Performance:
It is a measure that represents the response of the system.
Measuring the performance means measuring the processing speed, memory usage, response time and
efficiency.
Supportability:
it is also called maintainability. It is the ability to adopt the enhancement or changes made in the
software. It also means the ability to withstand in a given environment.
 Design Concepts
“The software design concept provides a framework for implementing the right
software.”
Certain issues that are considered while designing the software.
1. Abstraction
2. Modularity
3. Architecture
4. Refinement
5. Pattern
6. Information Hiding
7. Functional Independence
8. Refactoring
9. Design classes
1) Abstraction
Hiding the unnecessary details.
2 types of abstraction
 Procedural Abstraction
 Data Abstraction
Procedural Abstraction:
It gives the named sequence of instructions in the specific function. That means
the functionality of procedure is mentioned by its implementation details are hidden.
Eg:Search the record is a procedural abstraction in which implementation details are
hidden(i.e. Enter the name, compare each name of the record against the entered one,
if a match is found then declare success!! Otherwise declare name not found.
Data Abstraction:
The collection of data objects is represented.
Difference between the procedural and Data abstraction is that procedural
abstraction focuses on eliminating duplicate code within a single program, whereas
data abstraction hides the implementation details of data from the user of an API.
2) Modularity:
The software is divided in to separately named and addressable
components that called as modules.
Monolithic software is hard to hold/grasp for the software
engineer, hence it has now become a trend to divide the software into
number of products. But there is a correlation between the no.of
modules and overall cost of the software product.
3) Architecture:
Architecture means representation of overall structure of an
integrated system.
Architecture provides the basic framework for the software
system so that important framework activities can be conducted in
systematic manner.
4) Refinement:
Refinement is actually a process of elaboration/developing.
Abstraction and refinement are complementary concepts the
major difference is that in the abstraction low-level details are hidden.
Refinement helps the designer to elaborate low-level details.
5) Pattern:
Design pattern acts as a design solution for a particular problem
occurring in specific domain. Using design pattern designer can
determine whether
- pattern can be reusable.
- Pattern can be used for current work.
- pattern can be used to solve similar kind of problem with
different functionality.
6) Information Hiding:
Information hiding means the modules are designed in such
away that information contained in one module cannot be accessible to
the other module.
The advantage of information hiding is basically in testing &
maintenance. Due to information hiding some data and procedures of
one module can be hidden from another module.
One can make changes in the desired module without affecting
the other module.
7) Functional Independence:
By using functional independence functions may be divided and
interfaces are simplified.
Independent modules are easier to maintain with reduced error
propagation.
Functional independence is a key to good design and design is
the key to software quality.
The functional independence is assessed using two qualitative
criteria – cohesion and coupling.
Cohesion:
With the help of cohesion the information hiding can be done.
A cohesive module Perform only one task in software procedure
with little interaction with other models.
Different types of cohesion are
Coincidentally cohesive
Logically cohesive
Temporal cohesive
Procedural cohesive
Communication cohesive
Coincidentally cohesive :
The modules in which the set of tasks are related with each other loosely then
such modules are called coincidentally cohesive.
Logically cohesive:
A module that perform the task that are logically related with each other is
called logically cohesive.
Temporal cohesive:
The module in which the task needs to be executed in some specific time span is
called temporal cohesive.
Procedural cohesive:
When processing elements of a module are related with one another and must
be executed in some specific order then such module is called procedural cohesive.
Communication cohesive:
When the processing elements of a module share the data then such module is
communication cohesive.
Coupling
Coupling effectively represents how the models can be
connected with other module or with the outside world.
The goal is to strive for lowest possible coupling among models in
software design.
It should also reduce the cost in program changes testing and
maintenance.
Various types of coupling are
Data coupling
Control coupling
Common coupling
Content coupling
Data coupling:
The Data coupling is possible by parameter passing or data
interaction
Control coupling:
The modules share related control data in control coupling
Common coupling:
In common coupling common data or a global data is share
among the modules.
Content coupling:
Content coupling occurs when one module makes use of data or
control information maintained in another module.
8)Refactoring
“The process of changing a software system in such a way that
the external behavior of the design do not get changed however the
internal structure get improved.”
Benefits
• The redundancy can be achieved
• Inefficient algorithms can be eliminated or can be replaced by
efficient one
• Poorly Constructed or in accurate data structures can be removed or
replaced.
• Other design failures can be rectified.
9)Design classes
Design classes are defined as the classes that describe some
elements of problem domain, in which the problem is viewed from
users point of view.
The goal of design classes is
To refine the analysis classes by providing the detail design. Using
detailed design further implementation is carried out.
User interface class
The user interface class defines all the interactions with the system. The user
interface classes is basically a visual representation.
Business domain class
Business domain classes are the refinement of analysis classes. These classes
identify the attributes and services that are needed to implement some elements of
business domain.
Process class
Process class is used business domain.it define processes required by business
domain.
Persistent class
These classes represent the data store such as data bases which will be
retained as it is even after the execution of software.
System class
These classes are responsible for software management and control functions
that are used for system operation.
 The Design Model
• The design model can be viewed in two different dimensions.
• The process dimension denotes the progress of design model that occurs due
to various software tasks that get executed as the part of software process.
• The abstract dimension represents in how much detail the analysis model is
transformed into design model.
• In following diagram the dashed line shows the boundary between analysis
and design model.
• In both the analysis and design models the same UML diagrams are used but
in analysis model the UML diagrams are abstract and in design model these
are refined and elaborated. Moreover in design model the implementation
specific details are provided.
• Along the horizontal axis various such as architecture element,
interface element, component level elements and deployment level
elements are given.
• It is not necessary that these elements have to be developed in
sequential manner. First of all the preliminary architecture design
occurs then interface design and component level design occur in
parallel. The deployment level design ends up after the completions
of complete design model.
 Data Design element
• The data design represents the high level of abstraction. This data
represented at data design level is refined gradually for implementing
the computer based system.
• The data has great impact on the architecture of software systems.
Hence structure of data is very important factor in software design.
• Data appears in the form of data structures and algorithms at the
program component level.
• At the application level it appears as the database and at the business
level it appears as data warehouse and data mining. Thus data plays
an important role in software design.
 Architectural design element
• The architectural design gives the layout for overall view of the
software architectural model can be built using following sources-
• Data flow models or class diagrams.
• Information obtained from application domain.
• Architectural patterns and styles.
 Interface design elements
• Interface design represents the detailed design of the software system. In
interface design how information flows from one component to toher
component of the system is depicted. Typically there are three types of
interfaces –
• User Interface: By this interface user interacts with the system
Ex:GUI
• External Interface: This is the interface of the system components with the external
entities
Ex: networking.
• Internal interface: This is an interface which represents the inter component
communication of the system.
Ex: Two classes can communicate with each other by operations or by
passing messages.
 Component level design elements
• The component level design is more detailed design of the software
system along with the specifications. The component level design
elements describe the internal details of the component. In
component level design all the local data objects, required data
structures and algorithmic details and procedural details are exposed.
• Fig. represents that component order makes use of another
component form.
• The order is dependent upon the component form. These two objects
can be interfaced with each other.
 Deployment level design
elements
• The deployment level design elements indicate how software
functions and software subsystems are assigned to the physical
computing environment of the software product.
• For example web browsers may work in mobile phoned or they may
run on client PC or can execute on server machines.
 Introduction To Architectural Design
What Is Architecture?
• Architectural design represents the structure of data and program
components that are required to build a computer-based system.
• It considers
• the architectural style that the system will take,
• the structure and properties of the components that constitute the system, and
• the interrelationships that occur among all architectural components of a
system.
 Software Architecture
The architectural design is the design process for identifying the
subsystems making up the system and framework for subsystem control
and communication.
The goal of architectural design is to establish the overall
structure of software system. Architectural design represents the link
between design specification and actual design process.
“Software architecture is a structure of systems which consists of
various components, externally visible properties of the components and
the inter-relationship among these components.”
 Importance Of Software Architecture
There are three reasons why the software architecture is so important?
1. Software architecture gives the representation of the stakeholders
can take active part in the software development process. This helps
in clear specification/understanding of requirements.
2. Some early design decisions can be taken using software
performance and operations remain under control.
3. The software architecture gives a clear cut idea about the computer
based system which is to be built.
The design of software architecture considers two levels of the design
pyramid
• Data design
• Architectural design.
Data design enables us to represent the data component of the
architecture.
Architectural design focuses on the representation of the structure
of software components, their properties, and interactions.
 Data Design
The data design activity translates data objects as part of the analysis model
into data structures at the software component level and, when necessary, a database
architecture at the application level.
At the program component level, the design of data structures and the
associated algorithms required to manipulate them is essential to the creation of
high-quality applications.
At the application level, the translation of a data model (derived as part of
requirements engineering) into a database is pivotal to achieving the business
objectives of a system.
At the business level, the collection of information stored in disparate
databases and reorganized into a ―data warehouse‖ enables data mining or
knowledge discovery that can have an impact on
the success of the business itself.
2.1) Data design at the Architectural Level:
The challenge for a business has been to extract useful
information from this data environment, particularly when the
information desired is cross functional.
To solve this challenge, the business IT community has developed
data mining techniques, also called knowledge discovery in databases
(KDD), that navigate through existing databases in an attempt to extract
appropriate business-level information. An alternative solution, called a
data warehouse, adds an additional layer to the data architecture. a data
warehouse is a large, independent database that encompasses some, but
not all, of the data that are stored in databases that serve the set of
applications required by a business.
 2.2) Data design at the Component Level:
Data design at the component level focuses on the representation of
data structures that are directly accessed by one or more software
components. The following set of principles for data specification:
The systematic analysis principles applied to function and behavior
should also be applied to data.
All data structures and the operations to be performed on each should
be identified.
A data dictionary should be established and used to define both data
and program design.
Low-level data design decisions should be deferred until late in the
design process
 The representation of data structure should be known only to
those modules that must make direct use of the data contained within
the structure.
A library of useful data structures and the operations that may be
applied to them should be developed.
A software design and programming language should support the
specification and realization of abstract data types.
 Structural Partitioning
The program structure can be partitioned horizontally or
vertically.
Horizontal partitioning
Horizontal Partitioning defines separate branches of the modular
hierarchy for each major program function.
Horizontal Partitioning can be done by partitioning system into:
input, data transformation (processing) and output.
In horizontal partitioning the design making modules are at top of
the architecture.
Vertical partitioning
Vertical partitioning suggests the control and work should be
distributed top-down in program structure.
In vertical partitioning
Define separate branches of the module hierarchy for each major
function.
Use control modules to co-ordinate communication between
functions.
 Architectural styles and patterns
• The architectural model or style is a pattern for creating the system
architecture for given problem. However, most of the large systems are
heterogeneous and do not follow single architectural style.
• System categories define the architectural style
1. Components: They perform a function
Ex: Database, simple computational modules, clients, servers and filters.
2. Connectors: Enable communications. They define how the components
communicate, co-ordinate and co-operate.
3. Constraints: Define how the system can be integrated.
4. Semantic models: specify how to determine a system’s overall properties
from the properties of its parts.
Data-centered architectures:

In this architecture the data store lies at the center of the

architecture and other components frequently access it by performing
add, delete and modify operations.
The client software requests for the data to central repository.
Sometime the client software accesses the data from the central
repository without any change in data or without any change in actions
of software actions.
Data centered architecture posses the property of interchangeability.
Interchangeability means any component from the architecture
can be replaced by new component without affecting the working of
other components.
Data-flow architectures
In this architecture series of transformations are applied to
produce the output data. The set of components called filters are
connected by pipes to perform the data from on component to another.
These filters work independently without a bothering about the working
of neighboring filter.
If the data flow degenerates into a single line of transforms, it is
termed as batch sequential.
Call and return architectures.
The program structure can be easily modified or scaled. The
program structure is organized into modules within the program.
In this architecture how modules call each other. The program
structure decomposes the function into control hierarchy where a main
program invokes number of program components.
In this architecture the hierarchical control for call and return is
represented.
Object-oriented architectures.

In this architecture the system is decomposed into number of

interacting objects.
These objects encapsulate data and the corresponding
operations that must be applied to manipulate the data.
The object oriented decomposition is concerned with
identifying objects classes, their attributes and the corresponding
operations. These is some control models used to co-ordinate the
object operations.
Layered architectures.
The basic structure of a layered architecture is illustrated in
Figure. A number of different layers are defined, each accomplishing
operations that progressively become closer to the machine instruction
set. At the outer layer, components service user interface operations. At
the inner layer, components perform operating system interfacing.
Intermediate layers provide utility services and application software
functions.
 Architectural Patterns
The architectural pattern is basically an approach for handling
behavioral characteristics of software systems.
Following are the architectural pattern domains.
1. Concurrency
2. Persistence
3. Distribution
Concurrency:
Concurrency means handling multiple tasks in parallel.for
example in operating system, multiple tasks are executed in parallel.
Hence concurrency is a pattern which represents that the system
components can interact with each other in parallel. The benefit of this
pattern is that system efficiency can be achieved.
Persistence:
Continuity in the data can be maintained by the persistence
pattern. In other words the data used in earlier execution can be made
available further by soring it in files or in database.
These files/databases can be modified in the software system as
per the need.
In object oriented system the values of all attributes various
operations that are to be executed are persistent for further use. Thus
broadly there are two patterns.
i)Database management pattern
ii) Application level pattern
Distribution:
Distribution pattern refers to the way in which the system
components communicate with each other in distribution systems.
There are two major problems that occur in distribution pattern
• The nature of interconnection of the components.
• The nature of communication.
These problems can be solved by other pattern called broker
pattern. The broker pattern lies between server and client components so
that the client server communication can be established properly. When
client want some service from server, it first sends message to broker.
The broker then conveys this message to server and completes the
connection. Typically example is CORBA is a distributed architecture in
which broker pattern is used.
Different Software Architecture Patterns :
• Layered Pattern
• Client-Server Pattern
• Event-Driven Pattern
• Microkernel Pattern
• Microservices Pattern
1.LayeredPattern:
As the name suggests, components(code) in this pattern are separated into layers of
subtasks and they are arranged one above another.
• Each layer has unique tasks to do and all the layers are independent of one another. Since
each layer is independent, one can modify the code inside a layer without affecting others.

• It is the most commonly used pattern for designing the majority of software. This layer is
also known as ‘N-tier architecture’. Basically, this pattern has 4 layers.
• Presentation layer (The user interface layer where we see and enter data into an
application.)
• Business layer (this layer is responsible for executing business logic as per the request.)
• Application layer (this layer acts as a medium for communication between the
‘presentation layer’ and ‘data layer’.
• Data layer (this layer has a database for managing data.)
• Ideal for:
• E-commerce web applications development like Amazon.
2. Client-Server Pattern :

The client-server pattern has two major entities. They are a server and
multiple clients.
• Here the server has resources(data, files or services) and a client requests
the server for a particular resource. Then the server processes the request
and responds back accordingly.
• Examples of software developed in this pattern:
• Email.
• WWW.
• File sharing apps.
• Banking, etc…
So this pattern is suitable for developing the kind of software listed in
the examples.
3. Event-Driven Pattern :
Event-Driven Architecture is an agile approach in which services
(operations) of the software are triggered by events.
• Well, what does an event mean?
• When a user takes action in the application built using the EDA approach, a
state change happens and a reaction is generated that is called an event.
Exploratory Data Analysis (EDA) is an analysis approach that identifies
general patterns in the data. These patterns include outliers and features of
the data that might be unexpected. EDA is an important first step in any data
analysis.
• Eg: A new user fills the signup form and clicks the signup button on Facebook
and then a FB account is created for him, which is an event.
Ideal for:
• Building websites with JavaScript and e-commerce websites in general.
4. Microkernel Pattern :
Microkernel pattern has two major components. They are a core
system and plug-in modules.
• The core system handles the fundamental and minimal operations of the
application.
• The plug-in modules handle the extended functionalities (like extra
features) and customized processing.
• Let’s imagine, you have successfully built a chat application. And the
basic functionality of the app is that you can text with people across the
world without an internet connection. After some time, you would like to
add a voice messaging feature to the application, then you are adding the
feature successfully. You can add that feature to the already developed
application because the microkernel pattern facilitates you to add
features as plug-ins.
Microkernel pattern is ideal for:
• Product-based applications and scheduling applications. We love new
features that keep giving dopamine boost to our brain. Such as
Instagram reels, YouTube Shorts and a lot more that feasts us digitally.
So this pattern is mostly preferred for app development.
5. Microservices Pattern :
The collection of small services that are combined to form the actual
application is the concept of microservices pattern.
Instead of building a bigger application, small programs are built for every
service (function) of an application independently. And those small programs are
bundled together to be a full-fledged application.
So adding new features and modifying existing microservices without
affecting other microservices are no longer a challenge when an application is built
in a microservices pattern.
Modules in the application of microservices patterns are loosely coupled. So
they are easily understandable, modifiable and scalable.
Example Netflix is one of the most popular examples of software built-in
microservices architecture. This pattern is most suitable for websites and web apps
having small components.