SOFTWARE ENGINEERING

L T P C
BCSE301L - 3 0 0 3
BCSE301P - 0 0 2 1

Dr. S M SATAPATHY
Associate Professor Sr.,
School of Computer Science and Engineering,
VIT Vellore, TN, India – 632 014.
SOFT WARE
DESIGN
 Module – 4

Software Design

1. Cohesion, Coupling

2. Architectural Design

3. Detailed Design

4. Object Oriented Design

5. User Interface Design

3
INTRODUCTION

• Design phase transforms SRS document:

– into a form easily implementable in some programming language.

SRS Document Design Documents

Design Activities
INTRODUCTION

• Items designed:
– module structure,
– control relationship among the modules
• call relationship or invocation relationship
– interface among different modules,
• data items to be exchanged among different modules,
– data structures of individual modules,
– algorithms for individual modules.
INTRODUCTION
• Good software designs:
– seldom arrived through a single step procedure:
– but through a series of steps and iterations.

• Design activities are usually classified into two stages:

– preliminary (or high-level) design
– detailed design.
• Meaning and scope of the two stages:
– vary considerably from one methodology to another.
HIGH LEVEL DESIGN
• The outcome of high-level design:
– program structure (or software architecture).
• Several notations are available to represent high-level design:
– Usually a tree-like diagram called structure chart is used.
– Other notations:
• Jackson diagram or Warnier-Orr diagram can also be used.
DETAILED DESIGN
• For each module, design:
– data structure
– algorithms
• Outcome of detailed design:
– module specification.
A FUNDAMENTAL QUESTION:
• How to distinguish between good and bad designs?
– Unless we know what a good software design is:
• we can not possibly design one.

• There is no unique way to design a system.

• Even using the same design methodology:
– different engineers can arrive at very different design solutions.
• We need to distinguish between good and bad designs.
WHAT IS GOOD SOFTWARE DESIGN?
• Correctness: Should implement all functionalities of the system correctly.
• Understandability: Should be easily understandable.
• Efficiency: Should be efficient.
• Maintainability: Should be easily amenable to change,
– i.e. easily maintainable.
WHAT IS GOOD SOFTWARE DESIGN?
• Understandability of a design is a major issue:
– determines goodness of design:
– a design that is easy to understand:
• also easy to maintain and change.
• Unless a design is easy to understand,
– tremendous effort needed to maintain it
– We already know that about 60% effort is spent in maintenance.
• If the software is not easy to understand:
– maintenance effort would increase many times.
UNDERSTANDABILITY
• Use consistent and meaningful names
– for various design components,
• Design solution should consist of:
– a cleanly decomposed set of modules (modularity),
• Different modules should be neatly arranged in a hierarchy:
– in a neat tree-like diagram.
MODULARITY
• Modularity is a fundamental attributes of any good design.
– Decomposition of a problem cleanly into modules:
– Modules are almost independent of each other
– divide and conquer principle.
• If modules are independent of each other:
– modules can be understood separately,
• reduces the complexity greatly.
– To understand why this is so,
• remember that it is very difficult to break a bunch of sticks but
very easy to break the sticks individually.
EXAMPLE OF CLEANLY AND NON-
CLEANLY DECOMPOSED MODULES
MODULARITY
• In technical terms, modules should display:
– high cohesion
– low coupling.
• Neat arrangement of modules in a hierarchy means:
– low fan-out
– abstraction
COHESION AND COUPLING
• Cohesion is a measure of:
– functional strength of a module.
– A cohesive module performs a single task or function.
• Coupling between two modules:
– a measure of the degree of interdependence or interaction between
the two modules.
• A module having high cohesion and low coupling:
– functionally independent of other modules:
• A functionally independent module has minimal interaction with
other modules.
ADVANTAGES OF FUNCTIONAL
INDEPENDENCE
• Functional independence is key to:
– understandability and good design:
– Complexity of design is reduced,
– different modules can be understood in isolation:
• modules are more or less independent of each other.
• Functional independence reduces error propagation.
– degree of interaction between modules is low.
– an error existing in one module does not directly affect other modules.
• Reuse of modules is possible.
ADVANTAGES OF FUNCTIONAL INDEPENDENCE

• A functionally independent module:

– can be easily taken out and reused in a different program.
• each module does some well-defined and precise function
• the interfaces of a module with other modules is simple and
minimal.
• Unfortunately, there are no ways:
– to quantitatively measure the degree of cohesion and coupling:
– classification of different kinds of cohesion and coupling:
• will give us some idea regarding the degree of cohesiveness of a
module.
COHESION
• Cohesion is a measure of the degree to which the elements of a module
are functionally related.
TYPES OF COHESION

Degree of
cohesion
COINCIDENTAL COHESION
• The module performs a set of tasks:
– which relate to each other very loosely, if at all.
• the module contains a random collection of functions.
• functions have been put in the module out of pure coincidence
without any thought or design.
• Coincidental cohesion exists in modules that contain instructions that
have little or no relationship to one another.
LOGICAL COHESION
• All elements of the module perform similar operations:
– e.g. error handling, data input, data output, etc.
• An example of logical cohesion:
– a set of print functions to generate an output report arranged into a
single module.
• Logical cohesion occurs in modules that contain instructions that appear
to be related because they fall into the same logical class of functions.
TEMPORAL COHESION
• The module contains tasks that are related by the fact:
– all the tasks must be executed in the same time span.
• Example:
– The set of functions responsible for
• initialization,
• start-up, shut-down of some process, etc.
• Module exhibits temporal cohesion when it contains tasks that
are related by the fact that all tasks must be executed in the
same time-span.
PROCEDURAL COHESION
• The set of functions of the module:
– all part of a procedure (algorithm)
– certain sequence of steps have to be carried out in a certain order for
achieving an objective,
• e.g. the algorithm for decoding a message.
• Procedural Cohesion occurs in modules whose instructions although
accomplish different tasks yet have been combined because there is a
specific order in which the tasks are to be completed.
COMMUNICATIONAL COHESION
• All functions of the module:
– reference or update the same data structure,
• Example:
– the set of functions defined on an array or a stack.
• X and Y both operate on the same input data or contribute towards the
same output data. But we might consider making them separate
procedures.
SEQUENTIAL COHESION
• Elements of a module form different parts of a sequence,
– output from one element of the sequence is input to the next.
– Example:
•

sort

search
display
FUNCTIONAL COHESION
• Different elements of a module cooperate:
– to achieve a single function,
– e.g. managing an employee's pay-roll.
• When a module displays functional cohesion,
– we can describe the function using a single sentence.

• The mathematical subroutine such as “calculate current GPA” or

“cumulative GPA” are typical example of functional cohesion.
DETERMINING COHESIVENESS
• Write down a sentence to describe the function of the module
– If the sentence is compound,
• it has a sequential or communicational cohesion.
– If it has words like “first”, “next”, “after”, “then”, etc.
• it has sequential or temporal cohesion.
– If it has words like initialize,
• it probably has temporal cohesion.
COUPLING
• Coupling is the measure of the degree of interdependence between
modules.
• There are no ways to precisely determine coupling between two modules:
– classification of different types of coupling will help us to
approximately estimate the degree of coupling between two modules.
•
EXAMPLE
• Consider the example of editing a student record in a “Student
Information System”.
TYPES OF COUPLING

Degree of
coupling
DATA COUPLING
• Two modules are data coupled,
– if they communicate via a parameter:
• an elementary data item,
• e.g an integer, a float, a character, etc.
– The data item should be problem related:
• not used for control purpose.
• The dependency between module A and B is said to be data coupled if
their dependency is based on the fact they communicate by only passing of
data. Other than communicating through data, the two modules are
independent.
STAMP COUPLING
• Two modules are stamp coupled,
– if they communicate via a composite data item
• such as a record in PASCAL
• or a structure in C.
• Stamp coupling occurs between module A and B when complete data
structure is passed from one module to another.
CONTROL COUPLING
• Data from one module is used to direct
– order of instruction execution in another.

• Example of control coupling:

– a flag set in one module and tested in another module.

• Module A and B are said to be control coupled if they communicate by

passing of control information. This is usually accomplished by means of
flags that are set by one module and reacted upon by the dependent
module.
CONTROL COUPLING
• Data from one module is used to direct
– order of instruction execution in another.

• Example of control coupling:

– a flag set in one module and tested in another module.

• Module A and B are said to be control coupled if they communicate by

passing of control information. This is usually accomplished by means of
flags that are set by one module and reacted upon by the dependent
module.
COMMON COUPLING
• Two modules are common coupled,
– if they share some global data.

• With common coupling, module A and module B have shared data. Global
data areas are commonly found in programming languages. Making a
change to the common data means tracing back to all the modules which
access that data to evaluate the effect of changes.
COMMON COUPLING
CONTENT COUPLING
• Content coupling exists between two modules:
– if they share code,
– e.g, branching from one module into another module.
• The degree of coupling increases
– from data coupling to content coupling.

• Content coupling occurs when module A changes data of module B or

when control is passed from one module to the middle of another. In Fig.
9, module B branches into D, even though D is supposed to be under the
control of C.
CONTENT COUPLING
LAYERED ARRANGEMENT OF MODULES
• Control hierarchy represents:
– organization of modules.
– control hierarchy is also called program structure.
• Most common notation:
– a tree-like diagram called structure chart.
• Neat arrangement of modules essentially means low fan-out and
abstraction.
CONCEPTS AND TERMINOLOGIES
• Superordinate and Subordinate Modules:
– A module that controls another module:
• said to be superordinate to it.
– Conversely, a module controlled by another module:
• said to be subordinate to it.
• Visibility:
– A module A is said to be visible by another module B,
• if A directly or indirectly calls B.
CONCEPTS AND TERMINOLOGIES
• Control Abstraction:
– The principle of abstraction requires:
• lower-level modules do not invoke functions of higher level
modules.
• Also known as layered design.
• Depth and Width:
– Depth:
• number of levels of control
– Width:
• overall span of control.
CONCEPTS AND TERMINOLOGIES
• Fan-out:
– a measure of the number of modules directly controlled by given
module.
– with high fan-out numbers is not a good design:
– a module having high fan-out lacks cohesion.
• Fan-in:
– indicates how many modules directly invoke a given module.
– High fan-in represents code reuse and is in general encouraged.
DESIGN APPROACHES
• Two fundamentally different software design approaches:
– Function-oriented design
– Object-oriented design
• These two design approaches are radically different.
– However, are complementary
• rather than competing techniques.
– Each technique is applicable at
• different stages of the design process.
FUNCTION-ORIENTED DESIGN
• A system is looked upon as something
– that performs a set of functions.
• Top-down Decomposition:
– Starting at this high-level view of the system:
• each function is successively refined into more detailed functions.
• Functions are mapped to a module structure.
FUNCTION-ORIENTED DESIGN
• The function create-new-library- member:
– creates the record for a new member,
– assigns a unique membership number
– prints a bill towards the membership
• Create-library-member function consists of the following sub-functions:
– assign-membership-number
– create-member-record
– print-bill
• Each subfunction:
– split into more detailed subfunctions and so on.
FUNCTION-ORIENTED DESIGN
• Centralised System State:
– The system state is centralized:
• accessible to different functions,
• member-records:
– available for reference and updation to several functions:
• create-new-member
• delete-member
• update-member-record
FUNCTION-ORIENTED DESIGN
• Centralised System State:
– The system state is centralized:
• accessible to different functions,
• member-records:
– available for reference and updation to several functions:
• create-new-member
• delete-member
• update-member-record
FUNCTION-ORIENTED DESIGN
• A few well-established function-oriented design approaches are:
– Step-wise refinement by Wirth [1971]
– Jackson’s Structured Design by Jackson [1975]
– Warnier-orr Methodology [1977, 1981]
– Structured Design by Constantine and Yourdan [1979]
– Hatley and Pirbhai’s Methodology [1987]
OBJECT-ORIENTED DESIGN
• System is viewed as a collection of objects (i.e. entities).
• System state is decentralized among the objects:
– each object manages its own state information.

• Library Automation Software:

– each library member is a separate object
• with its own data and functions.
– Functions defined for one object:
• cannot directly refer to or change data of other objects.
OBJECT-ORIENTED DESIGN
• Objects have their own internal data:
– defines their state.

• Similar objects constitute a class.

– each object is a member of some class.

• Classes may inherit features

– from a super class.

• Conceptually, objects communicate by message passing.

OOD VS. FOD
• Unlike function-oriented design,
– in OOD the basic abstraction is not functions such as “sort”, “display”,
“track”, etc.,
– but real-world entities such as “employee”, “picture”, “machine”, “radar
system”, etc.
• In OOD:
– software is not developed by designing functions such as:
• update-employee-record,
• get-employee-address, etc.
– but by designing objects such as:
• employees,
• departments, etc.
OOD VS. FOD
• Grady Booch sums up this fundamental difference saying:
– “Identify verbs if you are after procedural design and nouns if you are
after object-oriented design.”

• In OOD:
– state information is not shared in a centralized data.
– but is distributed among the objects of the system.
OOD VS. FOD
• In an employee pay-roll system, the following can be global data:
– names of the employees,
– their code numbers,
– basic salaries, etc.
• Whereas, in object oriented systems:
– data is distributed among different employee objects of the system.
• Objects communicate by message passing.
– one object may discover the state information of another object by
interrogating it.
• Of course, somewhere or other the functions must be implemented:
– the functions are usually associated with specific real-world entities
(objects)
– directly access only part of the system state information.
OOD VS. FOD
• Function-oriented techniques group functions together if:
– as a group, they constitute a higher level function.
• On the other hand, object-oriented techniques group functions together:
– on the basis of the data they operate on.

• To illustrate the differences between object-oriented and function-

oriented design approaches,
– let us consider an example ---
– An automated fire-alarm system for a large building.
AUTOMATED FIRE-ALARM SYSTEM

• We need to develop a computerized fire alarm system for a large multi-

storied building:
– There are 80 floors and 1000 rooms in the building.
• Different rooms of the building:
– fitted with smoke detectors and fire alarms.
• The fire alarm system would monitor:
– status of the smoke detectors.
AUTOMATED FIRE-ALARM SYSTEM
• Whenever a fire condition is reported by any smoke detector:
– the fire alarm system should:
• determine the location from which the fire condition was reported
• sound the alarms in the neighboring locations.
• The fire alarm system should:
– flash an alarm message on the computer console:
• fire fighting personnel man the console round the clock.
• After a fire condition has been successfully handled,
– the fire alarm system should let fire fighting personnel reset the alarms
FUNCTION-ORIENTED APPROACH:
• /* Global data (system state) accessible by various functions */
BOOL detector_status[1000];
int detector_locs[1000];
BOOL alarm-status[1000]; /* alarm activated when status set */
int alarm_locs[1000]; /* room number where alarm is located */
int neighbor-alarms[1000][10]; /* each detector has at most */
/* 10 neighboring alarm locations */
The functions which operate on the system state:
interrogate_detectors();
get_detector_location();
determine_neighbor();
ring_alarm();
reset_alarm();
report_fire_location();
OBJECT-ORIENTED APPROACH:
• class detector
attributes: status, location, neighbors
operations: create, sense-status, get-location,
find-neighbors
• class alarm
attributes: location, status
operations: create, ring-alarm, get_location,
reset-alarm
• In the object oriented program,
– appropriate number of instances of the class detector and alarm should
be created.
OOD VS. FOD
• In the function-oriented program :
– the system state is centralized
– several functions accessing these data are defined.
• In the object oriented program,
– the state information is distributed among various sensor and alarm
objects.
• Use OOD to design the classes:
– then applies top-down function oriented techniques
• to design the internal methods of classes.
• Though outwardly a system may appear to have been developed in an
object oriented fashion,
– but inside each class there is a small hierarchy of functions designed in
a top-down manner.
ARCHITECTURAL
DESIGN
SOFTWARE ARCHITECTURE
• A widely quoted definition of software architecture given by Bass, Clements, and
Karman says
“The software architecture of a program or computing system is the structure
or structures of the system, which comprise: software components, the
externally visible properties of those components and the relationships among
them.”

• The architecture is not the operational software, it is a representation that

enables a software engineer to:
– Analyze the effectiveness of the design in meeting its stated requirements,
– Consider architectural alternatives at a stage when making design changes is
still relatively easy, and
– Reduce the risks associated with the construction of the software.
SYSTEM ARCHITECTURE VS. SOFTWARE ARCHITECTURE
• Under system architecture:
– All the requirements are partitions into different categories,
– Sub system are identified,
– Requirements are assigned to different sub system,
– The functionality of each sub system is specified and
– Interface design is created for enabling communication between sub systems.

• Software architecture is the description of structure of new software which is

under planning, description of data, interfaces and algorithms used in it. The
large system are designed iteratively, architects keep adding details by moving
back and forth in previous version and current version of architecture design.
– Here relationships between different sub systems are identified.
– An abstract specification of services and constraints of each sub systems are defined.
– Interface description is defined and documented
– Data structure required to implement system is described in details.
– Algorithms used to deliver services are defined.
WHY IS SOFTWARE ARCHITECTURE IMPORTANT?
• Software architecture provides a representation that facilitates communication
among all stakeholders interested in the development of a computer-based
system.
• Architecture highlights early design decisions that will have a profound impact on
all software engineering work that follows.
• Architecture constitutes a relatively small, intellectually graspable mode of how
the system is structured and how its components work together.

Q. The key question is how to define structure of the system.

Views are used to define structure
MODEL VIEWS
• The four views of the model of a real system are: logical, development, process
and physical view are produced for better communication.
– Logical view: It is the functionality that the system provides to end-users. So it is an
external view that shows the attributes of the architecture such as maintainability,
extensibility, performance and security.
– Process view: It deals with the dynamic behaviour of the system, i.e., the system
processes, their communication, data flow and focuses on the runtime behaviour of
the system. Process and data flow diagrams are used to represent it.
– Development view: It depicts a system from a programmers perspective. It is
concerned with software management. Components or Modules of the system are
shown here.
MODEL VIEWS
– Physical view: It depicts the servers and storage system. It is concerned with the
topology of software components on the physical layer, as well as communication
between these components. Deployment diagrams are used to represent it.

• In software architecture, several models are used to produce different

views, static models are used to produce structure of a Logical View,
dynamic models are used to depict Process View and Interface
models are used to depict communication between sub systems.
• Modules of the system are used to depict Development View.
• Deployment diagrams depicting servers are used to show physical
view of architecture.
CONTROL MODELS
• To handle the control flow between subsystems.
• Control models
– Centralised control
• One sub-system has overall responsibility for control and starts and stops other
sub-systems.
– Event-based control
• Each sub-system can respond to externally generated events from other sub-
systems or the system’s environment.
CONTROL MODELS
• Centralised control
– Call Return Model
• Top down sub routine model
• Controls starts at the top of hierarchy
• Applicable to sequential systems

– Manager Model
• Applicable to concurrent systems
• One subsystems controls , starts and stops the coordination of other
subsystems.
CONTROL MODELS
• Event-based control
• It is driven by externally generated events. Timing of the event is with the subsystem
that process the event.
• Broadcast models.
– Broadcast is sent to all subsystems.
– Any sub system which can handle the broadcast will react
CONTROL MODELS
• Interrupt-driven models.
– Used in real-time systems
– Interrupt handler components handles the interrupts
AGILITY AND ARCHITECTURE
• To avoid rework, user stories are used to create and evolve an
architectural model (walking skeleton) before beginning any coding.
• Use models which allow software architects to add user stories to the
evolving storyboard and works with the product owner to prioritize the
architectural stories as “sprints” (work units) are planned.
• Well run agile projects include delivery of architectural documentation
during each sprint.
• After the sprint is completed, the architect reviews the working prototype
for quality before the team presents it to the stakeholders in a formal
sprint review.
ARCHITECTURAL STYLES
• Each style describes a system category that encompasses:
– set of components (for example: a database, computational modules) that
perform a function required by a system.
– set of connectors that enable “communication, coordination and
cooperation” among components.
– 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 by analyzing the known properties of its constituent
parts.
DATA CENTERED ARCHITECTURE

• The architecture reads data store (repository or blackboard), multiple

client software placed around it are connected to the data store.
DATA FLOW / PIPE AND FILTER ARCHITECTURE

• In this architecture, each rectangular component represents the architecture

labelled a filter and the connecting arrows between the filters are labelled
pipes. The data flow is read in the right to left direction.
CALL RETURN ARCHITECTURE

• In this architecture, the main program is connected to three controller

subprograms. Each controller subprograms are connected to two application
subprograms each. These two subprograms again constitutes an application
subprogram.
CLIENT SERVER ARCHITECTURE
• It is a distributed design system involving
clients and servers, which reside on separate
machines and they are connected through
network. It is called as 2 Tier architectural
system.

• The example of client server architecture is

Web Browser over which clients send request
to database servers and obtain response over
from them. User interface is always on client
and data management is on server.
LAYERED ARCHITECTURE

• The circular diagram has four layers: core layer, utility layer, application layer, and
user interface layer from inner to outer level. The outer level is in a semicircle
form. Each layer has components displayed with squares which are decreasing
in number from outer to inner layers.
LAYERED ARCHITECTURAL STYLE
• Under this style application functionality is broken down into various
layers by grouping relevant functions into one layer and placing the layers
one after another in vertical fashion. Each layer is assigned a particular role,
the interaction between layers is through interfaces.

• For example, the interaction of users over internet with first layer, say,
presentation is through http, interaction between middle layer (business
logic) and back layer (database) is through JDBC

• By dividing responsibility among different layers, separates out concerns,

which makes it easy for architects to bring flexibility and maintainability.

• There are two styles of layered architecture:

– strict layering
– relax layering
LAYERED ARCHITECTURAL STYLE
• In a strict layering style, components of one layer can only talk to
components present either in same layer or with components which are
directly below it.

• In relaxed layering style, components can interact with components of

same layer or with all components present in any layer which is below it.

• The layers can come all on a single hardware machine or each layer on
one separate hardware computer. If layers are mapped to individual
hardware machines, it is known as n-tier.

• Generally, web applications are spread over minimum 3 layers, first layer is
presentation layer, second layer consists of business logic processing and
third layer is data access.
N-TIER / 3-TIER ARCHITECTURAL STYLE
• It is an improved way of designing layered architecture style, here instead of
assigning all layers to one physical server, each layer is assigned and hosted to a
separate physical computer.

• The tiers interact with each other using platform specific protocol of
communication- HTTP, JDBC, etc.
MODEL VIEW CONTROLLER ARCHITECTURE
• Model View Controller or MVC, it is a software design pattern for developing
web applications.
• MVC pattern has three parts:
– Model - The lowest level of the pattern which is responsible for maintaining data.
It accepts requests from View and responds to instructions from the controller to
update its data. It is the data base layer.
– View - This is responsible for displaying all or a portion of the data to the user.
This is screen form design portion. They are script based systems such as JSP, ASP,
PHP. etc..
– Controller – This is Software Code that controls the interactions between the
Model and View.
• It receives the input, validates it and then performs the business operation that
modifies the state of the data model. Typically, it reads data from a view (form),
control user input, and send input data to the model (database).
• MVC isolates the application logic from the user interface layer and supports
separation of concerns.
MODEL VIEW CONTROLLER ARCHITECTURE
MODEL VIEW CONTROLLER ARCHITECTURE
• The diagram shows a model view controller architecture. The architecture
contains three section. The client, the server and the external data.
• A client accessed a browser. The browser connects to the server via two paths.
• The server contains controller, model and view. The browser sends a user
request or data to the controller or the browser accesses H T M L data in the
view.
– The controller manages user requests, selects model behaviour and selects view
response. The controller sends a view selection to view and sends a sends a state
change behaviour request to model.
– The view prepares data from model, requests update from model and presents
view selected by controller. View receives the data from model and sends an
updated request to model.
– The model, encapsulates functionality, encapsulates content objects and
incorporates all web app states. Model has a two data exchange with external
data.
OBJECT-ORIENTED ARCHITECTURE
• In an object oriented architecture, the functionality is broken down into sub
systems using the constructs of object oriented data models such as object
classes, attributes and operations.
• It is a modular decomposition architectural style which is applied at application
design level.
• This architecture is based on breaking the responsibilities of an application into
separate reusable independent objects.

• Data and methods, i.e., structure and behaviour both are kept in the object.
This kind of style views the system as a collection of cooperating objects
instead of set of sub programs or procedures.

• Objects are solid, independent and loosely coupled. Interfaces or messages are
used by the objects to communicate with each other.
OBJECT-ORIENTED ARCHITECTURE

• In this diagram, an actor connects to a security logon and requests logon and
enters name password on logon. The security logon has an internal loop that
relays: display, display message, and display logon. If the security logon is valid,
the actor accesses the account data base. After selecting the user type the
actor accessed the system.
INTER ORGANIZATIONAL COMMUNICATION
• Some time organizations follow distributed architecture or they need to talk to
each other to get specialized services from other organizations.

• These days in each transaction based application where payment is involved,

requires integration with payment gateways.

• In such cases, either message or web services based architecture can be

adopted.

• It is an example of distributed architecture systems which can support

resource sharing, interoperability, scalability and transparency.
MESSAGE ORIENTED ARCHITECTURE
• The need for integrating different systems is increasing. The way departments is
to define schema which contains semantics of information which will be
exchanged between two departments. It is called as
– contract between Service Provider
– Service Consumer.

• It is expressed in Web Service Definition Language (WSDL) document.

• On the basis of format of information agreed, an XML packet is generated. It is

sent over transport protocol, http. The envelope so created is called as Simple
Object Access Protocol (SOAP).

• The way to achieve the above integration is either use

– Message Oriented architecture (MOA)
– Service Oriented Architecture (SOA) [Web Services].
MESSAGE ORIENTED ARCHITECTURE
• In SOA, the integration takes place between components (web services) which
are identical so integration is seamless. The SOA integration is Action
Oriented, i.e., message is sent, operation is performed over it and results are
delivered back by the invoked web service. Integration is on point to point
basis.
• In Message Oriented Architecture, the integration components are not
necessarily identical but message format is identical. A message bus is capable
of providing:
– Message-oriented communications: The communication between disparate
applications is based on known protocol, message format (known schema) and
protocol.
– Complex processing logic: Complex operations is broken down into simple
operations and results are computed in multiple stages. The final results are
joined up.
ENTERPRISE SERVICE BUS (ESB)
• ESB uses message router which locates the desired web services in Universal
Description, Discovery and Integration (UDDI) based directory before sending
the request.

• It then interacts with its port on the web site called as endpoint on behalf of
Service consumer application acting as proxy for Service Provider.

• So all service consumers only talk to single point of contact, i.e., enterprise
service bus.

• As a value added service, an ESB usually provides data transformational

services which transform messages from one data format to another.
PRINCIPLES OF SOA ARCHITECTURE STYLE
• Independence among services: Development, deployment, maintenance and
version control for each service is not dependent on other services.

• Loose coupling of services: Services interact with each other through well
defined interfaces so their maintenance is easy as it does not impact
application.

• Services share schema and binding agreement, not class: Schema and binding
agreement are used to share information with service consumers allowing
them to use services it is a better way of sharing compared to sharing internal
details of classes.

• Policy based Compatibility: Policy is defined in terms of data format (XML),

transport protocol (http) and security. It is called as SOAP, it brings
interoperability since services can run on any platform.
DOMAIN DRIVEN DESIGN STYLE
• Common Communication Language: Building model of domain facilitates both
IT teams and business stakeholders to articulate business wisdom and
requirements in a common language free from technical jargons.

• Easy of Testing: Loose coupling and cohesion are the cornerstone of domain
modelling, which make this style easy to test the application.

• Extensible: As this style is based upon object oriented design, which in turn
supports the principles of inheritance so it implies that this style is extensible.
CLOUD COMPUTING ARCHITECTURE STYLE
• Cloud computing is defined as delivering compute power as service instead of
a product to the customers. Thus shared resources such as storage box,
software and information are provided to customers as utility like water or
phone connection over an internet. The customers pay for resources as per
usage.
• It supports multi tenancy architecture whereby it enables sharing of resources
and costs across a large number of users by centralizing infrastructure at those
locations which has lower costs of land, electricity, labour. It also enables
better utilization and efficiency of system resources which are not utilized fully.

• Cloud Computing comes in three flavours: Infrastructure as a Service ( IaaS ),

Platform as a Service ( PaaS ) and Software as a Service (SaaS ).
CLOUD COMPUTING ARCHITECTURE STYLE
• Infrastructure as a Service: The cloud providers are expected to create fabric of all the
hardware servers, storage boxes and system software as a common pool in the data
Canters so that as per the requirements of each application, the resources can be
assigned to it instantaneously

• Platform as a Service: Besides, building the pool of Infrastructure, the cloud providers
are expected to install both open source and proprietary Web Servers, Application
Servers, Databases and tools so that a technology agnostic development platform
becomes available for application development. The development platform should be
available in an on-demand provision mode to the customer organizations.

• Software as a Service: The cloud Providers, install on the Infrastructure pool, some
commonly used finished products both COTS and be spoke applications such e-mail,
Customer Relationship Module (CRM)MS office, Star Office. It also includes other
customized applications which the organization is developing for sharing with others
such as HR, Payroll, Accounting, etc. on pay as per usage pattern.
GRID COMPUTING AND CLOUD COMPUTING
• Grid Computing is an aggregation, selection and sharing of geographically
distributed resources such as computers, storage, data sources and specialized
devices owned by different organizations for solving resource intensive specific
engineering and science problems.

• Creating Cloud Computing Platform:- Hypervisor software (e.g. Xen, ESX,

Hyper V, KVM) (refer layer 4 in Figure 4.9) is used to partition a single physical
machine into several virtual machines.

• The operating system which runs inside the virtual machine is called as Guest
Operating System.
GRID COMPUTING AND CLOUD COMPUTING
• Hypervisor is positioned between the guest operating system running in the
virtual machine and hardware resources.

• This positioning enables the hypervisor to control how guest operating system
running inside a virtual machine uses hardware resources.

• This enables administrator to control all hardware resources using the

hypervisor as single point of control, which allows him to view hardware as a
pool of resources which can run arbitrary services on demand.
MULTI TENANCY ARCHITECTURE
• Multi tenancy means a type of architecture in which single instance of software
hosted on a server serves several customers organizations (tenants). Multi
tenancy is different from multi instance architecture. In the latter case separate
software instances or hardware systems are enabled for different organizations.

• But in case of multitenant architecture, the application is designed in such a

way so that it can be configured for different customer organizations and
dataset of each organization is stored separately. Separate virtual instance of
application is created for each organization. There are three ways to implement
it.
MULTI TENANCY ARCHITECTURE
• Separate Databases, Separate schema
– Common application source code and common system resources are used by all
the tenants.
– The data base and schema are different for different tenants. The data and schema
of each tenant is stored separately.
– It results in sound and robust security and privacy for the data of each tenant.

• Shared Database, Separate Schemas

– Another approach involves housing several tenants in one database, each tenant
has separate set of tables, indexes, triggers and a schema.
– The data is stored at one place for all the tenants so security and privacy of data
are concern.
– But each tenant has separate schema, it allows each tenant to exercise its own
strategic control over the database design.
MULTI TENANCY ARCHITECTURE
• Shared Database, Separate Schemas
– This approach is good for applications which use small number of tables, say of the
order of 100 or less.
– The cost of hosting a tenant is lower since database of all the tenants is common
so costs of data storage and maintenance gets shared among the tenants.

• Shared Database, Shared Schema

– This approach uses one database and same set of tables for all the tenants hosted
on the server.
– The tables store records of all tenants in same table; tenant ID is assigned to each
row (refer Figure 4.8).
– This approach is good if large number of tenants with small number of hardware
servers are to be served.
– Naturally, both the cost of tenancy and degree of data isolation are lowest in this
kind of data architecture.
CORE CONFIGURABLE AND CUSTOMIZABLE ARCHITECTURE
• Core:- Applications which have the potential for replication should be designed
following paradigm of core, configurable and customizable one.

• Configuration:- Out of 15 services, only 5 optional services as chosen by state

will be enabled. The fonts, layout and colour of different forms will be enabled
as per the choice of state.

• Customization: - In program code may be required to meet state specific

requirements.
– Some of the key benefits of configurable solutions are that only one ? version of
application is maintained so a better support can be provided. Quality control
remains focused which results in stable and reliable system.
USER INTERFACE
DESIGN
USER EXPERIENCE DESIGN ELEMENTS
• User experience design tries to ensure that no aspect of your software
appears the final product without the explicit decision of stakeholders to
include it.
– Strategy: Identifies user needs and customer business goals that form the basis for
all U X design work.
– Scope: Includes both the functional and content requirements needed to realize a
feature set consistent with the project strategy.
– Structure: Consists of the interaction design [For example, how the system reacts
in response to user action] and information architecture.
– Skeleton: Comprised of three components: information design, interface design,
navigation design.
– Surface: Presents visual design or the appearance of the finished project to its
users.
USER EXPERIENCE DESIGN ELEMENTS

• The elements in the design range from concrete to abstract with concrete at
the top. The elements from concrete to abstract are: Surface, skeleton,
structure, scope, and strategy. The surface constitutes the visual design. The
skeleton is consists of interface design, navigation design and information
design. The structure consists of interaction design and information
architecture. Scope consists of functional specifications, and content
requirements. The strategy consists of user needs and business goals.
INFORMATION ARCHITECTURE
• Information architecture structures lead organization, labeling, navigation, and
searching of content objects.

• Content architecture focuses on the manner content objects are structured

for presentation and navigation.

• Software architecture addresses the manner the application is structured to

manage user interaction, effect navigation, and present content.

• Architecture design is conducted in parallel with interface design, aesthetic

design, and content design.
• Decisions made during architecture design action will influence work
conducted during navigation design.
USER INTERACTION DESIGN
• Interaction design focuses on interface between product and user.
– Modes of user input and output include voice input, computer speech generation,
touch input, 3D printed output, immersive augmented reality experiences, and
sensor tracking of users.

• User interaction should be defined by the stakeholders in the user stories

created to describe how users can accomplish their goals using the software
product.
• User interaction design should also include a plan for how information should
be presented within such a system and how to enable the user to understand
that information.
• It is important to recall that the purpose of the user interface is to present just
enough information to help the users decide what their next action should be
to accomplish their goal and how to perform it.
USABILITY ENGINEERING
• Usability engineering is part of UX design work that defines the specification,
design, and testing of the human-computer interaction portion of a software
product.
• This software engineering action focuses on devising human-computer
interfaces that have high usability.
• If developers focus on making a product easy to learn, easy to use, and easy to
remember over time, usability can be measured quantitatively and tested for
improvements in usability.

• Accessibility is the degree to which people with special needs are provided
with a means to perceive, understand, navigate, and interact with computer
products.

• Accessibility is another aspect of usability engineering that needs to be

considered during design.
VISUAL DESIGN
• Visual design (aesthetic design or graphic design) is an artistic endeavour that
complements the technical aspects of the user experience design.

• Without it, a software product may be functional, but unappealing.

• With it, a product draws its users into a world that embraces them on an
emotional as well as an intellectual level.

• Graphic design considers every aspect of the look and feel of a web or mobile
app.

• Not every software engineer has artistic talent. If you fall into this category,
hire an experienced graphic designer to help.
GOLDEN RULE 1: PLACE USER IN CONTROL
• Define interaction modes in a way that does not force a user into unnecessary
or undesired actions.

• Provide for flexible interaction.

• Allow user interaction to be interruptible and undoable.

• Streamline interaction as skill levels advance and allow the interaction to be

customized.

• Hide technical internals from the casual user.

• Design for direct interaction with screen objects.

GOLDEN RULE 2: REDUCE USER’S MEMORY LOAD
• Reduce demand on short-term memory.

• Establish meaningful defaults.

• Define shortcuts that are intuitive.

• The visual layout of the interface should be based on a real-world metaphor.

• Disclose information in a progressive fashion.

GOLDEN RULE 3: MAKE INTERFACE CONSISTENT
• Allow the user to put the current task into a meaningful context.

• Maintain consistency across a family of applications.

• If past interactive models have created user expectations, do not make changes
unless there is a compelling reason to do so.
USER INTERFACE DESIGN MODELS
• User model — a profile of all end users of the system.

• Design model — a design realization of the user model.

• Mental model (system perception) — the user’s mental image of what the
interface is.

• Implementation model — the interface “look and feel” coupled with

supporting information that describe interface syntax and semantics.

An interface designer needs to reconcile these models and derive a consistent

representation of the interface.
USER INTERFACE DESIGN PROCESS
USER INTERFACE ANALYSIS AND DESIGN
• Interface analysis focuses on the profile of the users who will interact with the
system.

• Interface design defines a set of interface objects and actions that enable a user
to perform all defined tasks in a manner that meets every usability goal defined
for the system.

• Interface construction normally begins with the creation of a prototype that

enables usage scenarios to be evaluated.

• Interface validation focuses on:

– The ability of the interface to implement every user task correctly.
– The degree to which interface is easy to use and easy to learn.
– The user’s acceptance of the interface as a tool in her work.
 Disclaimer

The material for the presentation has been compiled from various sources such
as prescribed text books by Roger S pressman and Ian Sommerville and other
tutorials and lecture notes. The information contained in this lecture/
presentation is for educational purpose only.

113
THANK YOU FOR YOUR ATTENTION !

114