SOFTWARE ENGINEERING

UNIT - 4
 DESIGN CONCEPTS

• Architectural design
• Component – level Design
Architectural Design

• The software need architectural design to represent the design of the

software.
• it is the process of defining a collection of hardware and software
components and their interfaces to establish the framework for the
development of a computer system.
Component Level Design

• As soon as the first iteration of architectural design is complete, component

level design took place
• The objective of this design is to transform the design model into functional
software.
• Component level design is a interface , algorithms , data structures and
communication methods of a component.
TOPICS
 Design within the Context of Software Engineering
 The Design Process
 Design Concepts
 The Design Model
 Software Architecture
 Architectural Genres
 Architectural Styles
 Assessing Alternative Architectural Designs
 Architectural Mapping Using Data Flow, Components, Designing Class-Based
Components, Conducting Component-Level Design, Component-Level Design for
Web Apps , Designing Traditional Components, Component- Based Development.
SOFTWARE ARCHITECTURE
• The software needs the architectural design to represents the design of
software.
• Software architecture is the architecture of the software system like
BLUEPRINT in building architecture.

• Software architecture consists of

 software components
 details(data structure , algorithms etc..)
 relationships among the components
 dataflow , control flow and dependencies
• Elements of software architecture
 Components
abstract unit of s/w instruction and internal state which provides
transformation of data.

 Connectors
communicate, cooperate and coordinate among the components

 Configuration Topologies
it is a structure of architectural relationships among the components
and connectors.

 System Models
different architectural styles used to develop the s/w architecture
SOFTWARE ARCHITECTURE GENRES
• Architectural Genre is used to define the architectural approach for the build
of any structure.

• Considering the software programming areas, the architectural designs point

to a specific category, with a number of subcategories for each. 

• Some general styles that are taken into consideration with the genre of
buildings are – houses, condos, apartment buildings, office buildings,
industrial buildings, warehouses, etc.
• Communication – 
Systems that provide the infrastructure for transferring and managing data, for connecting
users of the data, or for presenting data at the edge of an infrastructure.
• Device – 
Systems that interact with the physical world to provide some point service for an individual.
• Entertainment and Sports – 
It includes those systems that manage public events or that provide a large group
entertainment experience.
• Financial – 
Systems that provide the infrastructure for managing and transferring money and other
securities.
• Artificial Intelligence – 
Systems which simulate or augment human cognition, locomotion, or other organic processes.
• Games – 
This includes the systems that provide an entertainment experience to individuals or groups.
• Military – 
Systems for consultation, command, communications, intelligence, and
control as well as offensive and defensive weapons.
• Operating Systems – 
It includes systems that sit just above hardware to provide basic software
services.
• Scientific – 
This includes systems that are used for scientific research and applications.
• Transportation – 
It includes systems that control water, ground air, or space vehicles.
• Government – 
This includes those systems that support the conduct and operations of a
local, state, federal, global, or other political entity.
Software Architecture Styles
• Data Centered Architecture
A data store (files or DB) resides at the centre of its architecture and is
accessed frequently by other components that update, add, delete or modify
with in the store.

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 architecture without the permission or concern of other clients

The client components operate independently.

DATA FLOW ARCHITECTURE
• This kind of architecture is used when INPUT data to be transformed into
OUTPUT data through a series of computational manipulative components.

• The figure represents pipe-and-filter architecture since it uses both pipe and
filter and it has a set of components called filters connected by pipes.

• Pipes are used to transmit data from one component to the next.

• Each filter will work independently and is designed to take data input of a
certain form and produces data output to the next filter of a specified form.
CALL & RETURN ARCHITECTURE

•  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. 

• 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. 

• 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.

 
OBJECT ORIENTED ARCHITECTURE
• This architecture is the latest version of call-and-return 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.
LAYERED ARCHITECTURE

• A no. of different layers are defined, each accomplishing operations progressively

become closer to the machine instruction set.

• At the outer layer, components will receive the user interface operations.

• At the inner layers, components will perform the operating system

interfacing(communication and coordination with OS)

• Intermediate layers to utility services and application software functions.

ASSESSING ALTERNATIVE ARCHITECTURAL DESIGNS
• To evaluate the quality of an architecture the design should be accomplished
effectively. 
• Basically there  are three different approaches for  the analysis of alternative 
architectural design as given below:

1. Architecture Trade off analysis Method

2. Architectural Complexity

3. Architectural Description Language(ADL)

ARCHITECTURE TRADE OFF ANALYSIS METHOD
• The Software Engineering Institute (SEI) has developed an architecture trade-off
analysis method  that establishes an iterative evaluation process for software
architectures.
• The design analysis activities that follow are performed iteratively:
1. Collect scenarios. A set of use-cases  is developed to represent the system from
the user’s point of view.

2. Elicit requirements, constraints, and environment description. This

information is required as part of requirements engineering and is used to be certain
that all customer, user, and stakeholder concerns have been addressed.
 3. Describe the architectural styles/patterns that have been chosen to address the
scenarios and requirements. The style(s) should be described using architectural views
such as

• Module view for analysis of work assignments with components and the degree to which
information hiding has been achieved.(subprogram)

• Process view for analysis of system performance.(solo program)

• Data flow view for analysis of the degree to which the architecture meets functional
requirements.(flow of data)
4. Evaluate quality attributes by considering each attribute in isolation.
Quality attributes for architectural design assessment include reliability,
performance, security, maintainability, flexibility, testability, portability,
reusability, and interoperability.

5. Identify the sensitivity of quality attributes to various architectural

attributes for a specific architectural style. This can be accomplished by
making small changes in the architecture and determining how sensitive a
quality attribute, say performance, is to the change.
• Architectural Complexity
The overall complexity of a proposed architecture is assessed by considering the
dependencies b/w components with in the architecture.
1.Sharing dependencies
it represents the dependency relationship among the customers who use the same
resources or producers who produce for the same customer.
2. Flow dependencies
represents the relationship b/w producer and consumer of the resources.
3. Constrained dependencies
represents the constraints on the relative flow of control among set of activities
• Architectural Description Language(ADL)
provides designers
with the ability to decompose the components
compose individual components into large components
combines the components
define the connection between the components
ARCHITECTURAL MAPPING USING DATA FLOW
• Structured design provides a
convenient transition flow from a DFD (Data
Flow Diagram) to software architecture.
• Types of information flow:
The two different types of information flows

1 Transaction flow - a single data item triggers information flow along one of
many paths.
2. Transform flow –overall data flow is sequential and flows along a small
number of straight line paths.
• Incoming flow
the path that transforms the external data into internal form

• Transform flow
the incoming data are passed through a transform center and begin
to move along the paths that lead it out of the software.

• Outgoing flow
the path that move the data out of the software.
• Steps involved
• Step 1: review the fundamental system model
• Step 2: review and refine data flow diagrams for the software
• Step 3: determine whether DFD has transform or transaction flow characteristics
• Step 4: isolate the transform center by specifying incoming and outgoing boundaries
• Step 5: perform “first level factoring”
• Step 6: perform “second level factoring”
• Step 7: refine the first iteration program structure using the design heuristic
COMPONENT LEVEL DESIGN
• Component level design occurs after the first iteration of the architectural
design.

• A component level design can be represented using some intermediate

representation (Eg graphical , tabular or text based ) that can be translated
into source code.

• What is a component ?
A component is modular building block for computer software.
• A component is a modular , deployable and replaceable part of a system that
encapsulate implementation and exposes a set of interfaces.

• Based on different points of view the meaning of component changes

object oriented view
conventional view
process related view
DESIGNING CLASS-BASED COMPONENTS

• Basic design principles

• Component level design guidelines
• Cohesion
• Coupling
DESIGNING CLASS-BASED COMPONENTS
Basic design principles
seven basic principles that are applicable to component level design and have
widely adopted when object oriented software engineering is applied.

• The Open-Closed Principle (OCP).  “A module [component] should be open for
extension but closed for modification.
• The Liskov Substitution Principle (LSP).  “Subclasses should be substitutable for
their base classes or main class. 
• Dependency Inversion Principle (DIP). “Depend on abstractions. Do not depend on
concretions.” 
• The Interface Segregation (Separation) Principle (ISP). “Many client-
specific interfaces are better than one general purpose interface. 

• The Release Reuse Equivalency Principle (REP). “The granule of reuse is

the granule of release.” 

• The Common Closure Principle (CCP). “Classes that change together

belong together.” 

• The Common Reuse Principle (CRP). “Classes that aren’t reused together
should not be grouped together.”
Component level design guidelines
• Components
naming conventions should be established for components that are specified as a
part of the architectural model and then refined and elaborated as a part of the component
level design
• Interfaces
interfaces provide important information about communication and collaboration
• Dependencies and inheritance
it is a good idea to model dependencies from left to right and inheritance from
bottom(derived classes) to top (base classes)
Cohesion
• Cohesion and coupling are used to measure the modules
• Cohesion is used to measure the intra dependency between the modules
• A good / best software will have high cohesion.
• Communication between two modules is very high

Types of cohesion
• Function cohesion (high)
• Sequential cohesion
• Communication cohesion
• Procedural cohesion
• Temporal cohesion
• Logical cohesion
• Coincidental cohesion (low)
• Functional cohesion
elements of the module are performed only one function is called as a functional
cohesion . Functional cohesion is the best cohesion in the s/w.
• Sequential cohesion
elements of the module are grouped because the output of one element serves as
input to another
• Communication cohesion
elements of the module are grouped together . The elements have same input and
same output data.
• Procedural cohesion
every element of module can perform the function in order way.
• Temporal cohesion
In the module every element can perform the task in certain time period
only.

• Logical cohesion
In the module, elements are performed the task then any problem occur then
communication b/w the modules are low

• Coincidental cohesion
unplanned cohesion
no communication happened b/w the elements of module
• Coupling
Coupling is used to measure the “interdependent” between the modules.
There are five types of couplings are present

i. data coupling (low)

ii. stamp coupling
iii. control coupling
iv. common coupling
v. content coupling (high)
• data coupling
the data is transferred from one module to another module . the dependency b/w the
two modules is LOW.
• stamp coupling
the complete data can be transferred from one module to another module
• control coupling
total data and control is transferred from one module to another module
• common coupling
entire data is transferred from one module to another module . sharing the global items
to all modules.
• content coupling
content is shared. the dependency b/w the two modules is HIGH
CONDUCTING COMPONENT-LEVEL DESIGN
• The following steps represents a task set for component level design , when it
is applied for an object oriented system.
• Step 1:identify all the classes that correspond to the problem domain
• Step 2: identify all the design classes that correspond to the infrastructure
domain.
• Step 3: elaborate all design classes that are not acquired as reusable
components.
a) specify message details when classes or components collaborate
b) identify appropriate interfaces for each component.
b) elaborate attributes and define the data types and data structures
that are required to implement them.
• Step 4: describe the persistent data sources(databases and files) and identify the
classes required to manage them.

• Step 5: develop and elaborate behavioural representations for a class or

component.

• Step 6: elaborate deployment diagrams to provide additional implementations

details

• Step 7: refactor every component-level design representation and always consider

alternatives.
COMPONENT-LEVEL DESIGN FOR WEB APPS
COMPONENT- BASED DEVELOPMENT