Software Engineering (203105303)

Shaikh Amin F., Assistant Professor

Computer Science & Engineering
 Unit-4
System Design
Design concept

Design Concepts, Design Model,

Software Architecture, Data Design,
Architectural Styles and Patterns,
Architectural Design, Alternative
architectural designs, Modeling
Component level design and its
modeling, Procedural Design, Object
Oriented Design.

Image source : Google

Software Design
Mitch Kapor, the creator of Lotus 1-2-3, presented a “software design manifesto”
in Dr. Dobbs Journal. He said:
Good software design should exhibit:
Firmness: A program should not have any bugs that inhibit its function.
Commodity: A program should be suitable for the purposes for which it was intended.
Delight: The experience of using the program should be pleasurable one.
 Analysis Model -> Design Model

Co m p o n e n t -
sc e n a r i o - b a se d f l o w- o r i e n t e d L e v e l D e si g n
e l e me nt s e l e me nt s
use-cases - text data flow diagrams
use-case diagrams control-flow diagrams
activity diagrams processing narratives
swim lane diagrams
I n t e r f a c e D e si g n
Analy sis Model

A r c h i t e c t u r a l D e si g n
c l a ss- b a se d be ha v i or a l
e l e me nt s e l e me nt s
class diagrams state diagrams
analysis packages sequence diagrams
CRC models D a t a / Cl a ss D e si g n
collaboration diagrams

Design Model

Image source : Google

 Design and Quality
• The design must implement all of the explicit requirements contained in
the analysis model, and it must accommodate all of the implicit
requirements desired by the customer.
The design must be a readable, understandable guide for those who
generate code and for those who test and subsequently support the
software.
The design should provide a complete picture of the software,
addressing the data, functional, and behavioral domains from an
implementation perspective.
 Fundamental Concepts
• Abstraction

• Architecture

• Design Patterns

• Modularity

• Information Hiding

• Functional Independence

• Refinement

• Refactoring

• Object-Oriented Design concepts

 Fundamental Concepts
• Abstraction

• Abstraction is used to hide background details or unnecessary implementation

about the data.

• So that users see only required information.

• Type 1: Procedural Abstraction:

• There is collections of subprograms.One is hidden group another is visible group

of functionalities. Example:

Private:Fuel_machine()Set_top_speed()Develop_engine()Public:Turn_on(),

Turn_off(Accelerate(), Break()
 Fundamental Concepts
• Abstraction

• Type 2: Data Abstraction:

• Collections of data that describe data objects. Show representation data & hide

manipulation data.Examples: Data Structure Programs directly used Push(),

Pop(), Top() and Empty() methods

Data Abstraction

door
manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism

implemented as a data structure

Procedural Abstraction

open

details of enter
algorithm

implemented with a "knowledge" of the

object that is associated with enter
 Fundamental Concepts
• Architecture

• The architecture is the structure of program modules where they interact with

each other in a specialized way.

• Structural Properties:

• Architectural design represent different types of components like modules, objects

& relationship between these.

• Extra-Functional Properties:

• How design architecture achieve requirements ofPerformance, Capacity,

Reliability, Security, Adaptability & other System Characteristics Performance,

Capacity, Reliability, Security, Adaptability & other System Characteristics.

• Families of related systems: The architectural design should draw repeatable

 Fundamental Concepts
• Architecture

• Families of related systems: The architectural design should draw repeatable

patterns. They have ability to reuse repeatable blocks.

 Fundamental Concepts
• Design Patterns

• Pattern: Each pattern describes a problem that occurs over and over multiple

times in our environment. So the solution can be used millions of times without

ever doing it same way twice.

• The pattern simply means a repeated form or design in which the same shape is

repeated several times to form a pattern.

 Fundamental Concepts
• Information Hiding

• Modules should be specified and designed in such a

way that the data structures and algorithm details

of one module are not accessible to other

modules.

• They pass only that much information to each

other, which is required to accomplish the

software functions.

• The way of hiding unnecessary details in modules

is referred to as information hiding.

 Fundamental Concepts
• Modularity

• Modularity simply means dividing the system or project into smaller parts to

reduce the complexity of the system or project.

• After developing the modules, they are integrated together to meet the software

requirements.

• Modularizing a design helps to effective development, accommodate changes

easily, conduct testing, debugging efficiently and conduct maintenance

work easily.
 Modularity: Trade-offs

What is the "right" number of modules

for a specific software design?
module development cost

cost of
software
module
integration
cost

optimal number number of modules

of modules
 Fundamental Concepts
• Functional Independance

• The functional independence is the concept of

separation and related to the concept of

modularity, abstraction and information hiding.

• Criteria 1: Coupling. The degree in which module

is "connected" to other module in the system.

Low Coupling necessary in good software.

• Criteria 2: Cohesion· The degree in which module

perform functions in inner module in the system.·

High Cohesion necessary in good software.

 Fundamental Concepts
• Refinement

• Refinement is a top-down design approach.

• It is a process of elaboration.

• A program is established for refining levels of procedural details.

• A hierarchy is established by decomposing a statement of function in a stepwise

manner till the programming language statement are reached.

– Example: INPUT – INPUT
– Get number 1 (Integer) – Get number 1 (Integer)
– Get number 2 (Integer) – Get number 2 (Integer)
– PROCESS – While (Invalid Number)
– OUTPUT – EXIT
 Fundamental Concepts
• Refactoring

• Refactoring is the process of changing the internal software system in a way

that it does not change the external behavior of the code still improves its

internal structure.

• When software is refactored the existing design is examined for redundancy,

unused design elements, unnecessary design algorithms, poorly

constructed data, inappropriate data structure or any other design failure that

can be corrected for better design.

 Fundamental Concepts
• Object Oriented Design Concepts

• Object Oriented is a popular design approach for analyzing and designing an

application.

• Advantage is that faster, low cost development and creates a high quality

software.
 The Design Model
• Design modeling in software engineering represents the features of the

software that helps engineer to develop it effectively, the architecture, the

user interface, and the component level detail.

• Design modeling provides a variety of different views of the system like

architecture plan for home or building.

• Different methods like data-driven, pattern-driven, or object-oriented methods

are used for constructing the design model. All these methods use set of design

principles for designing a model.

 The Design Model
high

a n a ly sis m o d e l

class diagr ams

analysis packages
use- cases - t ext class diagr ams
Requirement s:
CRC models use- case diagr ams const raint s
analysis packages
collabor at ion diagr ams
act ivit y diagr ams CRC models int eroperabilit y
dat a f low diagr ams sw im lane diagr ams collabor at ion diagr ams t arget s and
cont r ol- f low diagr ams collabor at ion diagr ams dat a f low diagr ams
pr ocessing nar r at ives st at e diagr ams cont r ol- f low diagr ams
conf igurat ion
sequence diagr ams pr ocessing nar r at ives
st at e diagr ams
sequence diagr ams

design class r ealizat ions

subsyst ems
collabor at ion diagr ams t echnical int er f ace component diagr ams
design class r ealizat ions
design design classes
subsyst ems
Navigat ion design act ivit y diagr ams
collabor at ion diagr ams
GUI design sequence diagr ams
component diagr ams
d e sig n m o d e l design classes
r ef inement s t o: act ivit y diagr ams
r ef inement s t o: sequence diagr ams
component diagr ams
design class r ealizat ions design classes
subsyst ems act ivit y diagr ams
low collabor at ion diagr ams sequence diagr ams deployment diagr ams

archit ect ure int erf ace component -level deployment -level
element s element s element s element s
 Design Model Elements

Co m p o n e n t -
sc e n a r i o - b a se d f l o w- o r i e nt e d L e v e l D e si g n
e l e me nt s e l e me nt s
use-cases - text data flow diagrams
use-case diagrams control-flow diagrams
activity diagrams processing narratives
swim lane diagrams
I n t e r f a c e D e si g n
Analy sis Model

A r c h i t e c t u r a l D e si g n
c l a ss- b a se d be ha v i or a l
e l e me nt s e l e me nt s
class diagrams state diagrams
analysis packages sequence diagrams
CRC models D a t a / Cl a ss D e si g n
collaboration diagrams

Design Model
 Software Design Process

The design phase of software development deals with transforming the

customer requirements as described in the SRS documents into a
form implementable using a programming language.
The software design process can be divided into the following three levels of
phases of design:
1. Interface Design
2. Architectural Design
3. Detailed Design
Software Design Process
 Interface Design:

• Interface design is the specification of the interaction between a system and its
environment.
• This phase proceeds at a high level of abstraction with respect to the inner
workings of the system i.e, during interface design, the internal of the systems
are completely ignored and the system is treated as a black box.
• Attention is focused on the dialogue between the target system and the users,
devices, and other systems with which it interacts.
 Interface Design:
• The design problem statement produced during the problem analysis step should identify
the people, other systems, and devices which are collectively called agents.
• Interface design should include the following details:
• Precise description of events in the environment, or messages from agents to which the
system must respond.
• Precise description of the events or messages that the system must produce.
• Specification on the data, and the formats of the data coming into and going out of the
system.
• Specification of the ordering and timing relationships between incoming events or
messages, and outgoing events or outputs.
 Architectural Design:
• Architectural design is the specification of the major components of a system, their
responsibilities, properties, interfaces, and the relationships and interactions between
them.
• In architectural design, the overall structure of the system is chosen, but the internal
details of major components are ignored.
 Detailed Design:
• Design is the specification of the internal elements of all major system components, their
properties, relationships, processing, and often their algorithms and the data structures.
• The detailed design may include:
– Decomposition of major system components into program units.
– Allocation of functional responsibilities to units.
– User interfaces
– Unit states and state changes
– Data and control interaction between units
– Data packaging and implementation, including issues of scope and visibility of program
elements
– Algorithms and data structures
 Objectives of Software Design
• 1. Correctness: Software design should be correct as per requirement.
• 2. Completeness: The design should have all components like data structures, modules, and
external interfaces, etc.
• 3. Efficiency: Resources should be used efficiently by the program.
• 4. Flexibility: Able to modify on changing needs.
• 5. Consistency: There should not be any inconsistency in the design.
• 6. Maintainability: The design should be so simple so that it can be easily maintainable by
other designers.
 Objectives of Software Design
• 1. Correctness: Software design should be correct as per requirement.
• 2. Completeness: The design should have all components like data structures, modules, and
external interfaces, etc.
• 3. Efficiency: Resources should be used efficiently by the program.
• 4. Flexibility: Able to modify on changing needs.
• 5. Consistency: There should not be any inconsistency in the design.
• 6. Maintainability: The design should be so simple so that it can be easily maintainable by
other designers.
UI Design

Image source : Google

 Interface Design

Easy to learn?
Easy to use?
Easy to understand?
 Interface Design
Typical Design
Errors
• lack of consistency
• too much memorization
• no guidance / help
• no context sensitivity
• poor response
• Unfriendly
User Interface Design Process
 Interface Analysis

Interface analysis 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.
 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?

 Task Analysis and Modeling (Cont.)

To answer these questions, many techniques are discussed, but in

this instance, these techniques are applied to the user interface.
Use-cases define basic interaction
Task elaboration refines interactive tasks
Object elaboration identifies interface objects (classes)
Workflow analysis defines how a work process is completed when several
people (and roles) are involved
 User Interface Design Patterns: Design Issues

• Response time

• Help facilities

• Error handling

• Menu and command labeling

• Application accessibility
 Mapping User Objectives
Menu bar
major functions

List of user object ives

graphic, logo, and company name
object ive #1
object ive #2
object ive #3
object ive #4
object ive #5
graphic

object ive #n

Home page text copy

Navigation
menu
Architectural Design – Software Engineering
• The software needs an architectural design to represent the design of the
software. IEEE defines architectural design as
“the process of defining a collection of hardware and software
components and their interfaces to establish the framework for the development of
a computer system.”
• The software that is built for computer-based systems can exhibit one of these
many architectural styles.
Need of Architecture?
The architecture is not the operational software. Rather, it is a representation that
enables a software engineer to:

(1) analyze the effectiveness of the design in meeting its stated requirements,

(2) consider architectural alternatives at a stage when making design changes is

still relatively easy, and

(3) reduce the risks associated with the construction of the software.
Architectural Design – Software Engineering
• System Category Consists of
– A set of components(eg: a database, computational modules) that will
perform a function required by the system.
– The set of connectors will help in coordination, communication, and
cooperation between the components.
– Conditions that how components can be integrated to form the system.
– Semantic models that help the designer to understand the overall
properties of the system.
Architectural Styles
Each style describes a system category that encompasses:

(1) A set of components (e.G., A database, computational modules) that perform a

function required by a system,

(2) A set of connectors that enable “communication, coordination and cooperation”

among components,

(3) Constraints that define how components can be integrated to form the system, and

(4) Semantic models that enable a designer to understand the overall properties of a
system by analyzing the known properties of its constituent parts.
 Various Architectures
• Data-centered architectures
• Data flow architectures
• Call and return architectures
• Object-oriented architectures
• Layered architectures
Data centered architectures:
• A data store will reside at the center of this architecture and is accessed
frequently by the other components that update, add, delete, or modify the
data present within the store.
• The figure illustrates a typical data-centered style.
• The client software accesses a central repository. Variations of this approach are
used to transform the repository into a blackboard when data related to the client
or data of interest for the client change the notifications to client software.
Data-Centered Architecture
Data centered architectures:
• 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.
• Data can be passed among clients using the blackboard mechanism.
Data centered architectures:
• Advantages of Data centered architecture:
– Repository of data is independent of clients
– Client work independent of each other
– It may be simple to add additional clients.
– Modification can be very easy
Data flow architectures:
• This kind of architecture is used when
input data is 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
lines.
Data flow architectures:
• Pipes are used to transmitting data from one component to the next.
• Each filter will work independently and is designed to take data input of a certain
form and produces data output to the next filter of a specified form.
• The filters don’t require any knowledge of the working of neighboring filters.

• Advantages of Data Flow architecture:

– It promotes maintenance, reuse, and adaptability.
– With this design, concurrent execution is supported.
Data flow architectures:
• Disadvantage of Data Flow architecture:
– Data flow architecture does not allow applications that require greater user
engagement.
– It is not easy to coordinate two different but related streams
Call and Return architectures
• It is used to create a program that is easy to scale and modify.
• Remote procedure call architecture: This components is used to present in a main
program or sub program architecture distributed among multiple computers on a
network.
• Main program or Subprogram architectures: The main program structure
decomposes into number of subprograms or function into a control hierarchy.
Main program contains number of subprograms that can invoke other
components.
Call and Return architectures
Object Oriented architecture
• The components of a system encapsulate data and the operations that must be
applied to manipulate the data.
• The coordination and communication between the components are established
via the message passing.
• It enables the designer to separate a challenge into a collection of autonomous
objects.
Layered architecture
• A number of different layers are defined with each layer performing a well-
defined set of operations.
• At the outer layer, components will receive the user interface operations and 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.
• One common example of this architectural style is OSI-ISO (Open Systems
Interconnection-International Organization for Standardization) communication
system.
Layered Architecture
Architecture Patterns
• Software architecture is like the blueprint for building software, showing how
different parts fit together and interact.
• It helps the development team understand how to build the software according
to customer requirements.
• There are many ways to organize these parts, called software architecture
patterns.
• These patterns have been tested and proven to solve different problems by
arranging components in specific ways.
Architecture Patterns
• 1. Layered Architecture Pattern
• 2. Client-Server Architecture Pattern
• 3. Event-Driven Architecture Pattern
• 4. Microkernel Architecture Pattern
• 5. Microservices Architecture Pattern
• 6. MVC Architecture Pattern
• 7. Master-Slave Architecture Pattern
• 8. Pipe-Filter Architecture Pattern
• 9. Broker Architecture Pattern
• 10. Peer-to-Peer Architecture Pattern
Layered Architecture Pattern
• SUBTASKS: each layer provides services to the next higher layer.
• Basic Layers:
• - Presentation layer (UI layer)
• - Application layer (service layer)
• - Business logic layer (domain layer)
• - Data access layer (persistence layer)
Client-Server Architecture Pattern
• Server provides services to
different clients as per their
requests.
• Examples: Email, Document
Sharing, Banking etc.
Event-Driven (Event-Bus) Architecture Pattern
• Events
• - Event Source
• - Event Listener
• - Channel
• - Event Bus

• Listeners are notified of messages that are

published to a channel to which they have
subscribed before.

• Example: Building Notification services in

Android
Peer to peer Architecture Pattern
• Peers
• Client - requesting services from other peers
• Server - providing services to other peers

• Example: file-sharing networks, multimedia protocols & various blockchain-

based products
Model-View-Controller (MVC) Pattern
• model - contains the core functionality and data
• view - displays the information to the user(more than one view may be defined)
• controller - handles the input from the user
Architectural Genres
• Genres implies a specific category within the overall software domain.
• Within each category, you encounter a number of subcategories.
• For example, within the genre of buildings, you would encounter the
following general styles: houses, commercial, apartment buildings, office
buildings, industrial building, warehouses, and so on.
• Within each general style, more specific styles might apply. Each style
would have a structure that can be described using a set of predictable
patterns.
Coupling and Cohesion
• Coupling refers to the degree of interdependence between software
modules.
• High coupling means that modules are closely connected and changes in
one module may affect other modules.
• Low coupling means that modules are independent, and changes in one
module have little impact on other modules.
Coupling and Cohesion
• Cohesion refers to the degree to which elements within a module work
together to fulfill a single, well-defined purpose.
• High cohesion means that elements are closely related and focused on a
single purpose, while low cohesion means that elements are loosely
related and serve multiple purposes.
Coupling and Cohesion
Coupling and Cohesion
• Both coupling and cohesion are important factors in determining the
maintainability, scalability, and reliability of a software system.

• High coupling and low cohesion can make a system difficult to change
and test,
• while low coupling and high cohesion make a system easier to maintain
and improve.
Coupling Types
• Data Coupling: If the dependency between the
modules is based on the fact that they
communicate by passing only data, then the
modules are said to be data coupled. In data
coupling, the components are independent of
each other and communicate through data.
Module communications don’t contain tramp
data. Example-customer billing system.
Coupling Types
• Data Coupling: If the dependency between the modules is
based on the fact that they communicate by passing only data,
then the modules are said to be data coupled. In data coupling,
the components are independent of each other and
communicate through data. Module communications don’t
contain tramp data. Example-customer billing system.
Coupling Types
• Stamp Coupling In stamp coupling, the complete data
structure is passed from one module to another module.
• Control Coupling: If the modules communicate by passing
control information, then they are said to be control coupled.
• External Coupling: In external coupling, the modules depend
on other modules, external to the software being developed or
to a particular type of hardware. Ex- protocol, external file,
device format, etc.
Coupling Types
• Common Coupling: The modules have shared data such as
global data structures. The changes in global data mean
tracing back to all modules which access that data to evaluate
the effect of the change.
• So it has got disadvantages like difficulty in reusing modules,
reduced ability to control data accesses, and reduced
maintainability.
Coupling Types
• Content Coupling: In a content coupling, one module can
modify the data of another module, or control flow is passed
from one module to the other module.
• This is the worst form of coupling and should be avoided.
Cohesion Types
• Functional Cohesion: Every essential
element for a single computation is
contained in the component.
• A functional cohesion performs the task
and functions. It is an ideal situation.
Cohesion Types
• Sequential Cohesion: An element outputs some data that
becomes the input for other element, i.e., data flow between
the parts.
• It occurs naturally in functional programming languages.
Cohesion Types
• Communicational Cohesion: Two elements operate on the
same input data or contribute towards the same output data.
• Update record in the database and send it to the printer.
• Procedural Cohesion: Elements of procedural cohesion ensure
the order of execution. Actions are still weakly connected and
unlikely to be reusable. Ex- calculate student GPA, print student
record, calculate cumulative GPA, print cumulative GPA.
Cohesion Types
• Temporal Cohesion: The elements are related by their timing
involved.
• A module connected with temporal cohesion all the tasks must
be executed in the same time span.
• This cohesion contains the code for initializing all the parts of
the system. Lots of different activities occur, all at unit time.
Cohesion Types
• Logical Cohesion: The elements are logically related and not
functionally. Ex- A component reads inputs from tape, disk, and
network. All the code for these functions is in the same
component. Operations are related, but the functions are
significantly different.
Cohesion Types
• Coincidental Cohesion: The elements are not
related(unrelated).
• The elements have no conceptual relationship other than
location in source code. It is accidental and the worst form of
cohesion.
Cohesion Types
• Procedural Cohesion: This type of cohesion occurs when
elements or tasks are grouped together in a module based on
their sequence of execution, such as a module that performs a
set of related procedures in a specific order.
• Procedural cohesion can be found in structured programming
languages.
Various Approaches of Partitioning
• If the system is having hierarchical architecture, the program
structure can easily be partitioned both horizontally and
vertically, figure (a), represents this view.
Various Approaches of Partitioning
• In given figure, horizontal
division defines the
individual branches of the
modular hierarchy for
every major program
function.
Various Approaches of Partitioning
• Control modular (shown by
rectangles) are used to
coordinate communication
between tasks. The three
partitions are done in simple
horizontal partitions i.e.,
input, data transformation
(processing) and output.
Various Approaches of Partitioning
The following benefits are provided by horizontal partitioning –

– Software, that can easily be tested.

– Software, that can easily be maintained.
– Propagation of fewer side effects.
– Software, that can easily be extended.
Various Approaches of Partitioning
• On the other hand, vertical
segmentation, also known as
“factoring”, states that control and
function must be distributed across
the program structure, top to bottom.
Various Approaches of Partitioning
• The top-level modules have to carry
out control functions and perform
fewer modules in the structure are
laborious, performing all input,
processing and output tasks.
Component Level Design
• Component level design is the definition and design of
components and modules after the architectural design phase.
• Component-level design defines the data structures,
algorithms, interface characteristics, and communication
mechanisms allocated to each component for the system
development.
Component Level Design
• A complete set of software components is defined during
architectural design.
• But the internal data structures and processing details of each
component are not represented at a level of abstraction that
is close to code.
Component Views
• OO View – A component is a set of collaborating classes.
• Conventional View – A component is a functional element of a
program that incorporates processing logic, the internal data
structures required to implement the processing logic, and an
interface that enables the component to be invoked and data
to be passed to it.
CLASS ELABORATION
• Class elaboration focuses on providing a detailed description of
attributes, interfaces and methods before the development of
the system activities.
• The following example provides a elaboration design class for
“PrintJob”, the elaborated design class provides a detail
description of the attributes, interfaces and the operations of
the class.
 Architectural Context
Safehome Internet-based
Product system

control
panel target system: surveillance
Security Fun ction function
uses
homeowner peers
uses

uses

sensors sensors
Component Structure
SafeHome
Execut ive

Funct ion
select ion

Ext ernal
Communicat ion
Management

Securit y Surveillance Home

management

GUI Int ernet

Int erface

Cont r ol det ect or alar m

panel management pr ocessing
pr ocessing
Refined Component Structure
Saf eHo me
Execut ive

Ext er nal
Communic at ion
Management

Securit y

GUI Int ernet

Int erf ace

Co n t ro l d e t e ct o r alarm
p an e l m an ag e m e n t p ro ce ssin g
p ro ce ssin g

Ke y p ad
p ro ce ssin g phone
sch e d u le r
co m m u n icat io n

CP d isp lay
fu n ct io n s
alarm

sen
se nso
sorr
se
se
se nn so
so rr
se
se nnsosorr
se nn so
so rr
se n so r
CLASS ELABORATION
CBSE Activities
• Component-Based Software Engineering (CBSE) is a process
that focuses on the design and development of computer-
based systems with the use of reusable software components.
• It not only identifies candidate components but also qualifies
each component’s interface, adapts components to remove
architectural mismatches, assembles components into a
selected architectural style, and updates components as
requirements for the system change.
Component-based development:
• Component-based development (CBD) is a CBSE activity that
occurs in parallel with domain engineering.
• Using analysis and architectural design methods, the software
team refines an architectural style that is appropriate for the
analysis model created for the application to be built.
CBSE Framework Activities:
• Component Qualification: This activity ensures that the system
architecture defines the requirements of the components for
becoming a reusable components. Reusable components are
generally identified through the traits in their interfaces. It
means “the services that are given and the means by which
customers or consumers access these services ” are defined as
a part of the component interface.
CBSE Framework Activities:
• Component Adaptation: This activity ensures that the
architecture defines the design conditions for all components
and identifies their modes of connection. In some cases,
existing reusable components may not be allowed to get used
due to the architecture’s design rules and conditions. These
components should adapt and meet the requirements of the
architecture or be refused and replaced by other, more
suitable components.
CBSE Framework Activities:
• Component Composition: This activity ensures that the
Architectural style of the system integrates the software
components and forms a working system.
• By identifying the connection and coordination mechanisms of
the system, the architecture describes the composition of the
end product.
CBSE Framework Activities:
• Component Update: This activity ensures the updation of
reusable components.
• Sometimes, updates are complicated due to the inclusion of
third-party (the organization that developed the reusable
component may be outside the immediate control of the
software engineering organization accessing the component
currently).
OO Design Concepts
• Object-Oriented Analysis and Design (OOAD) is a software
engineering methodology that employs object-oriented
principles to model and design complex systems.
• It involves analyzing the problem domain, representing it using
objects and their interactions, and then designing a modular
and scalable solution. It helps create systems that are easier to
understand, maintain, and extend by organizing functionality
into reusable and interconnected components.
 Important Aspects of OOAD
• Object-Oriented Programming: Object-oriented programming
involves modeling real-world objects as software objects, with
properties and methods that represent the behavior of those
objects. OOAD uses this approach to design and implement software
systems.
• Design Patterns: Design patterns are reusable solutions to common
problems in software design. OOAD uses design patterns to help
developers create more maintainable and efficient software systems.
 Important Aspects of OOAD
• UML Diagrams: Unified Modeling Language (UML) is a standardized
notation for creating diagrams that represent different aspects of a
software system.
• OOAD uses UML diagrams to represent the different components
and interactions of a software system.
 What is UML?
• Unified Modeling Language (UML) is a standardized visual modeling
language used in the field of software engineering to provide a
general-purpose, developmental, and intuitive way to visualize the
design of a system.
• UML helps in specifying, visualizing, constructing, and documenting
the artifacts of software systems.
 What is UML?
• We use UML diagrams to portray the behavior and structure of a
system.
• UML helps software engineers, businessmen, and system architects
with modeling, design, and analysis.
Different Types of UML Diagrams
 Class Diagram
• The most widely use UML diagram is the class diagram.
• It is the building block of all object oriented software systems.
• We use class diagrams to depict the static structure of a system by
showing system’s classes, their methods and attributes.
• Class diagrams also help us identify relationship between different
classes or objects.
Class Diagram
 Composite Structure Diagram
• It represents the internal structure of a class and its interaction points
with other parts of the system.

• It also represents relationship between parts and their configuration

which determine how the classifier (class, a component, or a
deployment node) behaves.
• They represent internal structure of a structured classifier making
the use of parts, ports, and connectors.
Composite Structure Diagram
 Object Diagram
• It is referred to as a screenshot of the instances in a system and the
relationship that exists between them.
• An object diagram is similar to a class diagram except it shows the
instances of classes in the system.
• We depict actual classifiers and their relationships making the use
of class diagrams.
• On the other hand, an Object Diagram represents specific instances
of classes and relationships between them at a point of time.
Object Diagram
 Component Diagram
• It is used to represent how the physical components in a system
have been organized. We use them for modelling implementation
details.
• Component Diagrams depict the structural relationship between
software system elements and help us in understanding if
functional requirements have been covered by planned
development.
• Component Diagrams become essential to use when we design and
build complex systems.
• Interfaces are used by components of the system to communicate
with each other.
Component Diagram
 Deployment Diagram
• It is used to represent system hardware and its software.
• It tells us what hardware components exist and what software
components run on them.

• We illustrate system architecture as distribution of software artifacts

over distributed targets.
• An artifact is the information that is generated by system software.
• They are primarily used when a software is being used, distributed or
deployed over multiple machines with different configurations.
Deployment Diagram
 State Machine Diagrams
• State diagrams are also referred to as State machines and State-chart
Diagrams.
• These terms are often used interchangeably. So simply, a state
diagram is used to model the dynamic behavior of a class in
response to time and changing external stimuli.
 State Machine Diagrams
• State diagrams are also referred to as State machines and State-chart
Diagrams.
• These terms are often used interchangeably. So simply, a state
diagram is used to model the dynamic behavior of a class in
response to time and changing external stimuli.
 Use Case Diagrams
• Use Case Diagrams are used to depict the functionality of a system
or a part of a system.
• They are widely used to illustrate the functional requirements of the
system and its interaction with external agents(actors).

• A use case diagram gives us a high level view of what the system or a
part of the system does without going into implementation details.
Use Case Diagrams
 Activity Diagrams
• We use Activity Diagrams to illustrate the flow of control in a system.
• We can also use an activity diagram to refer to the steps involved in
the execution of a use case.
• We basically depict workflows visually using an activity diagram.
• An activity diagram focuses on condition of flow and the sequence in
which it happens.
• We describe or depict what causes a particular event using an
activity diagram.
Activity Diagrams
 Sequence Diagram
• A sequence diagram simply depicts interaction between objects in a
sequential order i.e. the order in which these interactions take
place.
• We can also use the terms event diagrams or event scenarios to
refer to a sequence diagram.
• Sequence diagrams describe how and in what order the objects in a
system function.
• These diagrams are widely used by businessmen and software
developers to document and understand requirements for new and
existing systems.
Sequence Diagram
 Important Aspects of OOAD
• Use Cases: Use cases are a way of describing the different ways in
which users interact with a software system.
• OOAD uses use cases to help developers understand the
requirements of a system and to design software systems that meet
those requirements.
OOAD
 Design Classes

Analysis classes are refined during design to become

entity classes
• Boundary classes are developed during design to create the
interface (e.g., Interactive screen or printed reports) that the user

sees and interacts with as the software is used.

Boundary classes are designed with the responsibility of
managing the way entity objects are represented to users.
 Design Classes (Cont.)

• Controller classes are designed to manage

The creation or update of entity objects;
the instantiation of boundary objects as they obtain information
from entity objects;
complex communication between sets of objects;
validation of data communicated between objects or between
the user and the application.
Interface Elements
 Component-Level Design Elements
The component-level design for software is the equivalent to a set of
detailed drawings (and specifications) for each room in a house.

The component-level design for software fully describes the internal

detail of each software component.

To accomplish this, the component-level design defines data structures

for all local data objects and algorithmic detail for all processing.
 Component Elements

SensorManagement
Sensor
 Deployment Elements

Deployment-level design elements indicate how software

functionality and subsystems will be allocated within the physical
computing environment that will support the software.
Deployment Elements (Cont.)
Data Oriented Analysis & Design
Difference between Data
and Information, E-R
Diagram, Dataflow
Model, Control Flow
Model, Control and
Process Specification,
Data Dictionary

Image source : Google

Data
Information
Data & Information
 E-R Model

• It is the most conceptual model used for designing a database.

• Proposed by Dr. Peter Chen in 1960
• E-R model views the real world as a set of basic objects (entities) ,
their characteristics (attributes) and associations among objects
(relationship).
• Entities , Attributes & relationship are the basic concept of an E-R
model.
 Entity
An entity is an object that exists and is distinguishable from other objects.
Example: specific person, company, event, plant
Entities have attributes
Example: people have names and addresses
An entity set is a set of entities of the same type that share the same
properties.
Example: set of all persons, companies, trees, holidays
 E-R Diagrams

Rectangles represent entity sets.

Diamonds represent relationship sets.
Lines link attributes to entity sets and entity sets to relationship sets.
Ellipses represent attributes
Double ellipses represent multivalued attributes.
E-R Diagram Notations
E-R Diagram With Composite, Multivalued, and Derived Attributes
Relationship Sets with Attributes
E-R Diagram with a Ternary Relationship
 Cardinality Constraints

We express cardinality constraints by drawing either a directed line (→),

signifying “one,” or an undirected line (—), signifying “many,” between the
relationship set and the entity set.
 One-to-one relationship:
 A customer is associated with at most one loan via the relationship
borrower
 A loan is associated with at most one customer via borrower
 One-To-Many Relationship

In the one-to-many relationship a loan is associated with at most one

customer via borrower, a customer is associated with several (including 0)
loans via borrower
 Many-To-One Relationships

In a many-to-one relationship a loan is associated with several (including 0)

customers via borrower, a customer is associated with at most one loan via
borrower
 Many-To-Many Relationship

A customer is associated with several (possibly 0) loans via borrower

A loan is associated with several (possibly 0) customers via borrower
E-R Diagram with a Ternary Relationship
 Cont...
• Extended E-R features
• Specialization
• Generalization
• Aggregation
 Specialization

Top-down design process; we designate subgroupings within an entity set

that are distinctive from other entities in the set.

These subgroupings become lower-level entity sets that have attributes or

participate in relationships that do not apply to the higher-level entity set.
 Ex. Entity type BOOK can be further classified into three types.
TEXTBOOK, LANGUAGE_BOOK and NOVEL.

Local or Specific Attribute- some additional set of that differentiate them from
each other.
 TEXTBOOK may have additional attribute Subject( computer , maths ,
science ctc
Cont....
 Generalization

• A bottom-up design process – combine a number of entity sets that

share the same features into a higher-level entity set.
• DBD may first identify entity type TEXTBOOK, LANG_BOOK,
NOVEL then combine the common attribute to form BOOK.
• Specialization and generalization are simple inversions of each other;
they are represented in an E-R diagram in the same way.
• The terms specialization and generalization are used interchangeably
Cont....
Flow Modeling Notation

external entity

process

data flow

data store
 External Entity

A producer or consumer of data

Examples: a person, a device, a sensor

Another example: computer-based
system
Data must always originate somewhere
and must always be sent to something
 Process

A data transformer (changes input

to output)

Examples: compute taxes, determine area,

format report, display graph

Data must always be processed in some

way to achieve system function
 Data Flow

Data flows through a system, beginning

as input and transformed into output.

base
compute
area
triangle
height area
 Data Stores

Data is often stored for later use.

sensor # sensor #, type,

look-up
sensor
location, age
report required data
type,
sensor number location, age
sensor data
 Data Flow Diagramming: Guidelines

• All icons must be labeled with meaningful names

• The DFD evolves through a number of levels of detail

• Always begin with a context level diagram (also called level 0)

• Always show external entities at level 0

• Always label data flow arrows

• Do not represent procedural logic

 Constructing a DFD—I

•Review user scenarios and/or the data model to isolate data objects and use a
grammatical parse to determine “operations”

•Determine external entities (producers and consumers of data)

•Create a level 0 DFD

 Level 0 DFD Example

Processing
User request Requested
video
Digital signal
video Monitor
processor
Video
source NTSC
video signal
 Constructing a DFD—II

•Write a narrative describing the transform

•Parse to determine next level transforms

•“Balance” the flow to maintain data flow continuity

•Develop a level 1 DFD

•Use a 1:5 (approx.) Expansion ratio

 The Data Flow Hierarchy

a b
x P y level 0

c p2
a f
p1

p4 b
d 5
p3 e g
level 1
 Data Dictionary

•The data dictionary is a reference work of data about data (that is,
metadata), one that is compiled by systems analysts to guide them through
analysis and design.

•Data flow diagrams are an excellent starting point for collecting data
dictionary entries.
 Data Dictionary (Cont.)

Data Dictionary may be used to also:

•Validate the data flow diagram for completeness and accuracy.

•Provide a stating point for developing screens and reports.

•Determine the contents of data stored in files.

•Develop the logic for data-flow diagram processes.

 Data Dictionary Example

• Table name: scheme1_master

Primary key: schemeid

Foreign key: null

• References:
 Data Dictionary Example

FIELDNAME DATATYPE SIZE CONSTRAINT DESCRIPTION

Schemeid Varchar2 20 Primary key Stores the id of scheme

Stores the total time provided by

Time Number 10
scheme (in hours)
Stores the total days for expiring
Days Number 10
the scheme
Stores the amount for the
Rupees Number 4
schemes
www.paruluniversity.ac.in