UNIT 3

SOFTWARE DESIGN
 Model-View-Controller
• The Model-View-Controller (MVC) framework is
an architectural/design pattern that separates
an application into three main logical
components Model, View, and Controller.
• Each architectural component is built to handle
specific development aspects of an application.
• It isolates the business logic and presentation
layer from each other. It was traditionally used
for desktop graphical user interfaces (GUIs).
• Nowadays, MVC is one of the most frequently used
industry-standard web development frameworks
to create scalable and extensible projects.
• It is also used for designing mobile apps.
• MVC was created by Trygve Reenskaug. The main
goal of this design pattern was to solve the
problem of users controlling a large and complex
data set by splitting a large application into specific
sections that all have their own purpose.
 Features of MVC
• It provides a clear separation of business logic,
Ul logic, and input logic.
• It offers full control over your HTML and URLs
which makes it easy to design web application
architecture.
• It is a powerful URL-mapping component using
which we can build applications that have
comprehensible and searchable URLs.
• It supports Test Driven Development (TDD).
 Components of MVC
• The MVC framework includes the following 3
components:
• Controller
• Model
• View
 Controller
• The controller is the component that enables
the interconnection between the views and
the model so it acts as an intermediary.
• The controller is the component that enables
the interconnection between the views and
the model so it acts as an intermediary.
• The controller is the component that enables
the interconnection between the views and
the model so it acts as an intermediary.
 View
• The View component is used for all the UI
logic of the application. It generates a user
interface for the user.
• Views are created by the data which is
collected by the model component but these
data aren’t taken directly but through the
controller. It only interacts with the Controller.
 Model
• The Model component corresponds to all the data-
related logic that the user works with. This can
represent either the data that is being transferred
between the View and Controller components or
any other business logic-related data.
• It can add or retrieve data from the database. It
responds to the controller’s request because the
controller can’t interact with the database by itself.
• The model interacts with the database and gives the
required data back to the controller.
 Working of the MVC framework with an
example:
• Let’s imagine an end-user sends a request to a
server to get a list of students studying in a
class. The server would then send that request
to that particular controller that handles
students. That controller would then request
the model that handles students to return a
list of all students studying in a class.
The flow of Data in MVC Components
• The model would query the database for the
list of all students and then return that list back
to the controller. If the response back from the
model was successful, then the controller
would ask the view associated with students to
return a presentation of the list of students.
This view would take the list of students from
the controller and render the list into HTML
that can be used by the browser.
• The controller would then take that presentation and
returns it back to the user. Thus ending the request. If
earlier the model returned an error, the controller
would handle that error by asking the view that handles
errors to render a presentation for that particular error.
That error presentation would then be returned to the
user instead of the student list presentation.
• The view handles all of the presentations and the
controller just tells the model and view of what to do.
This is the basic architecture and working of the MVC
framework.
The MVC architectural pattern allows us
to adhere to the following design
principles:
• Divide and conquer.
• Increase cohesion.
• Reduce coupling.
• Increase reuse.
• Design for flexibility.
 Advantages of MVC:
• Codes are easy to maintain and they can be extended
easily.
• The MVC model component can be tested separately.
• The components of MVC can be developed
simultaneously.
• It reduces complexity by dividing an application into
three units. Model, view, and controller.
• It works well for Web apps that are supported by large
teams of web designers and developers.
• Search Engine Optimization (SEO) Friendly.
 Disadvantages of MVC:
• It is difficult to read, change, test, and reuse this
model.
• It is not suitable for building small applications.
• The inefficiency of data access in view.
• The framework navigation can be complex as it
introduces new layers of abstraction which
requires users to adapt to the decomposition
criteria of MVC.
• Increased complexity and Inefficiency of data
 Publisher-Subscriber Pattern
• Consider a scenario of synchronous message passing. You
have two components in your system that communicate
with each other. LeLet’ss call the sender and receiver. The
receiver asks for a service from the sender and the sender
serves the request and waits for an acknowledgment from
the receiver.
• There is another receiver that requests a service from the
sender. The sender is blocked since it hasn’t yet received
any acknowledgment from the first receiver. The sender
isn’t able to serve the second receiver which can create
problems. To solve this drawback, the Pub-Sub model was
introduced.
• Publisher Subscriber basically known as Pub-Sub is an asynchronous
message-passing system that solves the drawback above. The sender
is called the publisher whereas the receiver is called the subscriber.
• The main advantage of pub-sub is that it decouples the subsystem
which means all the components can work independently. This is very
important when it comes to writing APIs or working with databases.
• The publisher never sends a direct message to the subscribers, it is
sent to a broker and then the subscribers will get it. Sending a
message to the broker is called publishing whereas listening to
incoming messages is called subscribing. In simple terms, a subscriber
subscribes to a topic(which is like a message broker) and the
publisher pushes messages to the topic and then the topic will push
messages to the subscribers.
 What are the Different Components of
Pub/Sub Architecture?
1. Topic: It is basically a place where messages are sent.
2. Subscription: It is basically a service provided by the publisher. It
represents a stream of messages that is to be sent to the
subscriber-only.
3. Publisher: An entity that sends messages to topics.
4. Subscriber: An entity that receives messages from topics based
on Subscription. We can understand it by taking the analogy of
ott platforms. Ott platforms allow you to stream the services
only if you have a subscription. Similarly, a subscription here
works.
5. Acknowledgment: It is a message that subscribers send after
they receive a message from the topic
• There are two delivery methods: push and
pull. A subscriber receives the message by
either pushing the message to the subscriber
or by the subscriber pulling the message from
the topic.
• The below diagram represents the
architecture of pub-sub.
 Adapter
• This pattern is easy to understand as the real world is full of
adapters. For example consider a USB to Ethernet adapter.
• We need this when we have an Ethernet interface on one
end and USB on the other. Since they are incompatible with
each other. we use an adapter that converts one to other.
• This example is pretty analogous to Object Oriented
Adapters. In design, adapters are used when we have a
class (Client) expecting some type of object and we have an
object (Adaptee) offering the same features but exposing a
different interface.
 To use an adapter:
1. The client makes a request to the adapter by calling
a method on it using the target interface.
2. The adapter translates that request on the adaptee
using the adaptee interface.
3. Client receive the results of the call and is unaware
of adapter’s presence
4. Definition: The adapter pattern convert the interface
of a class into another interface clients expect.
Adapter lets classes work together that couldn’t
otherwise because of incompatible interfaces.
 Command
• Definition: The command pattern encapsulates a request
as an object, thereby letting us parameterize other objects
with different requests, queue or log requests, and
support undoable operations.
• In analogy to our problem above remote control is the
client and stereo, lights, etc. are the receivers.
• In a command pattern, there is a Command object that
encapsulates a request by binding together a set of
actions on a specific receiver. It does so by exposing just
one method execute() that causes some actions to be
invoked on the receiver.
• Parameterizing other objects with different requests in
our analogy means that the button used to turn on the
lights can later be used to turn on stereo or maybe open
the garage door.
• queue or log requests, and support undoable operations
means that Command’s Execute operation can store state
for reversing its effects in the Command itself
• The Command may have an added unExecute operation
that reverses the effects of a previous call to execute.It
may also support logging changes so that they can be
reapplied in case of a system crash.
 Advantages
• Makes our code extensible as we can add new
commands without changing existing code.
• Reduces coupling between the invoker and
receiver of a command.
Disadvantages:
• Increase in the number of classes for each
individual command.
 Strategy pattern
• Strategy pattern is a behavioral design pattern that
allows the behavior of an object to be selected at
runtime.
• It is one of the Gang of Four (GoF) design patterns, which
are widely used in object-oriented programming.
• The Strategy pattern is based on the idea of
encapsulating a family of algorithms into separate classes
that implement a common interface.
• The pattern consists of three main components: the
Context, the Strategy, and the Concrete Strategy.
• The Context is the class that contains the object
whose behavior needs to be changed dynamically.
• The Strategy is the interface or abstract class that
defines the common methods for all the algorithms
that can be used by the Context object.
• The Concrete Strategy is the class that implements
the Strategy interface and provides the actual
implementation of the algorithm.
 Advantages
• A family of algorithms can be defined as a class
hierarchy and can be used interchangeably to alter
application behavior without changing its architecture.
• By encapsulating the algorithm separately, new
algorithms complying with the same interface can be
easily introduced.
• The application can switch strategies at run-time.
• Strategy enables the clients to choose the required
algorithm, without using a “switch” statement or a
series of “if-else” statements.
• Data structures used for implementing the algorithm are
completely encapsulated in Strategy classes. Therefore, the
implementation of an algorithm can be changed without
affecting the Context class.
Disadvantages:
• The application must be aware of all the strategies to select
the right one for the right situation.
• Context and the Strategy classes normally communicate
through the interface specified by the abstract Strategy base
class. Strategy base class must expose interface for all the
required behaviours, which some concrete Strategy classes
might not implement.
• In most cases, the application configures the
Context with the required Strategy object.
Therefore, the application needs to create and
maintain two objects in place of one.
 Observer pattern
• To understand observer pattern, first you need to
understand the subject and observer objects. The
relation between subject and observer can easily be
understood as an analogy to magazine subscription.
• A magazine publisher(subject) is in the business and
publishes magazines (data).
• If you(user of data/observer) are interested in the
magazine you subscribe(register), and if a new edition is
published it gets delivered to you.
• If you unsubscribe(unregister) you stop getting new
editions.
• Publisher doesn’t know who you are and how
you use the magazine, it just delivers it to you
because you are a subscriber(loose coupling).
• Definition: The Observer Pattern defines a one
to many dependency between objects so that
one object changes state, all of its dependents
are notified and updated automatically.
 Advantages
• Provides a loosely coupled design between objects
that interact. Loosely coupled objects are flexible
with changing requirements. Here loose coupling
means that the interacting objects should have less
information about each other. Observer pattern
provides this loose coupling as:
• Subject only knows that observer implement
Observer interface.Nothing more.
• There is no need to modify Subject to add or
remove observers.
• We can reuse subject and observer classes
independently of each other.

Disadvantages:
• Memory leaks caused by Lapsed listener
problem because of explicit register and
unregistering of observers.
 Proxy
• 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“.
 Benefits
• Proxy pattern is security.
• avoids duplication of objects which might be
huge size and memory intensive.
• 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.
 Facade
• Facade Method Design Pattern is a part of the Gang of
Four design patterns and it is categorized under Structural
design patterns.
• Before we dive deep into the details of it, imagine a
building, the facade is the outer wall that people see, but
behind it is a complex network of wires, pipes, and other
systems that make the building function.
• The facade pattern is like that outer wall. It hides the
complexity of the underlying system and provides a simple
interface that clients can use to interact with the system.
 Advantages of Facade Method Design
Pattern
• Simplified Interface
• Reduced Coupling
• Encapsulation
• Improved Maintainability
 Disadvantages of Facade Method Design
Pattern
• Increased Complexity
• Reduced Flexibility
• Overengineering
• Potential Performance Overhead
 ARCHITECTURAL STYLES
• The software that is built for computer-based systems also
exhibits one of manyarchitecturalstyles. Each style describes a
system category that encompasses
• A set of components (e.g., a database, computational modules)
that perform a function required by a system;
• A set of connectors that enable “communication, coordination
and cooperation” amongcomponents;
• Constraints that define how components can be integrated to
form the system;
• Semantic models that enable a designer to understand the
overall properties of a system byanalyzing the known
properties of its parts.
• An architectural style is a transformation that is imposed on the design
of an entire system. Theintent is to establish a structure for all
components of the system.
A pattern differs from a style in a number of fundamental ways:
• The scope of a pattern is less broad, focusing on one aspect of the
architecture rather than the architecture in its entirety;
• A pattern imposes a rule on the architecture, describing how the
software will handle some aspect ofits functionality at the
infrastructure level (e.g., concurrency);
• Architectural patterns tend to address specific behavioral issues within
the context of the architecture(e.g., how real-time applications handle
synchronization or interrupts). Patterns can be used in conjunction
with an architectural style to shape theoverall structure of a system.
 1) Layered architectures
• A number of different layers are defined, each
accomplishing operations that progressivelybecome
closer to the machine instruction set.
• At the outerlayer, components service user
interface operations.
• At the inner layer, components perform operating
system interfacing.
• Intermediate layers provide utility services and
application software functions.
• 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 to the server through
the internet, the server accepts the requested process
and deliver the data packets requested back to the
client. Clients do not share any of their resources.
• Examples of ClientServer Model are Email, World Wide
Web, etc.
 Tiered Architecture
• In Tier Architecture, there is another layer between the
client and the server. The client does not directly
communicate with the server.
• Instead, it interacts with an application server which
further communicates with the database system and then
the query processing and transaction management takes
place.
• This intermediate layer acts as a medium for the exchange
of partially processed data between the server and the
client. This type of architecture is used in the case of large
web applications.
 Pipe and Filter Software Architecture
• This software architecture pattern decomposes a task that
performs complex processing into a series of separate
elements that can be reused, where processing is executed
sequentially step by step.
• There are four main components:
• Data Source: The original, unprocessed data
• Data Sink: The final processed data
• Filter: Components that perform processing
• Pipe: Components that pass data from a data source to a
filter, or from a filter to another filter, or from a filter to a
data sink
 Advantages
• Suitable for processing that requires clear, systematic steps
in order to transform successive pieces of data, because of
the intuitive flow of processing
• Each filter can be modified easily — as long as the data
input and data output remain the same
• Filters are reusable, old filters can be replaced by new
ones, or new filters can be inserted easily into the flow of
processing — as long as the data input and output
between filters are compatible
• Each component is implemented as a separate, distinct
task, hence having a natural separation of concerns
 Disadvantages
• Inefficient and inconvenient to pass around the
full set of data throughout the entire pipe and
filter system, because not every component will
require the full set of data
• Reliability may be an issue if data is lost on the
way between components.
• Having too many filters can slow down your
application, introducing bottlenecks or deadlocks
if one particular filter processes slowly or fails
 USER INTERFACE DESIGN
• User interface design creates an effective
communication medium between a human
and a computer.
GOLDEN RULES:
• Place the user in control.
• Reduce the user’s memory load.
• Make the interface consistent.
 Place the User in Control
Design principles that allow the user to maintain control are :
• Use modes judiciously (modeless)
• Allow users to use either the keyboard or mouse (flexible)
• Allow users to change focus (interruptible)
• Display descriptive messages and text(Helpful)
• Provide immediate and reversible actions, and feedback (forgiving)
• Provide meaningful paths and exits (navigable)
• Accommodate users with different skill levels (accessible)
• Make the user interface transparent (facilitative)
• Allow users to customize the interface (preferences)
• Allow users to directly manipulate interface objects (interactive)
 Reduce the User’s Memory Load:
• Relieve short-term memory (remember)
• Rely on recognition, not recall (recognition)
• Provide visual cues (inform)
• Provide defaults, undo, and redo (forgiving)
• Provide interface shortcuts (frequency)
• Promote an object-action syntax (intuitive)
• Use real-world metaphors (transfer)
• User progressive disclosure (context)
• Promote visual clarity (organize)
 Make the Interface Consistent
The interface should present and acquire
information in a consistent fashion. This implies that
• All visual information is organized according to
design rules that are maintained throughoutall
screen displays
• Input mechanisms are constrained to a limited set
that is used consistently throughout the application.
• Mechanisms for navigating from task to task are
consistently defined and implemented.
Set of design principles that help make the
interface consistent are:
• Sustain the context of users’ tasks (continuity)
• Maintain consistency within and across
products (experience)
• Keep interaction results the same
(expectations)
• Provide aesthetic appeal and integrity
(attitude)
• Encourage exploration (predictable)
USER INTERFACE ANALYSIS AND DESIGN
1) Interface Analysis and Design Models:
• User model - Establishes the profile of the end-users of the system Based on
age, gender, physical abilities, education, cultural or ethnic background,
motivation, goals, and personality. A human engineer or the software
engineer establishes a user model
• Design model- The software engineer creates a design model. Derived from
the analysis model of the requirements. Incorporates data, architectural,
interface, and procedural representationsof the software.
• Mental model- The end user develops a mental image. Often called the
user's system perception.Consists of the image of the system that users carry
in their heads.
• Implementation model - The implementers of the system create an
implementation model. Consists of the look and feel of the interface
combined with all supporting information (books, videos, help files) that
describe system syntax and semantics
• Users can be categorized as: i) Novices: No syntactic
knowledge1 of the system and little semantic
knowledge2of the application or computer usage in
general.
• ii) Knowledgeable, intermittent users: Reasonable semantic
knowledge of the applicationbut relatively low recall of
syntactic information necessary to use the interface
• iii) Knowledgeable, frequent users: Good semantic and
syntactic knowledge that often leads to the “power-user
syndrome”; that is, individuals who look for shortcuts and
abbreviated modes ofinteraction.
• 2) The Process: The analysis and design
process for user interfaces is iterative and can
be represented using a spiralmodel.

• Four distinct framework activities are (1)

Interface analysis and modeling (2) Interface
design (3) Interface construction (4) Interface
validation.
• The spiral implies that each of these tasks will occur more than
once, with each pass around the spiralrepresenting additional
elaboration of requirements and the resultant design.
• In most cases, the construction activity involves prototyping—
the only practical way to validate whathas been designed.
(1) Interface analysis focuses on the profile of the users who will
interact with the system.
• Skill level, business understanding, and general receptiveness
to the new system are recorded;and different user categories
are defined.
• For each user category, requirements are elicited. In essence,
understand the system perception for each class of users.
• Once general requirements have been defined, a more
detailed task analysis is conducted.
• Those tasks that the user performs to accomplish the goals
of the system are identified,described, and elaborated
over a number of iterative passes through the spiral.
• Finally, analysis of the user environment focuses on the
physical work environment.
(2) The goal of interface design is to define a set of interface
objects, actions and their screen representations that
enable a user to perform all defined tasks in a manner that
meets every usability goal defined for the system.
(3) Interface construction normally begins with the creation of a
prototype that enables usage scenarios to be evaluated. As the
iterative design process continues, a user interface tool kit may be
used to complete the construction of the interface.
(4) Interface validation focuses on
• The ability of the interface to implement every user task correctly,
to accommodate all task variations, and to achieve all general user
requirements;
• The degree to which the interface is easy to use and easy to learn.
• The users’ acceptance of the interface as a useful tool in their work.
• Subsequent passes through the process elaborate task detail,
design information, and the
• operational features of the interface.
 INTERFACE ANALYSIS
• Understand the problem before you attempt to design
a solution. In the case of user interface design,
understanding the problem means understanding.
(1) The people (end users) who will interact with the
system through the interface
(2) The tasks that end users must perform to do their
work
(3) The content that is presented as part of the interface
(4) The environment in which these tasks will be
conducted.
 1. User Analysis
• The phrase “user interface” is probably all the
justification needed to spend some time
understanding the user before worrying about
technical matters.
• Information from a broad array of sources can be
used.
• User Interviews.
• Sales input.
• Marketing input.
• Support input.
• The following set of questions will help you to better
understand the users of a system:
• Are users trained professionals, technicians, clerical, or
manufacturing workers?
• What level of formal education does the average user have?
• Are the users capable of learning from written materials or
have they expressed a desire forclassroom training?
• Are users expert typists or keyboard phobic?
• What is the age range of the user community?
• Will the users be represented predominately by one gender?
 2. Task Analysis and Modeling
The goal of task analysis is to answer the following
questions:
• What work will the user perform in specific
circumstances?
• What tasks and subtasks will be performed as the
user does the work?
• What specific problem domain objects will the user
manipulate as work is performed?
• What is the sequence of work tasks—the workflow?
• What is the hierarchy of tasks?
• Use cases.
• Task elaboration.
• Object elaboration.
• Workflow analysis.
• Hierarchical representation.
 3. Analysis of Display Content
• The user tasks identified lead to the presentation of
a variety of different types of content.
• For modern applications, display content can range
from character-based reports (e.g., a spreadsheet),
graphical displays (e.g., a histogram, a 3-D model, a
picture of a person), or
specialized information (e.g., audio or videofiles).
• The analysis modeling techniques identify the
output data objects that are produced by an
application.
• These data objects may be
(1) Generated by components in other parts of
an application
(2) Acquired from data stored in a database that
is accessible from the application
(3) Transmitted from systems external to the
application in question.
 4. Analysis of the Work Environment
• People do not perform their work in isolation. They are
influenced by the activity around them, the physical
characteristics of the workplace, the type of equipment they are
using and the work relationships they have with other people.
• If the products you design do not fit into the environment, they
may be difficult or frustrating to use.
• In some applications the user interface for a computer-based
system is placed in a “user-friendly location” (e.g., proper
lighting, good display height, easy keyboard access), but in
others (e.g., a factory floor or an airplane cockpit), lighting may
be suboptimal, noise may be a factor, a keyboard or mouse may
not be an option, display placement may be less than ideal.
• The interface designer may be constrained by factors that
mitigate against ease of use.
• In addition to physical environmental factors, the
workplace culture also comes into play.
• Will system interaction be measured in some manner
(e.g., time per transaction or accuracy of a transaction)?
• Will two or more people have to share information before
an input can be provided?
• How will support be provided to users of the system?
These and many related questions shouldbe answered
before the interface design commences.
 INTERFACE DESIGN STEPS
• Once interface analysis has been completed, all tasks (or
objects and actions) required by the enduser have been
identified in detail and the interface design activity
commences.
• Interface design is an iterative process. Each user
interface design step occurs a number of
times,elaborating and refining information developed in
the preceding step.
• Although many different user interface design models
have been proposed, all suggest somecombination of
the following steps:
1. Using information developed during interface analysis
define interface objects and actions(operations).
2. Define events (user actions) that will cause the state
of the user interface to change. Model this behavior.
3. Depict each interface state as it will actually look to
the end user.
4. Indicate how the user interprets the state of the
system from information provided through the
interface.
• Regardless of the sequence of design tasks,
you should
(1) Always follow the golden rules
(2) Model how the interface will be
implemented
(3) Consider the environment (e.g., display
technology, operating system, development
tools) that will be used.
1. Applying Interface Design Steps:
• The definition of interface objects and the actions that are applied to them is an
importantstep ininterface design.
• To accomplish this, user scenarios are parsed. That is, a use case is written.
• Nouns (objects) and verbs (actions) are isolated to create a list of objects and actions.
• Once the objects and actions have been defined and elaborated iteratively, they are
categorized by type.
• Target, source, and application objects are identified. A source object (e.g., a report
icon)
is dragged and dropped onto a target object (e.g., a printer icon).
• The implication of this action is to create a hard-copy report. An application object
represents application-specific data that are not directly manipulated as part of screen
interaction.
• For example, a mailing list is used to store
names for a mailing. The list itself might be
sorted, merged, or purged (menu-based
actions), but it is not dragged and dropped via
user interaction.
2. User Interface Design Patterns:
• Graphical user interfaces have become so
common that a wide variety of user interface
design patterns has emerged.
Six common design issues are
i) System response time
ii) User help facilities
iii) Error information handling
iv) Command labeling
v) Application accessibility.
vi) Internationalization.