SlideShare a Scribd company logo
Software Design
INTRO
 Goal is to produce a model or repesentation
 Designer should
 Stock all material of design like components, component solutions &
knowledge
 Choose elements from stock that meet requirements
 Alternatives are also considered & accepted/rejected for final
confirmation
Design Process
 To achieve intended goal of software – successful
implementation
 Always refers to finding solution or problem solving
 Includes algorithms, diagrams, formulae designs, low level
design etc.
 Follow semi standard methods like UML for modelling the
software
 Use different diagrams like activity, use case and sequence
 Use of design patterns and architectural guides (if required)
Design Concepts
 Abstraction
 For modular solution many level of abstraction is possible
 High level solution – solution stated in the language of the problem
environment
 lower levels of abstraction - used for detailed description
 data abstraction is actually a collection of data that describes a data
object
 Architecture
 Software architecture is the complete structure or
arrangement of the program components in such a way that
they interact with each other
 data structures may be used by these components
 these components are the building blocks of the overall
structure of the application being developed
 architectural design can be represented using one or more of a
number of different models
 Patterns
 a design pattern describes a design structure that solves a
particular design problem within a specific context
 Modularity
 consists of software architecture and design patterns
 defined as the modularization of a single attribute (main
module) of software into number of small parts (smaller
modules) such that these parts can be easily managed
 Consider
 C(x) – function of a problem x that define its complexity
 E(X) - function of a problem x that define efforts required to solve
that problem
 Let there are two problems p1 and p2 for which,
If C(p1) > C(p2) then E(p1) > E(p2)
 interesting characteristic is uncovered through observations
and experimentation
C(p1 + p2) > C(p1) + C(p2)
 complexity of two combined problems p1 and p2 is greater than
the complexity when the problems are considered separately
 From previous equations it follows,
E(p1 + p2) > E(p1) + E(p2)
 That leads to a strategy called divide and conquer
 always easy to solve a complex problem when it is divided in
small sub-problems that are easily manageable
 the effort (cost) to develop an
individual software module does
decrease as the total number of
modules increases
 For large size problem, the
number of modules will be
increased and the effort (cost)
associated with integrating the
modules also increases
• M is number of modules that would result in minimum development
cost, but there is no any proper and sophisticated method to predict M
• divide the problem into modules, but utmost care must be taken to stay in
the region of M
 five criteria defined for an effective modular system
 Modular decomposability : complex problem may be solved very
easily by decomposing into smaller sub problems
 Modular composability : Different modules and components are
integrated to produce a new system
 Modular understandability : While integrating a system, if each of the
individual modules or components are understood well, then it become
very easy to build the system once again
 Modular continuity : to minimize side effect of changes it’s always
better to make changes module-wise instead of making changes system-
wise
 Modular protection : for any abnormal condition within a module,
the effects are within that module only. Thus the side effects are
minimized and problems will not spread outside that module
 Information Hiding
 modules of the larger problem must be specified and designed
properly so that information (i.e. algorithms and data) present within
a module is not available to other modules that do not require such
information
 To achieve effective modularity that have proper necessary
communication among modules
 Refinement
 uses a top-down strategy
 the procedural details of a program are refined in various levels
 hierarchy is generated by modularizing the statements of a program
 Functional Independence
 Its a type of modularity and related to the concepts of
abstraction and information hiding
 In this, each module addresses a specific sub function of
requirements and has a simple interface
 Independence is assessed by two criteria
 Cohesion : a relative functional strength of a module
 Coupling : relative interdependence among modules
 Cohesion
 extension of the concept of information hiding
 a module performs only one task within a software procedure (or
required only little interaction with other procedures of the software)
 module that performs different tasks that are loosely related to each
other are termed as coincidentally cohesive
 module that performs tasks that are related logically is logically
cohesive
 When a module contains tasks that are related by the fact that all must
be executed with the same span of time, the module exhibits temporal
cohesion
 Procedural cohesion exists when processing elements of a module are
related and are executed in a specific order
 When all the processing elements do concentrate on only one area of a
data structure, then communicational cohesion is available
 High-end cohesion is characterized by a module that performs one
single and unique procedural task
 Coupling
 is a measure of inter-relationship among various modules in a software
structure
 always depends on the interface complexity among modules
 to make bit easy to understand, connectivity between different modules
of software is made simple by minimum possible coupling
 Simple connectivity  avoid “Ripple Effect” - (errors occurring at one
particular location in the system and propagating through a system)
 Types of Coupling
 Low data coupling (a – c)
 Data passed
 Stamp coupling (a - b)
 Data Structure passed
 Control Coupling (d - e)
 Control flag passed
 High level of coupling
(external coupling)
 Modules tied to external environments
 High (common) Coupling (c – g – k )
 Modules refer a global data area
 Refactoring
 reorganization technique that simplifies the design (or code) of a
component without changing its function or behavior
 it does not alter the external behavior of the code [design] yet improves
its internal structure
 Importance
 To improve quality of software
 Improving the quality of the code, working becomes easier  addition of new
code and maintenance of the code becomes easy
 Improves the code over the period of time
 Play important role in splitting long functions into reasonably small sub
functions
 Helps in creating reusable codes
 Error handling is much easier and within control
 Design Classes
 Each of the software team should define a set of design classes
 Classes should describe the elements of problem domain and that should focus
the customer requirement
 It should,
 Refine the analysis classes that are implemented
 Create a new set of design classes that must support the business solutions
Design Principles
 s/w design must be in such a way that the system is easily
traceable to the analysis model
 software design must not reinvent the wheel (i.e. repetition of the
same tasks), since the time is limited and the resources are also
limited, the design should use the existing ideas and patterns
 design must be in such a way that it minimizes the intellectual
distance between the application or the system and the related
problems
 design must demonstrate uniformity and integration of different
components to their interfaces
 design structure must be flexible to accommodate
modification
 design must withstand against abnormal data, abnormal
events and abnormal operating conditions
 design should not be the coding, and coding should not be the
design
 design should be able to evaluate the quality
 design must be reviewed to minimize the conceptual errors
Architectural Design
 architecture of a program or computing system is actually the
structures of the system that consists of following attributes
 Software Components
 Externally visible property of s/w component
 Relationships among this components
 It’s a representation that enable s/w engineer to analyse,
 Analyse the effectivness of the design
 Consider architectural alternatives
 Reduce the associated risks
 Importance of architectural design
 enables communication between all stakeholders involved in the
development of the system
 emphasizes early design decisions that will have a deep influence on all
software engineering tasks (success mantra for the system)
 builds a small, intellectually model that will help the system to integrate
its component
Architectural Styles
 It explains the system category that consist of,
 set of components (i.e. a database or the computational modules) that
perform a function required by the system
 set of connectors used for communication, coordination, and
cooperation between the components
 constraints used to define the integration of various components into
system
 semantic models used to understand the overall properties of a system
with the help of analysis of its elements
Data Centered Architecture
 Data stored – accessed by various components of the system
 Access a central repository
 Independent of other component changes and update
Data Flow architectures
 When i/p data are to be transformed through series of computational components
to get o/p data
 Pipe and filter pattern  transmit data from one component to next
 Each filter designed to expect data i/p of certain form and produce o/p in specified
form
 Doesn’t require working knowledge of neighbouring filter
 Call & Return architecture
 Enables program structure that is easy to modify and scales
 No of sub style
 Main Program/Sub Program Arch. : decomposes function into control
hierarchy where main program invokes no of other components
 Remote Procedure Call Archi. : component of main program / subprogram
are distributed across multiple computers on n/w
 Object Oriented Architecture
 Component encapsulate data and operations
 Component communication happen via message passing
 Layered Archi.
 No of different layers are
defined having operations that
progressively become closer to
solution
 Other Architectures
 Publisher Subscriber Architecture
 Client Server Architecture
 Peer to Peer Architecture
 Event Based s/w Architecture
Component Level Design
 comes after architectural design is completed
 It’s an alternative approach to the architectural design approach
 Defines data structures, algorithms, interface characteristics & comm
mechanism
 Three different view of a component design
 Objet Oriented view (defines attributes and operations)
 ConventionalView (component with – processing logic + data Structures + interface)
 Process RelatedView (focus on the reusability of the existing software components)
Object OrientedView ConventionalView
User Interface Design
 Creates an effective communication between user and system
 Many factors are considered before designing UI
 Type of the user, age, education level, purpose of the s/w
 Provided at h/w as well as s/w level
 Need good understanding of user needs
 Types of UI - Command Interpreter & GUI
 Benefits of good UI
 Higher revenue
 Increased user efficiency and satisfaction
 Reduced development costs
 Reduced support costs
Design rules for UI
 Place the user in Control
 Define the interaction modes in such a way that the user is not forced
to perform unnecessary or undesired actions
 The interaction should be flexible
 User interaction should be interruptible and undoable
 The different levels of difficulty in interaction for different classes of
users must be customized
 Hide complexities from the casual user
 direct interaction with objects that appear on the screen
 Reduce the User’s Memory Load
 Reduce the demand for short-term memory
 Define shortcuts that can easily remembered
 Established meaningful defaults
 information should be disclosed in a progressive fashion
 Make the Interface Consistent
UI Design Models
 User Profile Model
 Novices (no syntactic but little semantic knowledge)
 Knowledgeable, intermittent users (low syntactic & reasonable semantic
knowledge)
 Knowledgeable, frequent users (Good Syntactic and semantic knowledge)
 Design Model
 Implementation Model
 User’s System Perception
Web Application Design
 WebApp Design involves technical and non technical acts like,
 Establishing look and feel of web app
 Great UI
 Defining overall architectural structure
 Developing content and functionality that resides within his architecture
 Planning the navigation that occurs within the WebApp
WebApp Design Quality Requirement
WebApp Interface Design
 Main objectives
 Establish a consistent
window into the content
an functionality that
provided by the interface
 Guide the user with series
of interactions with the
WebApp
 Organize the navigation
option and content
available to the user
 Aesthetic Design (graphic design)
 Is an artistic endeavour that complements technical aspects of
WebApp Design
 Content Design
 Focus on two different task (addressed by individuals)
 Design representation for content objects and relationship between
them developed
 Conducted by copywriters, graphic designers & others who generate
the content to be used within WebApp
 Architectural Design (in parallel with previous phase)
 Tied to the goals
 Content to be presented
 Users who visit the WebApp
 Navigation philosophy established within the WebApp
 Decisions made during this phase has strong influence on
Navigation Designing
 Navigation Design
 Define the navigation pathways that enable user to access
components and functions of the WebApp (pages, functions,
scripts and other pages)
 Component Level Design
 ModernWebApps deliver sophisticated processing functions
that perform
 localized processing (to generate content and navigation dynamically)
 Computation or data processing capability
 Provide sophisticated database query and access
 Establish data interface with external components
END

More Related Content

What's hot

Software architecture design ppt
Software architecture design pptSoftware architecture design ppt
Software architecture design ppt
farazimlak
 
unit 5 Architectural design
 unit 5 Architectural design unit 5 Architectural design
unit 5 Architectural design
devika g
 
Software design
Software designSoftware design
Software design
Benazir Fathima
 
Requirements Engineering
Requirements EngineeringRequirements Engineering
Requirements Engineering
Benoy Ramachandran
 
Functional vs Non-functional Requirements - Which comes first?
Functional vs Non-functional Requirements - Which comes first?Functional vs Non-functional Requirements - Which comes first?
Functional vs Non-functional Requirements - Which comes first?
Evgeniy Labunskiy
 
Software reliability
Software reliabilitySoftware reliability
Software reliability
Anand Kumar
 
Architectural structures and views
Architectural structures and viewsArchitectural structures and views
Architectural structures and views
Dr Reeja S R
 
Software Engineering- Requirement Elicitation and Specification
Software Engineering- Requirement Elicitation and SpecificationSoftware Engineering- Requirement Elicitation and Specification
Software Engineering- Requirement Elicitation and Specification
Nishu Rastogi
 
unit 3 Design 1
unit 3 Design 1unit 3 Design 1
unit 3 Design 1
TharuniDiddekunta
 
Phased life cycle model
Phased life cycle modelPhased life cycle model
Phased life cycle model
Stephennancy
 
Software requirement and specification
Software requirement and specificationSoftware requirement and specification
Software requirement and specification
Aman Adhikari
 
Requirement Analysis
Requirement AnalysisRequirement Analysis
Requirement Analysis
SADEED AMEEN
 
Chapter 1 2 - some size factors
Chapter 1   2 - some size factorsChapter 1   2 - some size factors
Chapter 1 2 - some size factors
NancyBeaulah_R
 
Software Process Models
Software Process ModelsSoftware Process Models
Software Process Models
Atul Karmyal
 
Context model
Context modelContext model
Context model
Ubaid423
 
Architectural Styles and Case Studies, Software architecture ,unit–2
Architectural Styles and Case Studies, Software architecture ,unit–2Architectural Styles and Case Studies, Software architecture ,unit–2
Architectural Styles and Case Studies, Software architecture ,unit–2
Sudarshan Dhondaley
 
Software evolution and maintenance
Software evolution and maintenanceSoftware evolution and maintenance
Software evolution and maintenance
Feliciano Colella
 
Software Engineering Methodologies
Software Engineering MethodologiesSoftware Engineering Methodologies
Software Engineering MethodologiesDamian T. Gordon
 
Designing Techniques in Software Engineering
Designing Techniques in Software EngineeringDesigning Techniques in Software Engineering
Designing Techniques in Software Engineering
kirupasuchi1996
 

What's hot (20)

Software architecture design ppt
Software architecture design pptSoftware architecture design ppt
Software architecture design ppt
 
unit 5 Architectural design
 unit 5 Architectural design unit 5 Architectural design
unit 5 Architectural design
 
Software design
Software designSoftware design
Software design
 
Requirements Engineering
Requirements EngineeringRequirements Engineering
Requirements Engineering
 
Functional vs Non-functional Requirements - Which comes first?
Functional vs Non-functional Requirements - Which comes first?Functional vs Non-functional Requirements - Which comes first?
Functional vs Non-functional Requirements - Which comes first?
 
Software reliability
Software reliabilitySoftware reliability
Software reliability
 
Architectural structures and views
Architectural structures and viewsArchitectural structures and views
Architectural structures and views
 
Software Engineering- Requirement Elicitation and Specification
Software Engineering- Requirement Elicitation and SpecificationSoftware Engineering- Requirement Elicitation and Specification
Software Engineering- Requirement Elicitation and Specification
 
unit 3 Design 1
unit 3 Design 1unit 3 Design 1
unit 3 Design 1
 
Phased life cycle model
Phased life cycle modelPhased life cycle model
Phased life cycle model
 
Software requirement and specification
Software requirement and specificationSoftware requirement and specification
Software requirement and specification
 
Requirement Analysis
Requirement AnalysisRequirement Analysis
Requirement Analysis
 
Chapter 1 2 - some size factors
Chapter 1   2 - some size factorsChapter 1   2 - some size factors
Chapter 1 2 - some size factors
 
Software design
Software designSoftware design
Software design
 
Software Process Models
Software Process ModelsSoftware Process Models
Software Process Models
 
Context model
Context modelContext model
Context model
 
Architectural Styles and Case Studies, Software architecture ,unit–2
Architectural Styles and Case Studies, Software architecture ,unit–2Architectural Styles and Case Studies, Software architecture ,unit–2
Architectural Styles and Case Studies, Software architecture ,unit–2
 
Software evolution and maintenance
Software evolution and maintenanceSoftware evolution and maintenance
Software evolution and maintenance
 
Software Engineering Methodologies
Software Engineering MethodologiesSoftware Engineering Methodologies
Software Engineering Methodologies
 
Designing Techniques in Software Engineering
Designing Techniques in Software EngineeringDesigning Techniques in Software Engineering
Designing Techniques in Software Engineering
 

Similar to Software Designing - Software Engineering

Function oriented design
Function oriented designFunction oriented design
Function oriented design
Vidhun T
 
Slides chapter 9
Slides chapter 9Slides chapter 9
Slides chapter 9
Priyanka Shetty
 
Design concepts and principles
Design concepts and principlesDesign concepts and principles
Design concepts and principlessaurabhshertukde
 
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvfUNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
puttipavan23022023
 
CS8494 SOFTWARE ENGINEERING Unit-3
CS8494 SOFTWARE ENGINEERING Unit-3CS8494 SOFTWARE ENGINEERING Unit-3
CS8494 SOFTWARE ENGINEERING Unit-3
SIMONTHOMAS S
 
6&8-Design.ppt
6&8-Design.ppt6&8-Design.ppt
6&8-Design.ppt
KomalSinghGill
 
Software design
Software designSoftware design
Software design
Inocentshuja Ahmad
 
11.3.14&22.1.16
11.3.14&22.1.1611.3.14&22.1.16
11.3.14&22.1.16
Rajes Wari
 
Software Design
Software Design Software Design
Software Design
Anas Bilal
 
Software design
Software designSoftware design
Software design
Zulqarnaintayyab
 
Design Engineering is a topic of software engineering of second year fourth s...
Design Engineering is a topic of software engineering of second year fourth s...Design Engineering is a topic of software engineering of second year fourth s...
Design Engineering is a topic of software engineering of second year fourth s...
38aartidhage
 
Software design i (2) (1)
Software design   i (2) (1)Software design   i (2) (1)
Software design i (2) (1)
Shagufta shaheen
 
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptx
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptxchapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptx
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptx
MahmoudZidan53
 
UNIT 3 SE.pptx
UNIT 3 SE.pptxUNIT 3 SE.pptx
UNIT 3 SE.pptx
rabiyathulbachiriyar
 
Unit-3.doc
Unit-3.docUnit-3.doc
Unit-3.doc
chitranshidheeraj6
 
Design final
Design finalDesign final
Design final
Indu Sharma Bhardwaj
 

Similar to Software Designing - Software Engineering (20)

Function oriented design
Function oriented designFunction oriented design
Function oriented design
 
Slides chapter 9
Slides chapter 9Slides chapter 9
Slides chapter 9
 
Design concepts and principles
Design concepts and principlesDesign concepts and principles
Design concepts and principles
 
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvfUNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
 
CS8494 SOFTWARE ENGINEERING Unit-3
CS8494 SOFTWARE ENGINEERING Unit-3CS8494 SOFTWARE ENGINEERING Unit-3
CS8494 SOFTWARE ENGINEERING Unit-3
 
6&8-Design.ppt
6&8-Design.ppt6&8-Design.ppt
6&8-Design.ppt
 
Software design
Software designSoftware design
Software design
 
11.3.14&22.1.16
11.3.14&22.1.1611.3.14&22.1.16
11.3.14&22.1.16
 
Software Design
Software Design Software Design
Software Design
 
06 fse design
06 fse design06 fse design
06 fse design
 
Software design
Software designSoftware design
Software design
 
Design Engineering is a topic of software engineering of second year fourth s...
Design Engineering is a topic of software engineering of second year fourth s...Design Engineering is a topic of software engineering of second year fourth s...
Design Engineering is a topic of software engineering of second year fourth s...
 
Design engineering
Design engineeringDesign engineering
Design engineering
 
Design engineering
Design engineeringDesign engineering
Design engineering
 
Software design i (2) (1)
Software design   i (2) (1)Software design   i (2) (1)
Software design i (2) (1)
 
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptx
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptxchapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptx
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptx
 
rEFUP.pdf
rEFUP.pdfrEFUP.pdf
rEFUP.pdf
 
UNIT 3 SE.pptx
UNIT 3 SE.pptxUNIT 3 SE.pptx
UNIT 3 SE.pptx
 
Unit-3.doc
Unit-3.docUnit-3.doc
Unit-3.doc
 
Design final
Design finalDesign final
Design final
 

More from Purvik Rana

Software Quality Assurance - Software Engineering
Software Quality Assurance - Software EngineeringSoftware Quality Assurance - Software Engineering
Software Quality Assurance - Software Engineering
Purvik Rana
 
Agile Methodology - Software Engineering
Agile Methodology - Software EngineeringAgile Methodology - Software Engineering
Agile Methodology - Software Engineering
Purvik Rana
 
Software Engineering - Basics
Software Engineering - BasicsSoftware Engineering - Basics
Software Engineering - Basics
Purvik Rana
 
OOPs Concepts - Android Programming
OOPs Concepts - Android ProgrammingOOPs Concepts - Android Programming
OOPs Concepts - Android Programming
Purvik Rana
 
Sql queries - Basics
Sql queries - BasicsSql queries - Basics
Sql queries - Basics
Purvik Rana
 
Android Workshop_1
Android Workshop_1Android Workshop_1
Android Workshop_1
Purvik Rana
 
File system in iOS
File system in iOSFile system in iOS
File system in iOSPurvik Rana
 

More from Purvik Rana (9)

Software Quality Assurance - Software Engineering
Software Quality Assurance - Software EngineeringSoftware Quality Assurance - Software Engineering
Software Quality Assurance - Software Engineering
 
Agile Methodology - Software Engineering
Agile Methodology - Software EngineeringAgile Methodology - Software Engineering
Agile Methodology - Software Engineering
 
Software Engineering - Basics
Software Engineering - BasicsSoftware Engineering - Basics
Software Engineering - Basics
 
OOPs Concepts - Android Programming
OOPs Concepts - Android ProgrammingOOPs Concepts - Android Programming
OOPs Concepts - Android Programming
 
Sql queries - Basics
Sql queries - BasicsSql queries - Basics
Sql queries - Basics
 
Android Workshop_1
Android Workshop_1Android Workshop_1
Android Workshop_1
 
Andriod_Intro
Andriod_IntroAndriod_Intro
Andriod_Intro
 
Apple bonjour
Apple bonjourApple bonjour
Apple bonjour
 
File system in iOS
File system in iOSFile system in iOS
File system in iOS
 

Recently uploaded

Synthetic Fiber Construction in lab .pptx
Synthetic Fiber Construction in lab .pptxSynthetic Fiber Construction in lab .pptx
Synthetic Fiber Construction in lab .pptx
Pavel ( NSTU)
 
Operation Blue Star - Saka Neela Tara
Operation Blue Star   -  Saka Neela TaraOperation Blue Star   -  Saka Neela Tara
Operation Blue Star - Saka Neela Tara
Balvir Singh
 
678020731-Sumas-y-Restas-Para-Colorear.pdf
678020731-Sumas-y-Restas-Para-Colorear.pdf678020731-Sumas-y-Restas-Para-Colorear.pdf
678020731-Sumas-y-Restas-Para-Colorear.pdf
CarlosHernanMontoyab2
 
How libraries can support authors with open access requirements for UKRI fund...
How libraries can support authors with open access requirements for UKRI fund...How libraries can support authors with open access requirements for UKRI fund...
How libraries can support authors with open access requirements for UKRI fund...
Jisc
 
The French Revolution Class 9 Study Material pdf free download
The French Revolution Class 9 Study Material pdf free downloadThe French Revolution Class 9 Study Material pdf free download
The French Revolution Class 9 Study Material pdf free download
Vivekanand Anglo Vedic Academy
 
Francesca Gottschalk - How can education support child empowerment.pptx
Francesca Gottschalk - How can education support child empowerment.pptxFrancesca Gottschalk - How can education support child empowerment.pptx
Francesca Gottschalk - How can education support child empowerment.pptx
EduSkills OECD
 
The approach at University of Liverpool.pptx
The approach at University of Liverpool.pptxThe approach at University of Liverpool.pptx
The approach at University of Liverpool.pptx
Jisc
 
Adversarial Attention Modeling for Multi-dimensional Emotion Regression.pdf
Adversarial Attention Modeling for Multi-dimensional Emotion Regression.pdfAdversarial Attention Modeling for Multi-dimensional Emotion Regression.pdf
Adversarial Attention Modeling for Multi-dimensional Emotion Regression.pdf
Po-Chuan Chen
 
Model Attribute Check Company Auto Property
Model Attribute  Check Company Auto PropertyModel Attribute  Check Company Auto Property
Model Attribute Check Company Auto Property
Celine George
 
Welcome to TechSoup New Member Orientation and Q&A (May 2024).pdf
Welcome to TechSoup   New Member Orientation and Q&A (May 2024).pdfWelcome to TechSoup   New Member Orientation and Q&A (May 2024).pdf
Welcome to TechSoup New Member Orientation and Q&A (May 2024).pdf
TechSoup
 
Instructions for Submissions thorugh G- Classroom.pptx
Instructions for Submissions thorugh G- Classroom.pptxInstructions for Submissions thorugh G- Classroom.pptx
Instructions for Submissions thorugh G- Classroom.pptx
Jheel Barad
 
The geography of Taylor Swift - some ideas
The geography of Taylor Swift - some ideasThe geography of Taylor Swift - some ideas
The geography of Taylor Swift - some ideas
GeoBlogs
 
special B.ed 2nd year old paper_20240531.pdf
special B.ed 2nd year old paper_20240531.pdfspecial B.ed 2nd year old paper_20240531.pdf
special B.ed 2nd year old paper_20240531.pdf
Special education needs
 
The Roman Empire A Historical Colossus.pdf
The Roman Empire A Historical Colossus.pdfThe Roman Empire A Historical Colossus.pdf
The Roman Empire A Historical Colossus.pdf
kaushalkr1407
 
Digital Tools and AI for Teaching Learning and Research
Digital Tools and AI for Teaching Learning and ResearchDigital Tools and AI for Teaching Learning and Research
Digital Tools and AI for Teaching Learning and Research
Vikramjit Singh
 
Chapter 3 - Islamic Banking Products and Services.pptx
Chapter 3 - Islamic Banking Products and Services.pptxChapter 3 - Islamic Banking Products and Services.pptx
Chapter 3 - Islamic Banking Products and Services.pptx
Mohd Adib Abd Muin, Senior Lecturer at Universiti Utara Malaysia
 
Guidance_and_Counselling.pdf B.Ed. 4th Semester
Guidance_and_Counselling.pdf B.Ed. 4th SemesterGuidance_and_Counselling.pdf B.Ed. 4th Semester
Guidance_and_Counselling.pdf B.Ed. 4th Semester
Atul Kumar Singh
 
1.4 modern child centered education - mahatma gandhi-2.pptx
1.4 modern child centered education - mahatma gandhi-2.pptx1.4 modern child centered education - mahatma gandhi-2.pptx
1.4 modern child centered education - mahatma gandhi-2.pptx
JosvitaDsouza2
 
Introduction to AI for Nonprofits with Tapp Network
Introduction to AI for Nonprofits with Tapp NetworkIntroduction to AI for Nonprofits with Tapp Network
Introduction to AI for Nonprofits with Tapp Network
TechSoup
 
CACJapan - GROUP Presentation 1- Wk 4.pdf
CACJapan - GROUP Presentation 1- Wk 4.pdfCACJapan - GROUP Presentation 1- Wk 4.pdf
CACJapan - GROUP Presentation 1- Wk 4.pdf
camakaiclarkmusic
 

Recently uploaded (20)

Synthetic Fiber Construction in lab .pptx
Synthetic Fiber Construction in lab .pptxSynthetic Fiber Construction in lab .pptx
Synthetic Fiber Construction in lab .pptx
 
Operation Blue Star - Saka Neela Tara
Operation Blue Star   -  Saka Neela TaraOperation Blue Star   -  Saka Neela Tara
Operation Blue Star - Saka Neela Tara
 
678020731-Sumas-y-Restas-Para-Colorear.pdf
678020731-Sumas-y-Restas-Para-Colorear.pdf678020731-Sumas-y-Restas-Para-Colorear.pdf
678020731-Sumas-y-Restas-Para-Colorear.pdf
 
How libraries can support authors with open access requirements for UKRI fund...
How libraries can support authors with open access requirements for UKRI fund...How libraries can support authors with open access requirements for UKRI fund...
How libraries can support authors with open access requirements for UKRI fund...
 
The French Revolution Class 9 Study Material pdf free download
The French Revolution Class 9 Study Material pdf free downloadThe French Revolution Class 9 Study Material pdf free download
The French Revolution Class 9 Study Material pdf free download
 
Francesca Gottschalk - How can education support child empowerment.pptx
Francesca Gottschalk - How can education support child empowerment.pptxFrancesca Gottschalk - How can education support child empowerment.pptx
Francesca Gottschalk - How can education support child empowerment.pptx
 
The approach at University of Liverpool.pptx
The approach at University of Liverpool.pptxThe approach at University of Liverpool.pptx
The approach at University of Liverpool.pptx
 
Adversarial Attention Modeling for Multi-dimensional Emotion Regression.pdf
Adversarial Attention Modeling for Multi-dimensional Emotion Regression.pdfAdversarial Attention Modeling for Multi-dimensional Emotion Regression.pdf
Adversarial Attention Modeling for Multi-dimensional Emotion Regression.pdf
 
Model Attribute Check Company Auto Property
Model Attribute  Check Company Auto PropertyModel Attribute  Check Company Auto Property
Model Attribute Check Company Auto Property
 
Welcome to TechSoup New Member Orientation and Q&A (May 2024).pdf
Welcome to TechSoup   New Member Orientation and Q&A (May 2024).pdfWelcome to TechSoup   New Member Orientation and Q&A (May 2024).pdf
Welcome to TechSoup New Member Orientation and Q&A (May 2024).pdf
 
Instructions for Submissions thorugh G- Classroom.pptx
Instructions for Submissions thorugh G- Classroom.pptxInstructions for Submissions thorugh G- Classroom.pptx
Instructions for Submissions thorugh G- Classroom.pptx
 
The geography of Taylor Swift - some ideas
The geography of Taylor Swift - some ideasThe geography of Taylor Swift - some ideas
The geography of Taylor Swift - some ideas
 
special B.ed 2nd year old paper_20240531.pdf
special B.ed 2nd year old paper_20240531.pdfspecial B.ed 2nd year old paper_20240531.pdf
special B.ed 2nd year old paper_20240531.pdf
 
The Roman Empire A Historical Colossus.pdf
The Roman Empire A Historical Colossus.pdfThe Roman Empire A Historical Colossus.pdf
The Roman Empire A Historical Colossus.pdf
 
Digital Tools and AI for Teaching Learning and Research
Digital Tools and AI for Teaching Learning and ResearchDigital Tools and AI for Teaching Learning and Research
Digital Tools and AI for Teaching Learning and Research
 
Chapter 3 - Islamic Banking Products and Services.pptx
Chapter 3 - Islamic Banking Products and Services.pptxChapter 3 - Islamic Banking Products and Services.pptx
Chapter 3 - Islamic Banking Products and Services.pptx
 
Guidance_and_Counselling.pdf B.Ed. 4th Semester
Guidance_and_Counselling.pdf B.Ed. 4th SemesterGuidance_and_Counselling.pdf B.Ed. 4th Semester
Guidance_and_Counselling.pdf B.Ed. 4th Semester
 
1.4 modern child centered education - mahatma gandhi-2.pptx
1.4 modern child centered education - mahatma gandhi-2.pptx1.4 modern child centered education - mahatma gandhi-2.pptx
1.4 modern child centered education - mahatma gandhi-2.pptx
 
Introduction to AI for Nonprofits with Tapp Network
Introduction to AI for Nonprofits with Tapp NetworkIntroduction to AI for Nonprofits with Tapp Network
Introduction to AI for Nonprofits with Tapp Network
 
CACJapan - GROUP Presentation 1- Wk 4.pdf
CACJapan - GROUP Presentation 1- Wk 4.pdfCACJapan - GROUP Presentation 1- Wk 4.pdf
CACJapan - GROUP Presentation 1- Wk 4.pdf
 

Software Designing - Software Engineering

  • 2. INTRO  Goal is to produce a model or repesentation  Designer should  Stock all material of design like components, component solutions & knowledge  Choose elements from stock that meet requirements  Alternatives are also considered & accepted/rejected for final confirmation
  • 3. Design Process  To achieve intended goal of software – successful implementation  Always refers to finding solution or problem solving  Includes algorithms, diagrams, formulae designs, low level design etc.  Follow semi standard methods like UML for modelling the software  Use different diagrams like activity, use case and sequence  Use of design patterns and architectural guides (if required)
  • 4. Design Concepts  Abstraction  For modular solution many level of abstraction is possible  High level solution – solution stated in the language of the problem environment  lower levels of abstraction - used for detailed description  data abstraction is actually a collection of data that describes a data object
  • 5.  Architecture  Software architecture is the complete structure or arrangement of the program components in such a way that they interact with each other  data structures may be used by these components  these components are the building blocks of the overall structure of the application being developed  architectural design can be represented using one or more of a number of different models  Patterns  a design pattern describes a design structure that solves a particular design problem within a specific context
  • 6.  Modularity  consists of software architecture and design patterns  defined as the modularization of a single attribute (main module) of software into number of small parts (smaller modules) such that these parts can be easily managed  Consider  C(x) – function of a problem x that define its complexity  E(X) - function of a problem x that define efforts required to solve that problem  Let there are two problems p1 and p2 for which, If C(p1) > C(p2) then E(p1) > E(p2)
  • 7.  interesting characteristic is uncovered through observations and experimentation C(p1 + p2) > C(p1) + C(p2)  complexity of two combined problems p1 and p2 is greater than the complexity when the problems are considered separately  From previous equations it follows, E(p1 + p2) > E(p1) + E(p2)  That leads to a strategy called divide and conquer  always easy to solve a complex problem when it is divided in small sub-problems that are easily manageable
  • 8.  the effort (cost) to develop an individual software module does decrease as the total number of modules increases  For large size problem, the number of modules will be increased and the effort (cost) associated with integrating the modules also increases • M is number of modules that would result in minimum development cost, but there is no any proper and sophisticated method to predict M • divide the problem into modules, but utmost care must be taken to stay in the region of M
  • 9.  five criteria defined for an effective modular system  Modular decomposability : complex problem may be solved very easily by decomposing into smaller sub problems  Modular composability : Different modules and components are integrated to produce a new system  Modular understandability : While integrating a system, if each of the individual modules or components are understood well, then it become very easy to build the system once again  Modular continuity : to minimize side effect of changes it’s always better to make changes module-wise instead of making changes system- wise  Modular protection : for any abnormal condition within a module, the effects are within that module only. Thus the side effects are minimized and problems will not spread outside that module
  • 10.  Information Hiding  modules of the larger problem must be specified and designed properly so that information (i.e. algorithms and data) present within a module is not available to other modules that do not require such information  To achieve effective modularity that have proper necessary communication among modules  Refinement  uses a top-down strategy  the procedural details of a program are refined in various levels  hierarchy is generated by modularizing the statements of a program
  • 11.  Functional Independence  Its a type of modularity and related to the concepts of abstraction and information hiding  In this, each module addresses a specific sub function of requirements and has a simple interface  Independence is assessed by two criteria  Cohesion : a relative functional strength of a module  Coupling : relative interdependence among modules
  • 12.  Cohesion  extension of the concept of information hiding  a module performs only one task within a software procedure (or required only little interaction with other procedures of the software)  module that performs different tasks that are loosely related to each other are termed as coincidentally cohesive  module that performs tasks that are related logically is logically cohesive  When a module contains tasks that are related by the fact that all must be executed with the same span of time, the module exhibits temporal cohesion  Procedural cohesion exists when processing elements of a module are related and are executed in a specific order
  • 13.  When all the processing elements do concentrate on only one area of a data structure, then communicational cohesion is available  High-end cohesion is characterized by a module that performs one single and unique procedural task  Coupling  is a measure of inter-relationship among various modules in a software structure  always depends on the interface complexity among modules  to make bit easy to understand, connectivity between different modules of software is made simple by minimum possible coupling  Simple connectivity  avoid “Ripple Effect” - (errors occurring at one particular location in the system and propagating through a system)
  • 14.  Types of Coupling  Low data coupling (a – c)  Data passed  Stamp coupling (a - b)  Data Structure passed  Control Coupling (d - e)  Control flag passed  High level of coupling (external coupling)  Modules tied to external environments  High (common) Coupling (c – g – k )  Modules refer a global data area
  • 15.  Refactoring  reorganization technique that simplifies the design (or code) of a component without changing its function or behavior  it does not alter the external behavior of the code [design] yet improves its internal structure  Importance  To improve quality of software  Improving the quality of the code, working becomes easier  addition of new code and maintenance of the code becomes easy  Improves the code over the period of time  Play important role in splitting long functions into reasonably small sub functions  Helps in creating reusable codes  Error handling is much easier and within control
  • 16.  Design Classes  Each of the software team should define a set of design classes  Classes should describe the elements of problem domain and that should focus the customer requirement  It should,  Refine the analysis classes that are implemented  Create a new set of design classes that must support the business solutions
  • 17. Design Principles  s/w design must be in such a way that the system is easily traceable to the analysis model  software design must not reinvent the wheel (i.e. repetition of the same tasks), since the time is limited and the resources are also limited, the design should use the existing ideas and patterns  design must be in such a way that it minimizes the intellectual distance between the application or the system and the related problems  design must demonstrate uniformity and integration of different components to their interfaces
  • 18.  design structure must be flexible to accommodate modification  design must withstand against abnormal data, abnormal events and abnormal operating conditions  design should not be the coding, and coding should not be the design  design should be able to evaluate the quality  design must be reviewed to minimize the conceptual errors
  • 19. Architectural Design  architecture of a program or computing system is actually the structures of the system that consists of following attributes  Software Components  Externally visible property of s/w component  Relationships among this components  It’s a representation that enable s/w engineer to analyse,  Analyse the effectivness of the design  Consider architectural alternatives  Reduce the associated risks
  • 20.  Importance of architectural design  enables communication between all stakeholders involved in the development of the system  emphasizes early design decisions that will have a deep influence on all software engineering tasks (success mantra for the system)  builds a small, intellectually model that will help the system to integrate its component
  • 21. Architectural Styles  It explains the system category that consist of,  set of components (i.e. a database or the computational modules) that perform a function required by the system  set of connectors used for communication, coordination, and cooperation between the components  constraints used to define the integration of various components into system  semantic models used to understand the overall properties of a system with the help of analysis of its elements
  • 22. Data Centered Architecture  Data stored – accessed by various components of the system  Access a central repository  Independent of other component changes and update
  • 23. Data Flow architectures  When i/p data are to be transformed through series of computational components to get o/p data  Pipe and filter pattern  transmit data from one component to next  Each filter designed to expect data i/p of certain form and produce o/p in specified form  Doesn’t require working knowledge of neighbouring filter
  • 24.  Call & Return architecture  Enables program structure that is easy to modify and scales  No of sub style  Main Program/Sub Program Arch. : decomposes function into control hierarchy where main program invokes no of other components  Remote Procedure Call Archi. : component of main program / subprogram are distributed across multiple computers on n/w  Object Oriented Architecture  Component encapsulate data and operations  Component communication happen via message passing
  • 25.  Layered Archi.  No of different layers are defined having operations that progressively become closer to solution
  • 26.  Other Architectures  Publisher Subscriber Architecture  Client Server Architecture  Peer to Peer Architecture  Event Based s/w Architecture
  • 27. Component Level Design  comes after architectural design is completed  It’s an alternative approach to the architectural design approach  Defines data structures, algorithms, interface characteristics & comm mechanism  Three different view of a component design  Objet Oriented view (defines attributes and operations)  ConventionalView (component with – processing logic + data Structures + interface)  Process RelatedView (focus on the reusability of the existing software components)
  • 29. User Interface Design  Creates an effective communication between user and system  Many factors are considered before designing UI  Type of the user, age, education level, purpose of the s/w  Provided at h/w as well as s/w level  Need good understanding of user needs  Types of UI - Command Interpreter & GUI  Benefits of good UI  Higher revenue  Increased user efficiency and satisfaction  Reduced development costs  Reduced support costs
  • 30. Design rules for UI  Place the user in Control  Define the interaction modes in such a way that the user is not forced to perform unnecessary or undesired actions  The interaction should be flexible  User interaction should be interruptible and undoable  The different levels of difficulty in interaction for different classes of users must be customized  Hide complexities from the casual user  direct interaction with objects that appear on the screen
  • 31.  Reduce the User’s Memory Load  Reduce the demand for short-term memory  Define shortcuts that can easily remembered  Established meaningful defaults  information should be disclosed in a progressive fashion  Make the Interface Consistent
  • 32. UI Design Models  User Profile Model  Novices (no syntactic but little semantic knowledge)  Knowledgeable, intermittent users (low syntactic & reasonable semantic knowledge)  Knowledgeable, frequent users (Good Syntactic and semantic knowledge)  Design Model  Implementation Model  User’s System Perception
  • 33. Web Application Design  WebApp Design involves technical and non technical acts like,  Establishing look and feel of web app  Great UI  Defining overall architectural structure  Developing content and functionality that resides within his architecture  Planning the navigation that occurs within the WebApp
  • 34. WebApp Design Quality Requirement
  • 35. WebApp Interface Design  Main objectives  Establish a consistent window into the content an functionality that provided by the interface  Guide the user with series of interactions with the WebApp  Organize the navigation option and content available to the user
  • 36.  Aesthetic Design (graphic design)  Is an artistic endeavour that complements technical aspects of WebApp Design  Content Design  Focus on two different task (addressed by individuals)  Design representation for content objects and relationship between them developed  Conducted by copywriters, graphic designers & others who generate the content to be used within WebApp
  • 37.  Architectural Design (in parallel with previous phase)  Tied to the goals  Content to be presented  Users who visit the WebApp  Navigation philosophy established within the WebApp  Decisions made during this phase has strong influence on Navigation Designing  Navigation Design  Define the navigation pathways that enable user to access components and functions of the WebApp (pages, functions, scripts and other pages)
  • 38.  Component Level Design  ModernWebApps deliver sophisticated processing functions that perform  localized processing (to generate content and navigation dynamically)  Computation or data processing capability  Provide sophisticated database query and access  Establish data interface with external components
  • 39. END