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
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.
Modules: These are components that handle one specific task in a system. A
combination of the modules makes up the system.
Components: This provides a particular function or group of related functions. They are made
up of modules.
Interfaces: This is the shared boundary across which the components of a system
exchange
information and relate.
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.
2.Specification of the data, and the formats of the data coming into and going out of
the system.
3. 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

 CCS356−OBJECT ORIENTED 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

7. Functional Abstraction
8. 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.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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.

oach 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

oIt encourages the creation of commonly used routines to be placed in
the library and used by other programs.
oIt 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
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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
oMorelinkage 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.
4. 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.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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
managed easily.
be
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.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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

 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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.
Coupling Cohesion shows the
shows the relationship within the module.
relationships
between modules.
Coupling Cohesionshows module's the
relative functional strength.
s
hows

the relative
independence
between

the modules.

While creating, While creating you should

you should aim for aim for high cohesion, i.e., a
low coupling, i.e., cohesive component/ module
dependency among focuses on a single function (i.e.,
modules should be single-mindedness) with little
less. interaction with other modules of
the system.
In coupling, In cohesion, the module
modules are linked focuses on a single thing.
to the other
modules.
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.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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 are addition Module,
modules subtraction division Module, multiplication Module. Each
one of you pick up one module for development purpose.
Module,

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

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
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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
implementations.Importance 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
interface.This 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
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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

MVC in Real World

application Web applications

 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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

ASP.NET MVC framework offers and MVC pattern as one of the development model.

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

An example of a controller action in ASP.NET

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

 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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
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.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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 time.This 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 execute()
then does the work when the
methodis called. An invoker object knows how to execute a command, and
in command
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, 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.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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.
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:
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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:
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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

Observer design pattern falls under the category of behavioral design

pattern Observer Pattern maintains a one-to-many relationship among objects,
ensuring that whe state of one object is changed, all of its dependent
objects are simultaneously inf and updated. This design pattern is also
referred to as Dependents.

A subject and observer (many) exist in a one-to-many relationship. Here

the observ not have any access to data, so they are dependent on the subject to
feed them with inform

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
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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
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
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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
 S
declared by the Observer interface. It
ometimes, observers want some additional context in order to properly process any update notifiedusually
includes
by the Subject. As a result, the Subject frequently an updating
supplies method. The
some contextual method may
information as
include numerous options that allow
parameters to the notification function. The subject can pass itself as an argument, allowingthe subject
the
subject to immediately retrieve any needed data. to provide event information together with the
update.
 Concrete Observers do certain I
implementation activities in response to alerts sent by the
Subject. All the concrete observer classes
1. Declare an Observer interface with an update should method
implementatthe thebase observer interface,
least.
2. Declare the subject interface and the
and subject interface
a is coupled only with
couple method
for of the base observer interface.
attaching and detaching observer objects from the list of observers. (Remember s
that publishers
must only interact with subscribers through the subscriber interface.)
3. 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.
4. 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,
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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.
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
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

package com.saket.demo.proxy; 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.

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 “java.sql.Connection” 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
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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.

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.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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.

3. Fixing Interface Segregation Principle Violation.

 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

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
system.The 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

3Call 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

4Object 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.
Thebusiness 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.
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

 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. It also makes it simple to
develop, test, govern, and maintain applications using this architecture
pattern.

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).
 CCS356−OBJECT ORIENTED SOFTWARE ENGINEERING

 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
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.
 CCS356−OBVJECT ORIENTED SOFTWARE ENGINEERING

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

 CCS356−OBVJECT ORIENTED SOFTWARE ENGINEERING

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.

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.

 CCS356−OBVJECT ORIENTED SOFTWARE ENGINEERING

· 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
6.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.
7.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.