UNIT III

SOFTWARE DESIGN
Software design – Design process – Design concepts – Coupling – Cohesion – Functional
independence – Design patterns – Model-view-controller – Publish- subscribe – Adapter –
Command – Strategy – Observer – Proxy – Facade – Architectural styles – Layered - Client Server
- Tiered - Pipe and filter- User interface design-Case Study.

1. Software design:
The design phase of software development deals with transforming the customer
requirements as described in the SRS documents into a form implementable using a programming
language. The software design process can be divided into the following three levels or phases of
design:
1. Interface Design
2. Architectural Design
3. Detailed Design
Elements of a System
1. Architecture: This is the conceptual model that defines the structure, behavior, and
views of a system. We can use flowcharts to represent and illustrate the architecture.
2. Modules: These are components that handle one specific task in a system. A
combination of the modules makes up the system.
3. Components: This provides a particular function or group of related functions. They are
made up of modules.
4. Interfaces: This is the shared boundary across which the components of a system
exchange information and relate.
5. Data: This is the management of the information and data flow.
The design phase of software development deals with transforming the customer
requirements as described in the SRS documents into a form implementable using a programming
language. The software design process can be divided into the following three levels or phases of
design:
1. Interface Design
2. Architectural Design
3. Detailed Design
Elements of a System
1. Architecture: This is the conceptual model that defines the structure, behavior, and
views of a system. We can use flowcharts to represent and illustrate the architecture.
2. Modules: These are components that handle one specific task in a system. A
combination of the modules makes up the system.
3. Components: This provides a particular function or group of related functions. They are
made up of modules.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

4. Interfaces: This is the shared boundary across which the components of a system
exchange information and relate.
5. Data: This is the management of the information and data flow.

Interface
Design

Interface design is the specification of the interaction between a system and its environment.
This phase proceeds at a high level of abstraction with respect to the inner workings of the system
i.e, during interface design, the internal of the systems are completely ignored, and the system is
treated as a black box. Attention is focused on the dialogue between the target system and the
users, devices, and other systems with which it interacts. The design problem statement
produced during the problem analysis step should identify the people, other systems, and devices
which are collectively called agents.
Interface design should include the following details:
1. Precise description of events in the environment, or messages from agents to which the
system must respond.
2. Precise description of the events or messages that the system must produce.
3. Specification of the data, and the formats of the data coming into and going out of the
system.
4. Specification of the ordering and timing relationships between incoming events or
messages, and outgoing events or outputs.
Architectural Design
Architectural design is the specification of the major components of a system, their
responsibilities, properties, interfaces, and the relationships and interactions between them. In
architectural design, the overall structure of the system is chosen, but the internal details of major
components are ignored. Issues in architectural design includes:
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

1. Gross decomposition of the systems into major components.

2. Allocation of functional responsibilities to components.
3. Component Interfaces.
4. Component scaling and performance properties, resource consumption properties,
reliability properties, and so forth.
5. Communication and interaction between components.
The architectural design adds important details ignored during the interface design. Design of
the internals of the major components is ignored until the last phase of the design.
Detailed Design
Design is the specification of the internal elements of all major system components, their
properties, relationships, processing, and often their algorithms and the data structures. The
detailed design may include:
1. Decomposition of major system components into program units.
2. Allocation of functional responsibilities to units.
3. User interfaces.
4. Unit states and state changes.
5. Data and control interaction between units.
6. Data packaging and implementation, including issues of scope and visibility of program
elements.
7. Algorithms and data structures.

2. Software Design Principles

Software design principles are concerned with providing means to handle the complexity of
the design process effectively. Effectively managing the complexity will not only reduce the effort
needed for design but can also reduce the scope of introducing errors during design.

Following are the principles of software engineering

 Problem Partitioning

For small problem, we can handle the entire problem at once but for the significant
problem, divide the problems and conquer the problem it means to divide the problem
into smaller pieces so that each piece can be captured separately.

For software design, the goal is to divide the problem into manageable pieces.

Benefits of Problem Partitioning

1. Software is easy to understand
2. Software becomes simple
3. Software is easy to test
4. Software is easy to modify
5. Software is easy to maintain
6. Software is easy to expand

Abstraction

An abstraction is a tool that enables a designer to consider a component at an

abstract level without bothering about the internal details of the implementation.
Abstraction can be used for existing element as well as the component being designed.
Here, there are two common abstraction mechanisms

1. Functional Abstraction
2. Data Abstraction

Functional Abstraction
i. A module is specified by the method it performs.
ii. The details of the algorithm to accomplish the functions are not visible to
the user of the function.

Functional abstraction forms the basis for Function oriented design

approaches.

Data Abstraction

Details of the data elements are not visible to the users of data. Data Abstraction
forms the basis for Object Oriented design approaches.
 Modularity

Modularity specifies to the division of software into separate modules which are
differently named and addressed and are integrated later on in to obtain the completely
functional software. It is the only property that allows a program to be intellectually
manageable. Single large programs are difficult to understand and read due to a large
number of reference variables, control paths, global variables, etc.

o ach module is a well-defined system that can be used with other

applications.
o Each module has single specified objectives.
o Modules can be separately compiled and saved in the library.
o Modules should be easier to use than to build.
o Modules are simpler from outside than inside.

Advantages and Disadvantages of Modularity

In this topic, we will discuss various advantage and disadvantage of Modularity.

Advantages of Modularity

There are several advantages of Modularity

o It allows large programs to be written by several or different people

o It encourages the creation of commonly used routines to be placed in the
library and used by other programs.
o It simplifies the overlay procedure of loading a large program into main
storage.
o It provides more checkpoints to measure progress.
o It provides a framework for complete testing, more accessible to test
 o It produced the well designed and more readable program.

Disadvantages of Modularity

There are several disadvantages of Modularity

o Execution time maybe, but not certainly, longer

o Storage size perhaps, but is not certainly, increased
o Compilation and loading time may be longer
o Inter-module communication problems may be increased
o More linkage required, run-time may be longer, more source lines must be
written, and more documentation has to be done
3. Design concepts

The set of fundamental software design concepts are as follows:

1. Abstraction
 A solution is stated in large terms using the language of the problem
environment at the highest level abstraction.
 The lower level of abstraction provides a more detail description of the
solution.
 A sequence of instruction that contain a specific and limited function refers
in a procedural abstraction.
 A collection of data that describes a data object is a data abstraction.
2. Architecture
 The complete structure of the software is known as software architecture.
 Structure provides conceptual integrity for a system in a number of ways.
 The architecture is the structure of program modules where they interact
with each other in a specialized way.
 The components use the structure of data.
 The aim of the software design is to obtain an architectural framework of a
system.
 The more detailed design activities are conducted from the framework.
3. Patterns
A design pattern describes a design structure and that structure solves a
particular design problem in a specified content.
 4. Modularity
 A software is separately divided into name and addressable components.
Sometime they are called as modules which integrate to satisfy the problem
requirements.
 Modularity is the single attribute of a software that permits a program to be
managed easily.
5. Information hiding
Modules must be specified and designed so that the information like algorithm
and data presented in a module is not accessible for other modules not requiring that
information.

 Functional independence

The functional independence is the concept of separation and related to the

concept of modularity, abstraction and information hiding.
The functional independence is accessed using two criteria i.e Cohesion and
coupling.
Cohesion
Cohesion is an extension of the information hiding concept.
A cohesive module performs a single task and it requires a small interaction with
the other components in other parts of the program.
Coupling
Coupling is an indication of interconnection between modules in a structure of
software.

6. Refinement
Refinement is a top-down design approach.
It is a process of elaboration.
A program is established for refining levels of procedural details.
A hierarchy is established by decomposing a statement of function in a stepwise
manner till the programming language statement are reached.
7. Refactoring
It is a reorganization technique which simplifies the design of components
without changing its function behaviour.
Refactoring is the process of changing the software system in a way that it does
not change the external behaviour of the code still improves its internal structure.
 8. Design classes
The model of software is defined as a set of design classes.
Every class describes the elements of problem domain and that focus on features
of the problem which are user visible.

OO design concept in Software Engineering

Software design model elements

1.2 Coupling and Cohesion
Module Coupling

In software engineering, the coupling is the degree of interdependence between

software modules. Two modules that are tightly coupled are strongly dependent on each
other. However, two modules that are loosely coupled are not dependent on each other.
Uncoupled modules have no interdependence at all within them.

The various types of coupling techniques are shown in fig:

A good design is the one that has low coupling. Coupling is measured by the
number of relations between the modules. That is, the coupling increases as the number
of calls between modules increase or the amount of shared data is large. Thus, it can be
said that a design with high coupling will have more errors.

Types of Module Coupling

 1. No Direct Coupling: There is no direct coupling between M1 and M2

In this case, modules are subordinates to different modules. Therefore, no direct coupling.

2. Data Coupling: When data of one module is passed to another module, this is called data
coupling.
 3. Stamp Coupling: Two modules are stamp coupled if they communicate using composite
data items such as structure, objects, etc. When the module passes non-global data structure or entire
structure to another module, they are said to be stamp coupled. For example, passing structure
variable in C or object in C++ language to a module.

4. Control Coupling: Control Coupling exists among two modules if data from one module
is used to direct the structure of instruction execution in another.

5. External Coupling: External Coupling arises when two modules share an externally
imposed data format, communication protocols, or device interface. This is related to communication
to external tools and devices.

6. Common Coupling: Two modules are common coupled if they share information through
some global data items.

7. Content Coupling: Content Coupling exists among two modules if they share code, e.g.,
a branch from one module into another module.

Module Cohesion

In computer programming, cohesion defines to the degree to which the elements of a module
belong together. Thus, cohesion measures the strength of relationships between pieces of
functionality within a given module. For example, in highly cohesive systems, functionality is
strongly related.

Cohesion is an ordinal type of measurement and is generally described as "high cohesion" or

"low cohesion."
Types of Modules Cohesion
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

1. Functional Cohesion: Functional Cohesion is said to exist if the different elements of a

module, cooperate to achieve a single function.
2. Sequential Cohesion: A module is said to possess sequential cohesion if the element of a
module form the components of the sequence, where the output from one component of the sequence
is input to the next.
3. Communicational Cohesion: A module is said to have communicational cohesion, if all
tasks of the module refer to or update the same data structure, e.g., the set of functions defined on an
array or a stack.
4. Procedural Cohesion: A module is said to be procedural cohesion if the set of purpose of
the module are all parts of a procedure in which particular sequence of steps has to be carried out for
achieving a goal, e.g., the algorithm for decoding a message.
5. Temporal Cohesion: When a module includes functions that are associated by the fact
that all the methods must be executed in the same time, the module is said to exhibit temporal
cohesion.

6. Logical Cohesion: A module is said to be logically cohesive if all the elements of the
module perform a similar operation. For example Error handling, data input and data output,
etc.
7. Coincidental Cohesion: A module is said to have coincidental cohesion if it
performs a set of tasks that are associated with each other very loosely, if at all.

Differentiate between Coupling and Cohesion

Coupling Cohesion

Coupling is also c Cohesion is also called Intra-

alled Inter-Module Module Binding.
Binding.
Cohesion shows the relationship
Coupli
ng shows the within the module.
relationships
between modules.
Coupling s Cohesion shows the
hows module's relative functional
t strength.
he relative
independenc
e
between
t
he modules.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

While creating, you should While creating you should aim for high
aim for low coupling, i.e., cohesion, i.e., a cohesive component/ module focuses
dependency among modules on a single function (i.e., single-mindedness) with little
should be less. interaction with other modules of the system.

In cohesion, the module focuses

In coupling, modules are linked to the
other modules. on a single thing.

FUNCTIONAL INDEPENDENCE IN SOFTWARE ENGINEERING

Functional independence in software engineering means that when a module focuses on a

single task, it should be able to accomplish it with very little interaction with other modules.

In software engineering, if a module is functionally independent of other module then it

means it has high cohesion and low coupling.

Functional independence is essential for good software design. Example of

functional independence
We will take an example of simple college level project to explain concept of
functional independence.

Suppose you and your friends are asked to work on a calculator project as a team. Here
we need to develop each calculator functionality in form of modules taking two user inputs.

So our modules are addition Module, subtraction

Module, division Module, multiplication Module. Each
one of you pick up one module for development purpose.

Before you enter into development phase, you and your team needs to make sure to design
the project in such a way that each of the module that you develop individually should be able
to perform its assigned task without requiring much or no interaction with your friends module.
What I intend to say is, if you are working on addition Module then your module should
be able to independently perform addition operation on receiving user input. It should not
require to make any interaction with other modules like subtraction Module, multiplication
Module or etc.

This is actually the concept of having module as functional independence of other

modules. There is an advantage of functional independence in software engineering which we
are going to discuss next.

Advantage of functional independence

 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

Advantages of functional independence are given below:

Error isolation
When a module is functionally independent then it performs most of its task
independently without interacting with other modules much. This reduces the chances of error
getting propagated to other modules. This helps in easily isolating and tracing the error.

Module reusability
A functionally independent module performs some well defined and specific task. So it
becomes easy to reuse such modules in different program requiring same functionality.

Understandability
A functionally independent module is less complex so easy to understand. Since such
modules are less interaction with other modules so can be understood in isolation.

1.3. Design Patterns

In software engineering, a design pattern is a general repeatable solution to a commonly

occurring problem in software design. A design pattern isn't a finished design that can be
transformed directly into code. It is a description or template for how to solve a problem that can
be used in many different situations.

Uses of Design Patterns

Design patterns can speed up the development process by providing tested, proven
development paradigms. Effective software design requires considering issues that may not
become visible until later in the implementation. Reusing design patterns helps to prevent subtle
issues that can cause major problems and improves code readability for coders and architects
familiar with the patterns.

Often, people only understand how to apply certain software design techniques to certain
problems. These techniques are difficult to apply to a broader range ofproblems. Design patterns
provide general solutions, documented in a format that doesn't require specifics tied to a particular
problem.

In addition, patterns allow developers to communicate using well-known, well understood

names for software interactions. Common design patterns can be improved over time, making
them more robust than ad-hoc designs.

Creational design patterns

These design patterns are all about class instantiation. This pattern can befurther
divided into class-creation patterns and object-creational patterns. While
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

class-creation patterns use inheritance effectively in the instantiation p object-creation patterns

use delegation effectively to get the job done.

 AbstractFactory
Creates an instance of several families of classes
 Builder
Separates object construction from its representation
 FactoryMethod
Creates an instance of several derived classes
 ObjectPool
Avoid expensive acquisition and release of resources by recycling objectsthat are no
longer in use
 Prototype
A fully initialized instance to be copied or cloned
 Singleton
A class of which only a single instance can exist
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

Structural design patterns

These design patterns are all about Class and Object composition. S class-creation patterns use
inheritance to compose interfaces. Structura patterns define ways to compose objects to obtain
new functionality

ty.

Adapter
Match interfaces of different classes
 Bridge
Separates an object’s interface from its implementation
 Composite
A tree structure of simple and composite objects
 Decorator
Add responsibilities to objects dynamically
 Facade
A single class that represents an entire subsystem
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

 Flyweight
A fine-grained instance used for efficient sharing

PrivateClassData
Restricts accessor/mutator access

 Proxy
An object representing another object

Behavioral design patterns

These design patterns are all about Class's objects communication. Behavioral patterns are
those patterns that are most specifically concerned with communication between objects.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

 Chainofresponsibility
A way of passing a request between a chain of objects
 Command
Encapsulate a command request as an object
 Interpreter
A way to include language elements in a program
 Iterator
Sequentially access the elements of a collection
 Mediator
Defines simplified communication between classes
 Memento
Capture and restore an object's internal state
 NullObject
Designed to act as a default value of an object
 Observer
A way of notifying change to a number of classes

State
Alter an object's behavior when its state changes
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

 Strategy
Encapsulates an algorithm inside a class
 Templatemethod
Defer the exact steps of an algorithm to a subclass
 Visitor
Defines a new operation to a class without change

Types of Design Patterns

There are three types of Design Patterns,
 Creational Design Pattern
 Structural Design Pattern
 Behavioral Design PatternCreational Design Pattern
Creational Design Pattern abstract the instantiation process. They help in making a
systemindependent of how its objects are created, composed and represented.
Importance of Creational Design Patterns:
 A class creational Pattern uses inheritance to vary the class that’s instantiated,
whereas anobject creational pattern will delegate instantiation to another object.
 Creational patterns become important as systems evolve to depend more on object
composition than class inheritance. As that happens, emphasis shifts away from hardcoding a
fixed set of behaviors toward defining a smaller set of fundamental behaviors that can be
composed into any number of more complex ones.
 Creating objects with particular behaviors requires more than simply instantiating a
class.
When to ue Creational Design Patterns
 Complex Object Creation: Use creational patterns when the process of creating an
object iscomplex, involving multiple steps, or requires the configuration of various parameters.
 Promoting Reusability: Creational patterns promote object creation in a way that
can be reused across different parts of the code or even in different projects, enhancing
modularityand maintainability.
 Reducing Coupling: Creational patterns can help reduce the coupling between
client codeand the classes being instantiated, making the system more flexible and adaptable
to changes.
 Singleton Requirements: Use the Singleton pattern when exactly one instance of a
class isneeded, providing a global point of access to that instance.
 Step-by-Step Construction: Builder pattern of creational design patterns is suitable
when
you need to construct a complex object step by step, allowing for the creation of
differentrepresentations of the same object.
Advantages of Creational Design Patterns
 Flexibility and Adaptability: Creational patterns make it easier to introduce new
types of objects or change the way objects are created without modifying existing client code.
This enhances the system’s flexibility and adaptability to change.
 Reusability: By providing a standardized way to create objects, creational patterns
promote code reuse across different parts of the application or even in different projects. This
leads tomore maintainable and scalable software.
 Centralized Control: Creational patterns, such as Singleton and Factory patterns,
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

allow forcentralized control over the instantiation process. This can be advantageous in
managing resources, enforcing constraints, or ensuring a single point of access.
 Scalability: With creational patterns, it’s easier to scale and extend a system by
adding newtypes of objects or introducing variations without causing major disruptions to the
existing codebase.
 Promotion of Good Design Practices: Creational patterns often encourage adherence
to good design principles such as abstraction, encapsulation, and the separation of concerns. This
leads to cleaner, more maintainable code.
Disadvantages of Creational Design Patterns
 Increased Complexity: Introducing creational patterns can sometimes lead to
increasedcomplexity in the codebase, especially when dealing with a large number of classes,
interfaces, and relationships.
 Overhead: Using certain creational patterns, such as the Abstract Factory or
Prototypepattern, may introduce overhead due to the creation of a large number of classes and
interfaces.
 Dependency on Patterns: Over-reliance on creational patterns can make the
codebasedependent on a specific pattern, making it challenging to adapt to changes or switch
to alternative solutions.
 Readability and Understanding: The use of certain creational patterns might make
the code less readable and harder to understand, especially for developers who are not familiar
with thespecific pattern being employed.
Structural Design Patterns
Structural patterns are concerned with how classes and objects are composed to form
larger structures. Structural class patterns use inheritance to compose interfaces or
[Link] of Structural Design Patterns
 This pattern is particularly useful for making independently developed class
libraries worktogether.
 Structural object patterns describe ways to compose objects to realize new
functionality.
 It added flexibility of object composition comesfrom the ability to change the
composition atrun-time, which is impossible with static class composition.
When to ue Structural Design Patterns
 Adapting to Interfaces: Use structural patterns like the Adapter pattern when you
need to make existing classes work with others without modifying their source code. This is
particularlyuseful when integrating with third-party libraries or legacy code.
 Organizing Object Relationships: Structural patterns such as the Decorator pattern
are useful when you need to add new functionalities to objects by composing them in a
flexibleand reusable way, avoiding the need for subclassing.
 Simplifying Complex Systems: When dealing with complex systems, structural
patterns likethe Facade pattern can be used to provide a simplified and unified interface to a
set of interfaces in a subsystem.
 Managing Object Lifecycle: The Proxy pattern is helpful when you need to control
access toan object, either for security purposes, to delay object creation, or to manage the
object’s lifecycle.
 Hierarchical Class Structures: The Composite pattern is suitable when dealing
with hierarchical class structures where clients need to treat individual objects and
compositions ofobjects uniformly.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

Advantages of Structural Design Patterns

 Flexibility and Adaptability: Structural patterns enhance flexibility by allowing
objects to becomposed in various ways. This makes it easier to adapt to changing
requirements without modifying existing code.
 Code Reusability: These patterns promote code reuse by providing a standardized
way to compose objects. Components can be reused in different contexts, reducing
redundancy andimproving maintainability.
 Improved Scalability: As systems grow in complexity, structural patterns provide a
scalable way to organize and manage the relationships between classes and objects. This
supports thegrowth of the system without causing a significant increase in complexity.
 Simplified Integration: Structural patterns, such as the Adapter pattern, facilitate
the integration of existing components or third-party libraries by providing a standardized
[Link] makes it easier to incorporate new functionalities into an existing system.
 Easier Maintenance: By promoting modularity and encapsulation, structural
patterns contribute to easier maintenance. Changes to one part of the system are less likely to
affectother parts, reducing the risk of unintended consequences.
 Solves Recurring Design Problems: These patterns encapsulate solutions to
recurring design problems. By applying proven solutions, developers can focus on higher-
level designchallenges unique to their specific applications.
Disadvantages of Structural Design Patterns
 Complexity: Introducing structural patterns can sometimes lead to increased
complexity in thecodebase, especially when multiple patterns are used or when dealing with a
large number of classes and interfaces.
 Overhead: Some structural patterns, such as the Composite pattern, may introduce
overhead due to the additional layers of abstraction and complexity introduced to manage
hierarchies of objects.
 Maintenance Challenges: Changes to the structure of classes or relationships
betweenobjects may become more challenging when structural patterns are heavily relied
upon. Modifying the structure may require updates to multiple components.
 Limited Applicability: Not all structural patterns are universally applicable. The
suitability of apattern depends on the specific requirements of the system, and using a pattern
in the wrong context may lead to unnecessary complexity.
Behavioral Design Pattern
Behavioral patterns are concerned with algorithms and the assignment of
responsibilities between objects. Behavioral patterns describe not just patterns of objects or
classes but also thepatterns of communication between them.
Importance of Behavioral Design Pattern
 These patterns characterize complex control flow that’s difficult to follow at run-
time.
 They shift focus away from flow of control to let you concentratejust on the way
objects areinterconnected.
 Behavioral class patterns use inheritance to distribute behavior between classes.
When to ue Behavioral Design Patterns
 Communication Between Objects: Use behavioral patterns when you want to
define how objects communicate, collaborate, and interact with each other in a flexible and
reusable way.
 Encapsulation of Behavior: Apply behavioral patterns to encapsulate algorithms,
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

strategies,or behaviors, allowing them to vary independently from the objects that use them.
This promotes code reusability and maintainability.
 Dynamic Behavior Changes: Use behavioral patterns when you need to allow for
dynamicchanges in an object’s behavior at runtime without altering its code. This is
particularly relevant for systems that require flexibility in behavior.
 State-Dependent Behavior: State pattern is suitable when an object’s behavior
depends on its internal state, and the object needs to change its behavior dynamically as its
state changes.
 Interactions Between Objects: Behavioral patterns are valuable when you want to
model
and manage interactions between objects in a way that is clear, modular, and easy to
understand.
Advantages of Behavioral Design Patterns
Flexibility and Adaptability:
 Behavioral patterns enhance flexibility by allowing objects to interact in a more
dynamic andadaptable way. This makes it easier to modify or extend the behavior of a system
without altering existing code.
 Code Reusability:
 Behavioral patterns promote code reusability by encapsulating algorithms,
strategies, or behaviors in separate objects. This allows the same behavior to be reused across
differentparts of the system.
 Separation of Concerns:
 These patterns contribute to the separation of concerns by dividing the
responsibilities ofdifferent classes, making the codebase more modular and easier to
understand.
 Encapsulation of Algorithms:
 Behavioral patterns encapsulate algorithms, strategies, or behaviors in standalone
objects,making it possible to modify or extend the behavior without affecting the client code.
 Ease of Maintenance:
 With well-defined roles and responsibilities for objects, behavioral patterns contribute
to easier maintenance. Changes to the behavior can be localized, reducing the impact on the rest
of the code.
Disadvantages of Behavioral Design Patterns
 Increased Complexity: Introducing behavioral patterns can sometimes lead to
increased complexity in the codebase, especially when multiple patterns are used or when
there is anexcessive use of design patterns in general.
 Over-Engineering: There is a risk of over-engineering when applying behavioral
patterns where simpler solutions would suffice. Overuse of patterns may result in code that is
more complex than necessary.
 Limited Applicability: Not all behavioral patterns are universally applicable. The
suitability ofa pattern depends on the specific requirements of the system, and using a pattern
in the wrong context may lead to unnecessary complexity.
 Code Readability: In certain cases, applying behavioral patterns may make the code
less readable and harder to understand, especially for developers who are not familiar with the
specific pattern being employed.
 Scalability Concerns: As the complexity of a system increases, the scalability of
certain behavioral patterns may become a concern. For example, the Observer pattern may
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

becomeless efficient with a large number of observers.

Model-view-controller(MVC)

Definition

The MVC pattern in Software Engineering Architecture is defined as an applicationbeing

separated into three logical components: Model, View and Controller.

Model

This component in the architecture will represent all data-related logic. This includes
defining how the data is formed. In other words, this holds the definition for many ofthe types
that we use in the application. In many cases, the model here refers to the type of data that we
are dealing with in the application. This component also notifiesits dependents about data
changes.

View

Contains all User interface (UI) logic in the application. This component of the
application encapsulates mainly the UI related logic which includes things that the enduser will
manipulate like dropdown buttons and web pages etc.

Controller

Controllers exist as a layer between Model and View components to process all the
business logic arising from user input. It is responsible to handle inputs from the View
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

components, manipulate data using the models from the Model component and thenfinally
interact with the view components again to render the final output to the enduser. Responsible
for manipulating the data.

Why MVC

The MVC pattern today is widely used for many applications and remain a popularchoice.
This is due to a few key reasons
Faster Development Time
Given the separation of the applications into the three distinct areas, this means that more
developers are able to work on each part separately. e.g if a developer works onthe model, he is
not directly blocking another developer from building up the view component of the application
and thus allows teams to speed up development purelydue to the nature of the architecture itself.
Greater Testability
Each component being separated from each other means that developers are able totest
each one separately and in isolation. This is made easier due to the clear separation of concerns
that is applied in this architecture pattern. e.g a Model can betested easily without the view
component.
Easy extension of views/modification
Any changes in view component will usually not affect the model component, hence
developers using this pattern can easily extend and add new views to the application todisplay
the data from model in different ways. Thus, modifications are easier to be isolated to a single
component instead of affecting the entire application
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

MVC in Real World application

Web applications

Many web applications today run primarily on MVC architecture. In particular,

[Link] MVC framework offers and MVC pattern as one of the development model.

This framework provides developers with a MVC abstraction built on top of [Link]
and thus provide a large set of added functionality.
Sample code from [Link] documentation

An example of a controller action in [Link] MVC framework.

Another example framework for web that uses MVC is Sails. Sails is a nodeJs framework
that provides added functionality. A sails app comes preconfigured with theMVC structure
predefined and developers can just use it right out of the box.

1.4. Adapter

What is an Adapter?

An adapter is a class that transforms (adapts) an interface into another.

For example, an adapter implements an interface A and gets injected an interface B. When
the adapter is instantiated it gets injected in its constructor an object that implements interface
B. This adapter is then injected wherever interface A is neededand receives method requests that
it transforms and proxies to the inner object thatimplements interface B.

If I managed to confuse you, no worries, I give a more concrete example further below.

Two different types of adapters

The adapters on the left side, representing the UI, are called the Primary or Driving
Adapters because they are the ones to start some action on the application, while theadapters on
the right side, representing the connections to the backend tools, are called the Secondary or
Driven Adapters because they always react to an action ofa primary adapter.

There is also a difference on how the ports/adapters are used:

 On the left side, the adapter depends on the port and gets injected a concrete
implementation of the port, which contains the use case. On this side, both theport and its
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

concrete implementation (the use case) belong inside theapplication;

 On the right side, the adapter is the concrete implementation of the port and is
injected in our business logic although our business logic only knows about the interface. On
this side, the port belongs inside the application, but its concrete implementation belongs
outside and it wraps around some externaltool.

What are the benefits?

Using this port/adapter design, with our application in the centre of the system, allowsus to
keep the application isolated from the implementation details like ephemeral technologies,
tools and delivery mechanism

COMMAND:

The command pattern is a behavioral design pattern in which an object is used to

encapsulate all information needed to perform an action or trigger an event at a later
[Link] information includes the method name, the object that owns the method and
values for the method parameters. Four terms always associated with the command
pattern are command, receiver, invoker and client. A command object knows about receiver
andinvokes a method of the receiver. Values for parameters of the receiver method are
storedin the command.

The receiver object to execute these methods is also stored in the command object

by aggregation. The receiver then does the work when the method

in command is called. An invoker object knows how to execute a command, and

optionally does bookkeeping about the command execution.

The invoker does not know anything about a concrete command, it knows only about
the command interface. Invoker object(s), command objects and receiver objects are held by
a client object, the client decides which receiver objects it assigns to the command objects,
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

and which commands it assigns to the invoker.

The client decides which commands to execute at which points. To execute a

command, it passes the command object to the invoker object.

Using command objects makes it easier to construct general components that need to
delegate, sequence or execute method calls at a time of their choosing without the need to
know the class of the method or the method parameters.

Using an invoker object allows bookkeeping about command executions to be

conveniently performed, as well as implementing different modes for commands, which are
managed by the invoker object, without the need for the client to be aware of the existence
of bookkeeping or modes.
System Design Strategy – Software Engineering
A good system design is to organize the program modules in such a way that are easy to
developand change. Structured design techniques help developers to deal with the size and
complexity ofprograms. Analysts create instructions for the developers about how code
should be written and how pieces of code should fit together to form a program.
Software Engineering is the process of designing, building, testing, and maintaining
software. Thegoal of software engineering is to create software that is reliable, efficient, and
easy to maintain.
System design is a critical component of software engineering and involves making
decisionsabout the architecture, components, modules, interfaces, and data for a software
system.
System Design Strategy refers to the approach that is taken to design a software system.
There are several strategies that can be used to design software systems, including the
following:
1. Top-Down Design: This strategy starts with a high-level view of the system and
graduallybreaks it down into smaller, more manageable components.
2. Bottom-Up Design: This strategy starts with individual components and builds the
system up,piece by piece.
3. Iterative Design: This strategy involves designing and implementing the system in
stages, witheach stage building on the results of the previous stage.
4. Incremental Design: This strategy involves designing and implementing a small
part of thesystem at a time, adding more functionality with each iteration.
5. Agile Design: This strategy involves a flexible, iterative approach to design, where
requirements and design evolve through collaboration between self-organizing and cross-
functional teams.
The design of a system is essentially a blueprint or a plan for a solution for the system.
The design process for software systems often has two levels. At the first level the focus is
on deciding which modules are needed for the system, the specifications of these modules and
how the modules should be interconnected. The design of a system is correct if a system built
precisely according to the design satisfies the requirements of that system. The goal of the
designprocess is not simply to produce a design for the system. Instead, the goal is to find the
best possible design within the limitations imposed by the requirements and the physical and
social environment in which the system will operate.
The choice of system design strategy will depend on the particular requirements of the
software system, the size and complexity of the system, and the development methodology
being used. Awell-designed system can simplify the development process, improve the
quality of the software,and make the software easier to maintain.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

Importance of System Design Strategy:

1. If any pre-existing code needs to be understood, organized, and pieced together.
2. It is common for the project team to have to write some code and produce original
programsthat support the application logic of the system.
There are many strategies or techniques for performing system design. They are:
Bottom-up approach:

The design starts with the lowest level components and subsystems. By using these
components,the next immediate higher-level components and subsystems are created or
composed. The process is continued till all the components and subsystems are composed into
a single component, which is considered as the complete system. The amount of abstraction
grows high as the design moves to more high levels.
By using the basic information existing system, when a new system needs to be created,
thebottom-up strategy suits the purpose.

Bottom-up approach

Advantages of Bottom-up approach:

 The economics can result when general solutions can be reused.
 It can be used to hide the low-level details of implementation and be merged with
the top-down technique.
Disadvantages of Bottom-up approach:
 It is not so closely related to the structure of the problem.
 High-quality bottom-up solutions are very hard to construct.
 It leads to the proliferation of ‘potentially useful’ functions rather than the most
appropriateones.
Top-down approach:
Each system is divided into several subsystems and components. Each of the subsystems
is further divided into a set of subsystems and components. This process of division facilitates
forming a system hierarchy structure. The complete software system is considered a single
entityand in relation to the characteristics, the system is split into sub-systems and
components. The same is done with each of the sub-systems.
This process is continued until the lowest level of the system is reached. The design is
started initially by defining the system as a whole and then keeps on adding definitions of the
subsystemsand components. When all the definitions are combined, it turns out to be a
complete system.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

For the solutions of the software that need to be developed from the ground level, a top-
downdesign best suits the purpose.

Top-down approach

Advantages of Top-down approach:

 The main advantage of the top-down approach is that its strong focus on
requirements helpsto make a design responsive according to its requirements.
Disadvantages of Top-down approach:
 Project and system boundaries tend to be application specification-oriented. Thus,
it is morelikely that the advantages of component reuse will be missed.
 The system is likely to miss, the benefits of a well-structured, simple architecture.
 Hybrid Design:
It is a combination of both top-down and bottom-up design strategies. In this, we can
reuse themodules.
Advantages of using a System Design Strategy:
1. Improved quality: A well-designed system can improve the overall quality of the
software, as itprovides a clear and organized structure for the software.
2. Ease of maintenance: A well-designed system can make it easier to maintain and
update thesoftware, as the design provides a clear and organized structure for the software.
3. Improved efficiency: A well-designed system can make the software more efficient,
as it provides a clear and organized structure for the software that reduces the complexity of
thecode.
4. Better communication: A well-designed system can improve communication
between stakeholders, as it provides a clear and organized structure for the software that
makes iteasier for stakeholders to understand and agree on the design of the software.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

5. Faster development: A well-designed system can speed up the development

process, as it provides a clear and organized structure for the software that makes it easier for
developers tounderstand the requirements and implement the software.
Disadvantages of using a System Design Strategy:
1. Time-consuming: Designing a system can be time-consuming, especially for large
andcomplex systems, as it requires a significant amount of documentation and analysis.
2. Inflexibility: Once a system has been designed, it can be difficult to make changes
to thedesign, as the process is often highly structured and documentation-intensive.

PUBLISH –SUBSCRIBE

The publisher-subscriber (pub-sub) model is a widely used architectural pattern. We can

use it in software development to enable communication between different components in a
system.
In particular, it is often used in distributed systems, where different parts of the system
need tointeract with each other but don’t want to be tightly coupled.
In this tutorial, we’ll explore the pub-sub model, how it works, and some common
usecases for this architectural pattern.

Pub-Sub Model: Overview

The pub-sub model involves publishers and subscribers, making it a messaging pattern.
Specifically, the publishers are responsible for sending messages to the system, while
subscribers are responsible for receiving those messages.
Mainly, the pub-sub model is based on decoupling components in a system, which
means that components can interact without being tightly coupled.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

How the Pub-Sub Model Works

In this section, we’ll discuss how this model works, including sending messages,
checking for subscribers, receiving messages, registering for topics, decoupling publishers
and subscribers, and additional features the message broker implements toenhance
message delivery.

Sending Messages

A publisher sends a message to the message broker with a specific topic, which is a string
thatidentifies the content of the message.

Checking for Subscribers

The message broker receives the message and checks the topic to see if any subscribers
haveexpressed interest in receiving messages on that topic. Furthermore, if subscribers are
interested in the topic, the message broker sends the message to all subscribers who have
registered interest in that topic.
Receiving Messages

Subscribers receive the message from the message broker. Then, it can process the message
as needed. However, the message is discarded if no subscribers are interested in the topic.

Registering for Topics

To receive messages on specific topics, subscribers can register interest in one or more
topics with the message broker. Additionally, this feature enables subscribers to receive messages
ontopics they are interested in.

Decoupling Publishers and Subscribers

Publishers and subscribers do not need to know about each other’s existence since they
interact only through the message broker, which acts as an intermediary.

Additional Features

The message broker can also implement additional features such as filtering messages
basedon content, ensuring message delivery, and providing message ordering guarantees.
These features enhance the reliability and efficiency of message delivery.
By decoupling publishers and subscribers, the pub-sub model allows them to interact
through amessage broker, which helps to reduce tight coupling between components in a
system.
This makes it an ideal messaging pattern for use in distributed systems, where
differentparts of the system must interact without being tightly coupled.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

Advantages and Disadvantages of the Pub-SubModel

The pub-sub model has several benefits. The following table summarizes its main
advantages:

However, the pub-sub model also has some drawbacks. The following table shows its
main drawbacks:

Use Cases for the Pub-Sub Model

In this section, we’ll explore some use cases of this model, including real-time updatesin
online games, smart homes with IoT, and data distribution in data analytics.

Real-time Updates in Online Games

One of the use cases for the pub-sub model is online gaming, where publishers can send real-
time updates on player positions, score changes, and game events to all subscribers.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

Overall, this enhances the gaming experience and ensures all players receive the same

updates simultaneously.

Smart Homes with IoT

The pub-sub model is also used in smart homes to send messages from sensors to actuators.
For example, we can use this model to turn on the lights when someone enters a room.

1.5. Observer

The observer design patterns when designing a system where several objects are interested in
any possible modification to a specific object. In other words, the observer design pattern is
employed when there is a one-to-many relationship between objects, such as when one object
is updated, its dependent objects must be automatically notified.

Real-World Example: If a bus gets delayed, then all the passengers who were supposed to
travel in it get notified about the delay, to minimize inconvenience. Here, the bus agency is the
subject and all the passengers are the observers. All the passengers are dependent on the agency
to provide them with information about
any changes regarding their travel journey. Hence, there is a one-to-many relationship between
the travel agency and the passengers.

Other Examples of observer design patterns:

 Social Media Platforms for example, many users can follow a particular person(subject)
on a social media platform. All the followers will be updated if the subject updates his/her profile.
The users can follow and unfollow the subject anytime they want.
 Newsletters or magazine subscription
 Journalists providing news to the media
 E-commerce websites notify customers of the availability of specific products

Consider the following scenario: There is a new laughter club in town, with a grand opening,
it caught the attention of a lot of people interested in being a member of the club. Thrilled with the
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

overwhelming response, the club owner was a bit worried about the smooth management and
involvement of all the members.

The observer design pattern is the best solution to the owner’s problem. The owner here is the
subject and all the members of the club are observers. The observers have no access to the club’s
information and the upcoming events unless the owner notifies them of it. Also, the members have
the option to opt out of the club whenever they want to. This allows the owner to easily manage and
engage all of the members.

How does Observer Design Patterns work? Structure

 The subject delivers events that are intriguing to the observers. These events occur
due to changes in the state of the subject or the execution of certain behaviors.
Subjects have a registration architecture that enables new observers to join and
existing observers to withdraw from the list.
 Whenever a new event occurs, the subject iterates through the list of observers,
calling the notify method provided in the 'observer' interface.
 The notification interface is declared by the Observer interface. It usually includes an
updating method. The method may include numerous options that allow the subject to
provide event information together with the update.
 Concrete Observers do certain activities in response to alerts sent by the Subject. All
the concrete observer classes should implement the base observer interface, and the
subject interface is coupled only with the base observer interface.
 Sometimes, observers want some additional context in order to properly process any
update notified by the Subject. As a result, the Subject frequently supplies some
contextual information as parameters to the notification function. The subject can pass
itself as an argument, allowing the subject to immediately retrieve any needed data.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

 Declare an Observer interface with an update method at the least.

 Declare the subject interface and a couple of methods for
attaching and detaching observer objects from the list of observers. (Remember that
publishers must only interact with subscribers through the subscriber interface.)
 Create a concrete subject class if needed and add the subscribers’ list to this class.
Since this concrete class extends the Subject interface, it inherits all its properties
including adding and removing observers. Every time something significant happens
inside the subject class, it must inform to all the observers about it.
 In concrete observer classes, add the update notification methods. Some observers
might want basic background information about the occurrence. The notification
method accepts it as an input.

PROXY DESIGN PATTERN

Proxy means ‘in place of’, representing’ or ‘in place of’ or ‘on behalf of’ are literal meanings
of proxy and that directly explains Proxy Design Pattern. Proxies are also called surrogates,
handles, and wrappers. They are closely related in structure, but not purpose, to Adapters and
Decorators.
A real world example can be a cheque or credit card is a proxy for what is in our bank account.
It can be used in place of cash, and provides a means of accessing that cash when required. And
that’s exactly what the Proxy pattern does – “Controls and manage access to the object they are
protecting“.
BEHAVIOR
As in the decorator pattern, proxies can be chained together. The client, and each proxy,
believes it is delegating messages to the real server:

When to use this pattern?

Proxy pattern is used when we need to create a wrapper to cover the main object’s
complexity from the client.
TYPES OF PROXIES

Remoteproxy:
They are responsible for representing the object located remotely. Talking to the real object
might involve marshalling and unmarshalling of data and talking to the remote object. All that logic
is encapsulated in these proxies and the client application need not worry about them.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

Virtual proxy:
These proxies will provide some default and instant results if the real object is supposed to
take some time to produce results. These proxies initiate the operation on real objects and provide a
default result to the application. Once the real object is done, these proxies push the actual data to
the client where it has provided dummy data earlier.
Protection proxy:
If an application does not have access to some resource then such proxies will talk to the objects
in applications that have access to that resource and then get the result back.
Smart Proxy:
A smart proxy provides additional layer of security by interposing specific actions when the
object is accessed. An example can be to check if the real object is locked before it is accessed to
ensure that no other object can change it.
Some Examples
A very simple real life scenario is our college internet, which restricts few site access. The
proxy first checks the host you are connecting to, if it is not part of restricted site list, then it
connects to the real internet. This example is based on Protection proxies.
Interface of Internet

package [Link]; public

interface Internet

public void connectTo(String serverhost) throws Exception;

Benefits:
 One of the advantages of Proxy pattern is security.
 This pattern avoids duplication of objects which might be huge size and memory intensive.
This in turn increases the performance of the application.
 The remote proxy also ensures about security by installing the local code proxy (stub) in
the client machine and then accessing the server with help of the remote code.
Drawbacks/Consequences:
This pattern introduces another layer of abstraction which sometimes may be an issue if the
RealSubject code is accessed by some of the clients directly and some of them might access the
Proxy classes. This might cause disparate behaviour.

FAÇADE:

The facade pattern (also spelled façade) is a software-design pattern commonly used in object-
oriented programming. Analogous to a facade in architecture, a facade is an object that serves as a
front-facing interface masking more complex underlying or structural code.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

Facade is a part of the Gang of Four design patterns and it is categorized under Structural
design patterns. Before we dig into the details of it, let us discuss some examples which will be
solved by this particular Pattern. So, As the name suggests, it means the face of the building.

The people walking past the road can only see the glass face of the building. They do not know
anything about it, the wiring, the pipes, and other complexities. It hides all the complexities of the
building and displays a friendly face.

More examples
In Java, the interface JDBC can be called a facade because we as users or clients create
connections using the “[Link]” interface, the implementation of which we are not
concerned about.
The implementation is left to the vendor of the driver. Another good example can be the startup
of a computer. When a computer starts up, it involves the work of CPU, memory, hard drive, etc.
To make it easy to use for users, we can add a facade that wraps the complexity of the task,
and provide one simple interface instead. The same goes for the Facade Design Pattern. It hides
the complexities of the system and provides an interface to the client from where the client can access
the system.

FACADE DESIGN PATTERN DIAGRAM

Now Let’s try and understand the facade pattern better using a simple example. Let’s consider
a hotel. This hotel has a hotel keeper.
There are a lot of restaurants inside the hotel e.g. Veg restaurants, Non-Veg restaurants, and
Veg/Non Both restaurants. You, as a client want access to different menus of different restaurants.
You do not know what are the different menus they have. You just have access to a hotel keeper who
knows his hotel well. Whichever menu you want, you tell the hotel keeper and he takes it out of the
respective restaurants and hands it over to you. Here, the hotel keeper acts as the facade, as he
hides the complexities of the system hotel. Let’s see how it works:

1. Facade is a structural design pattern with the intent to provide a simplified (but limited)
interface to a complex system of classes, library or framework.

2. A Facade class can often be transformed into a Singleton since a single facade object is
sufficient in most cases.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

3. Facade routinely wraps multiple objects.

4. The Facade class will not encapsulate subclasses but will provide a simple
interface to their functions.

5. Classes in the subsystem will still be available to the client. However, Facade will
decouple client and subsystems so that they can change independently.

6. We can combine different features by writing different Facade classes for

different clients.

7. Facade can be recognized in a class that has a simple interface, but delegates most of
the work to other classes.

8. Usually, facades manage the full life cycle of objects they use.

9. Client is shielded from the unwanted complexities of the subsystems and gets only to
a fraction of a subsystem’s capabilities.

10. Abstract Factory can serve as an alternative to Facade when you only want to hide the
way the subsystem objects are created from the client code.

Usage:

1. Use the Facade pattern when you need to have a limited but straightforward
interface to a complex subsystem.

2. Use the Facade when you want to structure a subsystem into layers.

Related Patterns:

1. Combined with Abstract Factory or used as an alternative to it.

2. Often confused with Adapter and mediator patterns.

Some use cases in Enterprise Applications:

1. Decoupling Application Code From the Library.

2. Reusing Legacy Code in New Application.

 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

3. Fixing Interface Segregation Principle Violation.

1.6. ARCHITECTURAL STYLES

Introduction:
The software needs the architectural design to represents the design of software. IEEE
defines architectural design as “the process of defining a collection of hardware and software
components and their interfaces to establish the framework for the development of a
computersystem.” The software that is built for computer-based systems can exhibit one of these
many architectural styles.
Each style will describe a system category that consists of :

 A set of components(eg: a database, computational modules) that will perform a

functionrequired by the system.
 The set of connectors will help in coordination, communication, and cooperation
betweenthe components.
 Conditions that how components can be integrated to form the system.
 Semantic models that help the designer to understand the overall properties of the
[Link] use of architectural styles is to establish a structure for all the components of the
system.
Taxonomy of Architectural styles:
1] Data centered architectures:

 A data store will reside at the center of this architecture and is accessed
frequently by theother components that update, add, delete or modify the data present within the
store.
 The figure illustrates a typical data centered style. The client software access a central
repository. Variation of this approach are used to transform the repository into a blackboardwhen
data related to client or data of interest for the client change the notifications to client software.
 This data-centered architecture will promote integrability. This means that the existing
components can be changed and new client components can be added to the architecturewithout
the permission or concern of other clients.
 Data can be passed among clients using blackboard mechanism.
Advantage of Data centered architecture
 Repository of data is independent of clients
 Client work independent of each other
 It may be simple to add additional clients.
 Modification can be very easy
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

Data centered architecture

2] DATA FLOW ARCHITECTURES:

 This kind of architecture is used when input data is transformed into output data
through aseries of computational manipulative components.
 The figure represents pipe-and-filter architecture since it uses both pipe and filter and it
hasa set of components called filters connected by lines.
 Pipes are used to transmitting data from one component to the next.
 Each filter will work independently and is designed to take data input of a certain form
andproduces data output to the next filter of a specified form. The filters don’t require any
knowledge of the working of neighboring filters.
 If the data flow degenerates into a single line of transforms, then it is termed as batch
sequential. This structure accepts the batch of data and then applies a series of sequential
components to transform it.
Advantages of Data Flow architecture
 It encourages upkeep, repurposing, and modification.
 With this design, concurrent execution is supported.
The disadvantage of Data Flow architecture
 It frequently degenerates to batch sequential system
 Data flow architecture does not allow applications that require greater user
engagement.
 It is not easy to coordinate two different but related streams
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

Data Flow architecture

3] Call and Return architectures: It is used to create a program that is easy to scale and
modify. Many sub-styles exist within this category. Two of them are explained below.

 Remote procedure call architecture: This components is used to present in a main

program or sub program architecture distributed among multiple computers on a network.
 Main program or Subprogram architectures: The main program structure
decomposes
into number of subprograms or function into a control hierarchy. Main program contains
number of subprograms that can invoke other components.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

4] Object Oriented architecture: The components of a system encapsulate data and the
operations that must be applied to manipulate the data. The coordination and communication
between the components are established via the message passing.
Characteristics of Object Oriented architecture
 Object protect the system’s integrity.
 An object is unaware of the depiction of other items.
Advantage of Object Oriented architecture
 It enables the designer to separate a challenge into a collection of autonomous objects.
 Other objects are aware of the implementation details of the object, allowing changes
to bemade without having an impact on other objects.
5] Layered architecture:

 A number of different layers are defined with each layer performing a well-defined set
of operations. Each layer will do some operations that becomes closer to machine instructionset
progressively.
 At the outer layer, components will receive the user interface operations and at the
innerlayers, components will perform the operating system interfacing(communication and
coordination with OS)
 Intermediate layers to utility services and application software functions.
 One common example of this architectural style is OSI-ISO (Open Systems
Interconnection-International Organisation for Standardisation) communication system.

Layered architecture:

The most common architecture pattern is the layered architecture pattern, otherwise
known as the n-tier architecture pattern. This pattern is the de facto standard for most Java EE
applications and therefore is widely known by mostarchitects, designers, and developers.
The layered architecture pattern closely matches the traditional IT communication and
organizational structures found in most companies, making it a natural choice for most business
application development efforts.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

Layered architectures are widely used in software development and are considered to be the most
prevalent and commonly utilized architectural framework.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

It is an architectural pattern made up of numerous independent horizontal layers that work together to
form a single software unit. This pattern is also known as n-tier architecture.

A layer is a logical division of parts or programme code. This architecture typically places related or
comparable components on the same tiers. Every layer is unique and affects a different aspect of the entire
system.

Pattern Description
 Within the application, each layer of the layered architecture pattern is responsible for a particular
task.
 For instance, the user interface and browser communication logic would be
 handled by the presentation layer, whilst the business layer would be in charge of carrying out the
specific business rules related to the request.
 Each layer of the architecture creates an abstraction around the work required tocomplete a specific
business requirement.
 For instance, the presentation layer just needs to display customer data on a screen in a specific
way; it is not required to understand or worry about how to obtain customer
 data.
 The business layer only needs to obtain the data from the persistence layer, apply business logic to
the data (e.g., calculate values or aggregate data), and then pass that information up to the
presentation layer.
 In a similar manner, the business layer need not worry about how to format customer data for
display on a screen or even where the customer data is coming from
 Separating concerns among components is one of the layered architecture
 pattern's strong points. Components inside that layer deal with only logic specific to a certain layer.
 For instance, the presentation layer's components only deal with presentation logic, whereas the
business layer's components only deal with business logic. Due to the clearly defined component
interfaces and constrained component scope, this type of component classification makes it simple
to incorporate efficient roles and responsibility models into your architecture..
 CCS356−OBVJECT ORIENTED SOFTWARE ENGINEERING

CLIENT-SERVER MODEL
The 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 tothe server through the internet, the server accepts
the requested process and deliver the data packets requested back to the client.

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
howthe 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 aparticular 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
servessomething. Similarly in this digital world a Server is a remote computer which
provides information (data) or access to particular services.
So, its basically the Client requesting something and the Server serving it as long as itspresent in
the database.

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
 CCS356−OBVJECT ORIENTED SOFTWARE ENGINEERING
thenrequests 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
thehelp of DOM (Document Object Model) interpreter, CSS interpreter and JS
Engine collectively known as the JIT or (Just in Time) Compilers.

Advantages of Client-Server model:

 Centralized system with all data in a single place.
 Cost efficient requires less maintenance cost and Data recovery is possible.
 The capacity of the Client and Servers can be changed separately.
Disadvantages of Client-Server model:
 Clients are prone to viruses, Trojans and worms if present in the Server or uploaded
into theServer.
 Server are prone to Denial of Service (DOS) attacks.
 Data packets may be spoofed or modified during transmission.
 Phishing or capturing login credentials or other useful information of the user are
commonand MITM(Man in the Middle) attacks are common.
 CCS356−OBVJECT ORIENTED SOFTWARE ENGINEERING
PIPE AND FILTER ARCHITECTURES

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:

Definition
Pipe and Filter is another architectural pattern, which has independent entities called filters
(components) which perform transformations on data and process the input they receive, and pipes,
which serve as connectors for the stream of data being transformed, each connected to the next
component in the pipeline.

Many systems are required to transform streams of discrete data items, from input to output.
Many types of transformations occur repeatedly in practice, and so it isdesirable to create these as
independent, reusable parts, Filters. (Len Bass, 2012)
Description of the Pattern
The pattern of interaction in the pipe-and-filter pattern is characterized by successive
transformations of streams of data. As you can see in the diagram, the data flows in one
direction. It starts at a data source, arrives at a filter’s input port(s) whereprocessing is done at the
component, and then, is passed via its output port(s) through a pipe to the next filter, and then
eventually ends at the data target.

A single filter can consume data from, or produce data to, one or more ports. They can also
run concurrently and are not dependent. The output of one filter is the input of another, hence, the
order is very important.

A pipe has a single source for its input and a single target for its output. Itpreserves
the sequence of data items, and it does not alter the data passing through.
 CCS356−OBVJECT ORIENTED SOFTWARE ENGINEERING

Advantages of selecting the pipe and filter architecture are as follows:

· Ensures loose and flexible coupling of components, filters.
· Loose coupling allows filters to be changed without modifications to other filters.

· Conductive to parallel processing.

· Filters can be treated as black boxes. Users of the system don’t need to know the
logic behind the working of each filter.

· Re-usability. Each filter can be called and used over and over again. However, there
are a few drawbacks to this architecture and are discussed below:

· Addition of a large number of independent filters may reduce performance due to

excessive computational overheads.
· Not a good choice for an interactive system.
· Pipe-and-fitter systems may not be appropriate for long-running computations.

Applications of the Pattern

In software engineering, a pipeline consists of a chain of processing elements (processes,

threads, functions, etc.), arranged so that the output of each element is the input of the next. (Wiki,
n.d.).
The architectural pattern is very popular and used in many systems, such as the text- based
utilities in the UNIX operating system. Whenever different data sets need to be manipulated in
different ways, you should consider using the pipe and filter architecture. More specific
implementations are discussed below:
1. Compilers:
A compiler performs language transformation: Input is in language A and outputis in language
B. In order to do that the input goes through various stages inside the compiler — these stages form
the pipeline. The most commonly used division consistsof 3 stages: front-end, middle-end, and back-
end.
The front-end is responsible for parsing the input language and performing syntax and semantic
and then transforms it into an intermediate language. The middle- end takes the intermediate
representation and usually performs several optimization steps on it, the resulting transformed
program in is passed to the back-end which transforms it into language B.
Each level consists of several steps as well, and everything together forms thepipeline of
the compiler.
 CCS356−OBVJECT ORIENTED SOFTWARE ENGINEERING

USER INTERFACE DESIGN – SOFTWARE ENGINEERING

The user interface is the front-end application view to which the user interacts touse the
software. The software becomes more popular if its user interface is:
1. Attractive
2. Simple to use
3. Responsive in a short time
4. Clear to understand
5. Consistent on all interface screensTypes of User Interface
1. Command Line Interface: The Command Line Interface provides a command prompt,
where the user types the command and feeds it to the system. The user needs to remember the syntax
of the command and its use.
2. Graphical User Interface: Graphical User Interface provides a simple interactive
interface to interact with the system. GUI can be a combination of both hardware and software.
Using GUI, the user interprets the software.
User Interface Design Process
 CCS356−OBVJECT ORIENTED SOFTWARE ENGINEERING

User Interface Design Process

The analysis and design process of a user interface is iterative and can be represented by a
spiral model. The analysis and design process of user interface consists of four framework activities.
1. User, Task, Environmental Analysis, and Modeling
Initially, the focus is based on the profile of users who will interact with the system, i.e.,
understanding, skill and knowledge, type of user, etc., based on the user’s profile users are made
into categories. From each category requirements are gathered. Based on the requirement’s
developer understand how to develop the interface. Once all the requirements are gathered a detailed
analysis is conducted. In the analysis part, the tasks that the user performs to establish the goals of
the system are identified, described and elaborated. The analysis of the user environment focuses
on the physical work environment. Among the questions to be asked are:
1. Where will the interface be located physically?
2. Will the user be sitting, standing, or performing other tasks unrelated to theinterface?
3. Does the interface hardware accommodate space, light, or noise constraints?
4. Are there special human factors considerations driven by environmental factors?
2. Interface Design
The goal of this phase is to define the set of interface objects and actions i.e., control
mechanisms that enable the user to perform desired tasks. Indicate how these control mechanisms
affect the system. Specify the action sequence of tasks and subtasks, also called a user scenario.
Indicate the state of the system when the user performs a particular task. Always follow the three
golden rules stated by Theo Mandel. Design issues such as response time, command and action
structure, error handling, and help facilities are considered as the design model is refined. This phase
 CCS356−OBVJECT ORIENTED SOFTWARE ENGINEERING
serves as the foundation for the implementation phase.

Interface Construction and Implementation

The implementation activity begins with the creation of a prototype (model) that enables usage
scenarios to be evaluated. As iterative design process continues a User Interface toolkit that allows
the creation of windows, menus, device interaction,error messages, commands, and many other
elements of an interactive environment can be used for completing the construction of an interface.
4. Interface Validation
This phase focuses on testing the interface. The interface should be in such a way that it
should be able to perform tasks correctly, and it should be able to handle a variety of tasks. It should
achieve all the user’s requirements. It should be easy to use and easy to learn. Users should accept
the interface as a useful one in their work. User Interface Design Golden Rules
The following are the golden rules stated by Theo Mandel that must be followed during the
design of the interface. Place the user in control:
1. Define the interaction modes in such a way that does not force the user into
unnecessary or undesired actions: The user should be able to easily enter and exit the mode with
little or no effort.
2. Provide for flexible interaction: Different people will use different interaction
mechanisms, some might use keyboard commands, some might use mouse, some
might use touch screen, etc., Hence all interaction mechanisms should be provided.
3. Allow user interaction to be interruptible and undoable: When a user is doinga
sequence of actions the user must be able to interrupt the sequence to do some other work without
losing the work that had been done. The user should also be able to do undo operation.
4. Streamline interaction as skill level advances and allow the interaction to be
customized: Advanced or highly skilled user should be provided a chance tocustomize the interface
as user wants which allows different interaction mechanisms so that user doesn’t feel bored while
using the same interaction mechanism.
5. Hide technical internals from casual users: The user should not be aware of the internal
technical details of the system. He should interact with the interface justto do his work.
6. Design for direct interaction with objects that appear on-screen: The user should be
able to use the objects and manipulate the objects that are present onthe screen to perform a
necessary task. By this, the user feels easy to control over the screen.