Software design

Inocentshuja Ahmad
Inocentshuja AhmadStudent at MUNCIPAL DEGREE COLLEGE em Falcon School system
Chapter : Design Engineering
Design Engineering
 It covers the set of principles, concepts, and practices that
lead to the development of a high quality system or product.
 Goal of design engineering is to produce a model or
representation that depict:
 Firmness – program should not have any bug that inhibits its functions.
 Commodity – suitable to its intended use.
 Delight - pleasurable to use
 The design model provides detail about software data
structures, architecture, interfaces, and components that are
necessary to implement the system.
Software Design
 Software design model consists of 4
designs:
Data/class Design
Architectural Design
Interface Design
Component Design
Translating Analysis  Design
 Data/class design - Created by transforming the analysis model
class-based elements into classes and data structures required to
implement the software
 Architectural design - defines the relationships among the major
structural elements of the software, it is derived from the class-based
elements and flow-oriented elements of the analysis model
 Interface design - describes how the software elements, hardware
elements, and end-users communicate with one another, it is derived
from the analysis model scenario-based elements, flow-oriented
elements, and behavioral elements
 Component-level design - created by transforming the structural
elements defined by the software architecture into a procedural
description of the software components using information obtained
from the analysis model class-based elements, flow-oriented
elements, and behavioral elements
Why design is so important?
 It is place where quality is fostered.
 It provides us with representation of software that can be
assessed for quality.
 Only way that can accurately translate a customer’s
requirements into a finished software product.
 It serves as foundation for all software engineering
activities.
 Without design difficult to assess:
 Risk
 Test
 Quality
Design Process and Design Quality
 S/w design is an iterative process through
which requirements are translated into a
“blueprint” for constructing the s/w.
 As design iteration occur, subsequent
refinement leads to design representation
at much lower levels of abstraction.
Goal of design process
 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.
Quality Guidelines
Characteristics of good design
 A design should exhibit an architecture that
 as been created using recognizable architectural styles or
patterns,
 is composed of components that exhibit good design
characteristics and
 can be implemented in an evolutionary fashion
 A design should be modular; that is, the software should be logically
partitioned into elements or subsystems
 A design should contain distinct representations of data,
architecture, interfaces, and components.
 A design should lead to data structures that are appropriate for the
classes to be implemented and are drawn from recognizable data
patterns.
 A design should lead to components that exhibit independent
functional characteristics
Quality Guidelines (contd.)
 A design should lead to interfaces that reduce the
complexity of connections between components and with
the external environment.
 A design should be derived using a repeatable method
that is driven by information obtained during software
requirements analysis.
 A design should be represented using a notation that
effectively communicates its meaning.
Design Principles
 S/W design is both a process and a
model.
 Design process - sequence of steps that
enable the designer to describe all
aspects of the software to be built.
 Design model - created for software
provides a variety of different views of the
computer software
 The design process should not suffer from ‘tunnel vision.’ -
Designer should consider alternative approaches.
 The design should be traceable to the analysis model - a
single element of the design model often traces to multiple
requirements, it is necessary to have a means for tracking
how requirements have been satisfied by the design model.
 The design should not reinvent the wheel- use already exists
design pattern because time is short and resource are limited.
 The design should “minimize the intellectual distance”
between the software and the problem as it exists in the real
world. – design should be self-explanatory
 The design should exhibit uniformity and integration – before
design work begins rules of styles and format should be
defined for a design team.
 The design should be structured to accommodate change
 The design should be structured to degrade gently, even
when unusual data, events, or operating conditions are
encountered.
 Design is not coding, coding is not design.
 The design should be assessed for quality as it is being
created, not after the fact
 The design should be reviewed to minimize conceptual
(semantic) errors.
Design concepts
 Design concepts provide the necessary
framework for “to get the thing on right way”.
 Abstraction
 Refinement
 Modularity
 Architecture
 Control Hierarchy
 Structural Partitioning
 Data Structure
 Software Procedure
 Information Hiding
Abstraction
 At the highest level of abstraction – a solution is stated in
broad terms
 At lower level of abstraction – a more detailed description of
the solution is provided.
 Two types of abstraction:
 Procedural abstraction: Sequence of instructions that have a
specific and limited function.
Ex. Open a door
open implies long sequence of activities (e.g. walk to the door,
grasp knob, turn knob and pull the door, etc).
 Data abstraction: collection of data that describes a data
object.
Ex. Open a door. – door is data object.
 Data abstraction for door would encompass a set of attributes
that describe the door. (E.g. door type, swing direction,
opening mechanism, etc.)
Refinement
 Refinement is actually a process of elaboration.
 begin with a statement of function (or description of
information) that is defined at a high level of abstraction.
 That is, the statement describes function or information
conceptually but provides no information about the
internal workings of the function or the internal structure
of the information.
 Refinement causes the designer to elaborate on the
original statement, providing more and more detail as
each successive refinement (elaboration) occurs.
 Abstraction and refinement are complementary
concepts. Abstraction enables a designer to specify
procedure and data and yet suppress low-level details.
 Refinement helps the designer to expose low-level
details as design progresses.
Modularity
 Architecture and design pattern embody modularity.
 Software is divided into separately named and
addressable components, sometimes called modules,
which are integrated to satisfy problem requirement.
 modularity is the single attribute of software that allows a
program to be intellectually manageable
 It leads to a “divide and conquer” strategy. – it is easier
to solve a complex problem when you break into a
manageable pieces.
 Refer fig. that state that effort (cost) to develop an
individual software module does decrease if total number
of modules increase.
 However as the no. of modules grows, the effort (cost)
associated with integrating the modules also grows.
Modularity and software cost
 Undermodularity and overmodularity should be
avoided. But how do we know the vicinity of M?
 We modularize a design so that development can be
more easily planned.
 Software increments can be defined and delivered.
 Changes can be more easily accommodated.
 Testing and debugging can be conducted more
efficiently and long-term maintained can be
conducted without serious side effects.
Architecture
 Software architecture suggest “ the overall structure of the
software and the ways in which that structure provides
conceptual integrity for a system.
 No. of different models can use to represent architecture.
 Structural Model- represent architecture as an organized
collection of components
 Framework model – Increase level of design abstraction by
identifying repeatable architectural design framework.
 Dynamic model – address behavior of the program
architecture and indicating how system or structure
configuration may change as a function.
 Process Model – focus on design of the business or
technical process that the system must accommodate.
 Functional models – used to represent the functional
hierarchy of a system.
Control Hierarchy
 Control hierarchy, represents the organization of
program components (modules) and implies a
hierarchy of control.
 Different notations are used to represent control
hierarchy for those architectural styles that are
amenable to this representation.
 The most common is the treelike diagram that
represents hierarchical control for call and return
architectures.
Control Hierarchy
 In fig. depth and width provide an indication of the
number of levels of control and overall span of control.
 Fan-out is a measure of the number of modules that are
directly controlled by another module. Fan-in indicates
how many modules directly control a given module.
 A module that controls another module is said to be
superordinate to it, and conversely, a module controlled
by another is said to be subordinate to the controller.
Ex. Module M is superordinate to modules a, b, and c.
Module h is subordinate to module e
Structural Partitioning
Structure partitioning
 Two types of Structure partitioning:
 Horizontal Partitioning
 Vertical Partitioning
 Horizontal partitioning defines separate branches of the
modular hierarchy for each major program function.
 Control modules, represented in a darker shade are used
to coordinate communication & execution between its
functions.
 Horizontal partitioning defines three partitions—input,
data transformation (often called processing) and output.
 Benefits of Horizontal partitioning:
 software that is easier to test
 software that is easier to maintain
 propagation of fewer side effects
 software that is easier to extend
 On the negative side (Drawback), horizontal
partitioning often causes more data to be
passed across module interfaces and can
complicate the overall control of program flow.
 Vertical partitioning, often called factoring,
suggests that control (decision making) and
work should be distributed top-down in the
program structure.
 Top-level modules should perform control
functions and do little actual processing work.
 Modules that reside low in the structure should
be the workers, performing all input,
computation, and output tasks.
 A change in a control module (high in the
structure) will have a higher probability of
propagating side effects to modules that are
subordinate to it.
 A change to a worker module, given its low level in
the structure, is less likely to cause the
propagation of side effects.
 For this reason vertically partitioned structures are
less likely to be susceptible to side effects when
changes are made and will therefore be more
maintainable.
Data Structure
 Data structure is a representation of the logical relationship among
individual elements of data
 A scalar item is the simplest of all data structures. It represents a
single element of information that may be addressed by an identifier.
 When scalar items are organized as a list or contiguous group, a
sequential vector is formed.
 When the sequential vector is extended to two, three, and ultimately,
an arbitrary number of dimensions, an n-dimensional space is
created. Most common n-dimensional space is the two-dimensional
matrix
 A linked list is a data structure that organizes contiguous scalar
items, vectors, or spaces in a manner (called nodes) that enables
them to be processed as a list.
 A hierarchical data structure is implemented using multilinked lists
that contain scalar items, vectors, and possibly, n-dimensional
spaces.
Software Procedure
 Software procedure focuses on the
processing details of each module
individually.
 Procedure must provide a precise
specification of processing, including
sequence of events, exact decision points,
repetitive operations, and even data
organization and structure.
Information Hiding
 The principle of information hiding suggests that modules
be "characterized by design decisions that (each) hides
from all others modules.“
 In other words, modules should be specified and
designed so that information (algorithm and data)
contained within a module is inaccessible to other
modules that have no need for such information.
 The intent of information hiding is to hide the details of
data structure and procedural processing behind a
module interface.
 It gives benefits when modifications are required during
testing and maintenance because data and procedure
are hiding from other parts of software, unintentional
errors introduced during modification are less.
EFFECTIVE MODULAR DESIGN
 Effective modular design consist of three
things:
Functional Independence
Cohesion
Coupling
Functional Independence
 Functional independence is achieved by developing
modules with "single-minded“ function and an "aversion"
to excessive interaction with other modules.
 In other words - each module addresses a specific sub-
function of requirements and has a simple interface
when viewed from other parts of the program structure.
 Independence is important –
 Easier to develop
 Easier to Test and maintain
 Error propagation is reduced
 Reusable module.
Functional Independence
 To summarize, functional independence is a key
to good design, and design is the key to
software quality.
 To measure independence, have two qualitative
criteria: cohesion and coupling
 Cohesion is a measure of the relative functional
strength of a module.
 Coupling is a measure of the relative
interdependence among modules.
Cohesion
 Cohesion is a natural extension of the information hiding
concept
 A cohesive module performs a single task within a
software procedure, requiring little interaction with
procedures being performed in other parts of a program
 Simply state, a cohesive module should (ideally) do just
one thing.
 We always strive for high cohesion, although the mid-
range of the spectrum is often acceptable.
 Low-end cohesiveness is much "worse" than middle
range, which is nearly as "good" as high-end cohesion.
 So. designer should avoid low levels of cohesion when
modules are designed.
Cohesion
 When processing elements of a module are
related and must be executed in a specific order,
procedural cohesion exists.
 When all processing elements concentrate on
one area of a data structure, communicational
cohesion is present.
 High cohesion is characterized by a module that
performs one distinct procedural task.
Types of cohesion
 A 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.
 At the low-end of the spectrum, a module that
performs a set of tasks that relate to each other
loosely, called coincidentally cohesive.
Coupling
 Coupling depends on the interface complexity between
modules, the point at which entry or reference is made to
a module, and what data pass across the interface
 In software design, we strive for lowest possible
coupling. Simple connectivity among modules results in
software that is easier to understand and less prone to a
"ripple effect" caused when errors occur at one location
and propagate through a system.
 It occur because of design decisions made when
structure was developed.
Coupling
Coupling
 Coupling is characterized by passage of control between
modules.
 “Control flag” (a variable that controls decisions in a
subordinate or superordinate module) is passed between
modules d and e (called control coupling).
 Relatively high levels of coupling occur when modules
are communicate with external to software.
 External coupling is essential, but should be limited to a
small number of modules with a structure.
 High coupling also occurs when a number of modules
reference a global data area.
 Common coupling, no. of modules access a data item in
a global data area
 So it does not mean “use of global data is bad”. It does
mean that a software designer must be take care of this
thing.
Evolution of Software Design
 Early design work concentrated on criteria for the
development of modular programs and methods for
refining software structures in a top-down manner.
 Later work proposed methods for the translation of data
flow or data structure into a design definition.
 Today, the emphasis in software design has been on
software architecture and the design patterns that can be
used to implement software architectures.
Characteristics are common to all
design methods
 A mechanism for the translation of analysis
model into a design representation,
 A notation for representing functional
components and their interfaces.
 Heuristics for refinement and partitioning
 Guidelines for quality assessment.
Design quality attributes
 Acronym FURPS –
Functionality
Usability
Reliability
Performance
Supportability
 Functionality – is assessed by evaluating the feature set
and capabilities of the program.
 Functions that are delivered and security of the
overall system.
 Usability – assessed by considering human factors,
consistency & documentation.
 Reliability – evaluated by
 measuring the frequency and severity of failure.
 Accuracy of output results.
 Ability to recover from failure and predictability of the
program.
 Performance - measured by processing speed,
response time, resource consumption, efficiency.
 Supportability – combines the ability to extend the
program (extensibility), adaptability and serviceability.
1 de 44

Recomendados

Software design por
Software designSoftware design
Software designSyed Muhammad Hammad-ud-Din
69.1K visualizações30 slides
Overview of UML Diagrams por
Overview of UML DiagramsOverview of UML Diagrams
Overview of UML DiagramsManish Kumar
13.9K visualizações16 slides
Coupling and cohesion por
Coupling and cohesionCoupling and cohesion
Coupling and cohesionSutha31
4.3K visualizações27 slides
Data Designs (Software Engg.) por
Data Designs (Software Engg.)Data Designs (Software Engg.)
Data Designs (Software Engg.)Arun Shukla
4.3K visualizações13 slides
Design Concept software engineering por
Design Concept software engineeringDesign Concept software engineering
Design Concept software engineeringDarshit Metaliya
24.5K visualizações14 slides
Uml Presentation por
Uml PresentationUml Presentation
Uml Presentationmewaseem
45.3K visualizações56 slides

Mais conteúdo relacionado

Mais procurados

Formal Specification in Software Engineering SE9 por
Formal Specification in Software Engineering SE9Formal Specification in Software Engineering SE9
Formal Specification in Software Engineering SE9koolkampus
30.3K visualizações40 slides
Software architecture por
Software architectureSoftware architecture
Software architectureAhmad Raza Aslam
9.4K visualizações37 slides
Software Configuration Management (SCM) por
Software Configuration Management (SCM)Software Configuration Management (SCM)
Software Configuration Management (SCM)Er. Shiva K. Shrestha
15.5K visualizações14 slides
software cost factor por
software cost factorsoftware cost factor
software cost factorAbinaya B
30K visualizações27 slides
Software design por
Software designSoftware design
Software designBenazir Fathima
880 visualizações115 slides
Designing Techniques in Software Engineering por
Designing Techniques in Software EngineeringDesigning Techniques in Software Engineering
Designing Techniques in Software Engineeringkirupasuchi1996
23.1K visualizações18 slides

Mais procurados(20)

Formal Specification in Software Engineering SE9 por koolkampus
Formal Specification in Software Engineering SE9Formal Specification in Software Engineering SE9
Formal Specification in Software Engineering SE9
koolkampus30.3K visualizações
Software architecture por Ahmad Raza Aslam
Software architectureSoftware architecture
Software architecture
Ahmad Raza Aslam9.4K visualizações
Software Configuration Management (SCM) por Er. Shiva K. Shrestha
Software Configuration Management (SCM)Software Configuration Management (SCM)
Software Configuration Management (SCM)
Er. Shiva K. Shrestha15.5K visualizações
software cost factor por Abinaya B
software cost factorsoftware cost factor
software cost factor
Abinaya B30K visualizações
Software design por Benazir Fathima
Software designSoftware design
Software design
Benazir Fathima880 visualizações
Designing Techniques in Software Engineering por kirupasuchi1996
Designing Techniques in Software EngineeringDesigning Techniques in Software Engineering
Designing Techniques in Software Engineering
kirupasuchi199623.1K visualizações
Software architecture design ppt por farazimlak
Software architecture design pptSoftware architecture design ppt
Software architecture design ppt
farazimlak3K visualizações
Staffing level estimation por kavitha muneeshwaran
Staffing level estimation Staffing level estimation
Staffing level estimation
kavitha muneeshwaran22.4K visualizações
Chapter 01 software engineering pressman por RohitGoyal183
Chapter 01  software engineering pressmanChapter 01  software engineering pressman
Chapter 01 software engineering pressman
RohitGoyal18311.8K visualizações
Major and Minor Elements of Object Model por sohailsaif
Major and Minor Elements of Object ModelMajor and Minor Elements of Object Model
Major and Minor Elements of Object Model
sohailsaif2.6K visualizações
Uml in software engineering por Mubashir Jutt
Uml in software engineeringUml in software engineering
Uml in software engineering
Mubashir Jutt2.6K visualizações
Chapter 1 2 - some size factors por NancyBeaulah_R
Chapter 1   2 - some size factorsChapter 1   2 - some size factors
Chapter 1 2 - some size factors
NancyBeaulah_R6.8K visualizações
Modules and modularization criteria por Umaselvi_R
Modules and modularization criteriaModules and modularization criteria
Modules and modularization criteria
Umaselvi_R6.8K visualizações
Fundamental design concepts por srijavel
Fundamental design conceptsFundamental design concepts
Fundamental design concepts
srijavel29.2K visualizações
Design notation por ramya marichamy
Design notationDesign notation
Design notation
ramya marichamy21K visualizações
UML and Software Modeling Tools.pptx por Nwabueze Obioma
UML and Software Modeling Tools.pptxUML and Software Modeling Tools.pptx
UML and Software Modeling Tools.pptx
Nwabueze Obioma5.1K visualizações
Software design por Zulqarnaintayyab
Software designSoftware design
Software design
Zulqarnaintayyab390 visualizações
Object Oriented Analysis and Design por Haitham El-Ghareeb
Object Oriented Analysis and DesignObject Oriented Analysis and Design
Object Oriented Analysis and Design
Haitham El-Ghareeb74.4K visualizações
Software Process Models por Hassan A-j
Software Process ModelsSoftware Process Models
Software Process Models
Hassan A-j21.3K visualizações

Similar a Software design

CS8494 SOFTWARE ENGINEERING Unit-3 por
CS8494 SOFTWARE ENGINEERING Unit-3CS8494 SOFTWARE ENGINEERING Unit-3
CS8494 SOFTWARE ENGINEERING Unit-3SIMONTHOMAS S
391 visualizações174 slides
Slides chapter 9 por
Slides chapter 9Slides chapter 9
Slides chapter 9Priyanka Shetty
3.9K visualizações28 slides
Design engineering por
Design engineeringDesign engineering
Design engineeringVikram Dahiya
590 visualizações64 slides
Design engineering por
Design engineeringDesign engineering
Design engineeringVikram Dahiya
11.7K visualizações64 slides
06 fse design por
06 fse design06 fse design
06 fse designMohesh Chandran
838 visualizações46 slides
design-concept.ppt por
design-concept.pptdesign-concept.ppt
design-concept.pptMangeshKetkar1
8 visualizações14 slides

Similar a Software design(20)

CS8494 SOFTWARE ENGINEERING Unit-3 por SIMONTHOMAS S
CS8494 SOFTWARE ENGINEERING Unit-3CS8494 SOFTWARE ENGINEERING Unit-3
CS8494 SOFTWARE ENGINEERING Unit-3
SIMONTHOMAS S391 visualizações
Slides chapter 9 por Priyanka Shetty
Slides chapter 9Slides chapter 9
Slides chapter 9
Priyanka Shetty3.9K visualizações
Design engineering por Vikram Dahiya
Design engineeringDesign engineering
Design engineering
Vikram Dahiya590 visualizações
Design engineering por Vikram Dahiya
Design engineeringDesign engineering
Design engineering
Vikram Dahiya11.7K visualizações
06 fse design por Mohesh Chandran
06 fse design06 fse design
06 fse design
Mohesh Chandran838 visualizações
design-concept.ppt por MangeshKetkar1
design-concept.pptdesign-concept.ppt
design-concept.ppt
MangeshKetkar18 visualizações
Chapter 08 por Nazir Ahmed
Chapter 08Chapter 08
Chapter 08
Nazir Ahmed52 visualizações
Unit 5 design engineering ssad por Preeti Mishra
Unit 5 design engineering ssadUnit 5 design engineering ssad
Unit 5 design engineering ssad
Preeti Mishra1.3K visualizações
Software engg unit 3 por Vivek Kumar Sinha
Software engg unit 3 Software engg unit 3
Software engg unit 3
Vivek Kumar Sinha92 visualizações
Ch09 por guest50f28c
Ch09Ch09
Ch09
guest50f28c695 visualizações
Software engineering por Stella526835
Software engineeringSoftware engineering
Software engineering
Stella52683560 visualizações
Chapter 6 design por nikshaikh786
Chapter 6 designChapter 6 design
Chapter 6 design
nikshaikh786103 visualizações
Unit i software design principles 9 por kiruthikamurugesan2628
Unit i software design principles 9Unit i software design principles 9
Unit i software design principles 9
kiruthikamurugesan26284.1K visualizações
SA_UNIT_1.pptx por ShwetaGajbhiye12
SA_UNIT_1.pptxSA_UNIT_1.pptx
SA_UNIT_1.pptx
ShwetaGajbhiye1218 visualizações
Oose unit 4 ppt por Dr VISU P
Oose unit 4 pptOose unit 4 ppt
Oose unit 4 ppt
Dr VISU P90 visualizações
OOSE Unit 4 PPT.ppt por itadmin33
OOSE Unit 4 PPT.pptOOSE Unit 4 PPT.ppt
OOSE Unit 4 PPT.ppt
itadmin336 visualizações

Mais de Inocentshuja Ahmad

Bottom up parser por
Bottom up parserBottom up parser
Bottom up parserInocentshuja Ahmad
860 visualizações2 slides
7th lec overview - latest por
7th lec   overview - latest7th lec   overview - latest
7th lec overview - latestInocentshuja Ahmad
207 visualizações32 slides
6th lec infrared slides por
6th lec   infrared slides6th lec   infrared slides
6th lec infrared slidesInocentshuja Ahmad
117 visualizações19 slides
5th lec ofdm por
5th lec   ofdm5th lec   ofdm
5th lec ofdmInocentshuja Ahmad
111 visualizações22 slides
3rd lec fcss por
3rd lec   fcss3rd lec   fcss
3rd lec fcssInocentshuja Ahmad
128 visualizações15 slides
2nd lec wireless terminologies por
2nd lec   wireless terminologies2nd lec   wireless terminologies
2nd lec wireless terminologiesInocentshuja Ahmad
213 visualizações38 slides

Mais de Inocentshuja Ahmad(20)

Bottom up parser por Inocentshuja Ahmad
Bottom up parserBottom up parser
Bottom up parser
Inocentshuja Ahmad860 visualizações
7th lec overview - latest por Inocentshuja Ahmad
7th lec   overview - latest7th lec   overview - latest
7th lec overview - latest
Inocentshuja Ahmad207 visualizações
6th lec infrared slides por Inocentshuja Ahmad
6th lec   infrared slides6th lec   infrared slides
6th lec infrared slides
Inocentshuja Ahmad117 visualizações
2nd lec wireless terminologies por Inocentshuja Ahmad
2nd lec   wireless terminologies2nd lec   wireless terminologies
2nd lec wireless terminologies
Inocentshuja Ahmad213 visualizações
1st lec generations por Inocentshuja Ahmad
1st lec   generations1st lec   generations
1st lec generations
Inocentshuja Ahmad111 visualizações
Lecture notes on mobile communication por Inocentshuja Ahmad
Lecture notes on mobile communicationLecture notes on mobile communication
Lecture notes on mobile communication
Inocentshuja Ahmad4K visualizações
Lecture5 mobile communication_short por Inocentshuja Ahmad
Lecture5 mobile communication_short Lecture5 mobile communication_short
Lecture5 mobile communication_short
Inocentshuja Ahmad130 visualizações
8th lec flow and error control por Inocentshuja Ahmad
8th lec   flow and error control8th lec   flow and error control
8th lec flow and error control
Inocentshuja Ahmad657 visualizações
Chapter 10:Risk and Refinements In Capital Budgeting por Inocentshuja Ahmad
Chapter 10:Risk and Refinements In Capital BudgetingChapter 10:Risk and Refinements In Capital Budgeting
Chapter 10:Risk and Refinements In Capital Budgeting
Inocentshuja Ahmad3.5K visualizações
Chapter 9:Capital Budgeting Techniques por Inocentshuja Ahmad
Chapter 9:Capital Budgeting TechniquesChapter 9:Capital Budgeting Techniques
Chapter 9:Capital Budgeting Techniques
Inocentshuja Ahmad7.4K visualizações
Chapter 5:Risk and Return por Inocentshuja Ahmad
Chapter 5:Risk and ReturnChapter 5:Risk and Return
Chapter 5:Risk and Return
Inocentshuja Ahmad9.7K visualizações
Question and answer Programming por Inocentshuja Ahmad
Question and answer ProgrammingQuestion and answer Programming
Question and answer Programming
Inocentshuja Ahmad96 visualizações
Email security & threads por Inocentshuja Ahmad
Email security & threadsEmail security & threads
Email security & threads
Inocentshuja Ahmad307 visualizações
Chapter03 Top Down Design with Function por Inocentshuja Ahmad
Chapter03 Top Down Design with FunctionChapter03 Top Down Design with Function
Chapter03 Top Down Design with Function
Inocentshuja Ahmad167 visualizações

Último

Create a Structure in VBNet.pptx por
Create a Structure in VBNet.pptxCreate a Structure in VBNet.pptx
Create a Structure in VBNet.pptxBreach_P
82 visualizações8 slides
CUNY IT Picciano.pptx por
CUNY IT Picciano.pptxCUNY IT Picciano.pptx
CUNY IT Picciano.pptxapicciano
60 visualizações17 slides
When Sex Gets Complicated: Porn, Affairs, & Cybersex por
When Sex Gets Complicated: Porn, Affairs, & CybersexWhen Sex Gets Complicated: Porn, Affairs, & Cybersex
When Sex Gets Complicated: Porn, Affairs, & CybersexMarlene Maheu
108 visualizações73 slides
Parts of Speech (1).pptx por
Parts of Speech (1).pptxParts of Speech (1).pptx
Parts of Speech (1).pptxmhkpreet001
43 visualizações20 slides
MercerJesse2.1Doc.pdf por
MercerJesse2.1Doc.pdfMercerJesse2.1Doc.pdf
MercerJesse2.1Doc.pdfjessemercerail
301 visualizações5 slides
Narration lesson plan por
Narration lesson planNarration lesson plan
Narration lesson planTARIQ KHAN
69 visualizações11 slides

Último(20)

Create a Structure in VBNet.pptx por Breach_P
Create a Structure in VBNet.pptxCreate a Structure in VBNet.pptx
Create a Structure in VBNet.pptx
Breach_P82 visualizações
CUNY IT Picciano.pptx por apicciano
CUNY IT Picciano.pptxCUNY IT Picciano.pptx
CUNY IT Picciano.pptx
apicciano60 visualizações
When Sex Gets Complicated: Porn, Affairs, & Cybersex por Marlene Maheu
When Sex Gets Complicated: Porn, Affairs, & CybersexWhen Sex Gets Complicated: Porn, Affairs, & Cybersex
When Sex Gets Complicated: Porn, Affairs, & Cybersex
Marlene Maheu108 visualizações
Parts of Speech (1).pptx por mhkpreet001
Parts of Speech (1).pptxParts of Speech (1).pptx
Parts of Speech (1).pptx
mhkpreet00143 visualizações
MercerJesse2.1Doc.pdf por jessemercerail
MercerJesse2.1Doc.pdfMercerJesse2.1Doc.pdf
MercerJesse2.1Doc.pdf
jessemercerail301 visualizações
Narration lesson plan por TARIQ KHAN
Narration lesson planNarration lesson plan
Narration lesson plan
TARIQ KHAN69 visualizações
Pharmaceutical Inorganic Chemistry Unit IVMiscellaneous compounds Expectorant... por Ms. Pooja Bhandare
Pharmaceutical Inorganic Chemistry Unit IVMiscellaneous compounds Expectorant...Pharmaceutical Inorganic Chemistry Unit IVMiscellaneous compounds Expectorant...
Pharmaceutical Inorganic Chemistry Unit IVMiscellaneous compounds Expectorant...
Ms. Pooja Bhandare194 visualizações
Monthly Information Session for MV Asterix (November) por Esquimalt MFRC
Monthly Information Session for MV Asterix (November)Monthly Information Session for MV Asterix (November)
Monthly Information Session for MV Asterix (November)
Esquimalt MFRC98 visualizações
MercerJesse3.0.pdf por jessemercerail
MercerJesse3.0.pdfMercerJesse3.0.pdf
MercerJesse3.0.pdf
jessemercerail92 visualizações
Class 9 lesson plans por TARIQ KHAN
Class 9 lesson plansClass 9 lesson plans
Class 9 lesson plans
TARIQ KHAN68 visualizações
Jibachha publishing Textbook.docx por DrJibachhaSahVetphys
Jibachha publishing Textbook.docxJibachha publishing Textbook.docx
Jibachha publishing Textbook.docx
DrJibachhaSahVetphys54 visualizações
Creative Restart 2023: Atila Martins - Craft: A Necessity, Not a Choice por Taste
Creative Restart 2023: Atila Martins - Craft: A Necessity, Not a ChoiceCreative Restart 2023: Atila Martins - Craft: A Necessity, Not a Choice
Creative Restart 2023: Atila Martins - Craft: A Necessity, Not a Choice
Taste41 visualizações
JQUERY.pdf por ArthyR3
JQUERY.pdfJQUERY.pdf
JQUERY.pdf
ArthyR3103 visualizações
INT-244 Topic 6b Confucianism por S Meyer
INT-244 Topic 6b ConfucianismINT-244 Topic 6b Confucianism
INT-244 Topic 6b Confucianism
S Meyer44 visualizações
STRATEGIC MANAGEMENT MODULE 1_UNIT1 _UNIT2.pdf por Dr Vijay Vishwakarma
STRATEGIC MANAGEMENT MODULE 1_UNIT1 _UNIT2.pdfSTRATEGIC MANAGEMENT MODULE 1_UNIT1 _UNIT2.pdf
STRATEGIC MANAGEMENT MODULE 1_UNIT1 _UNIT2.pdf
Dr Vijay Vishwakarma90 visualizações
ICS3211_lecture 09_2023.pdf por Vanessa Camilleri
ICS3211_lecture 09_2023.pdfICS3211_lecture 09_2023.pdf
ICS3211_lecture 09_2023.pdf
Vanessa Camilleri134 visualizações
The Accursed House by Émile Gaboriau por DivyaSheta
The Accursed House  by Émile GaboriauThe Accursed House  by Émile Gaboriau
The Accursed House by Émile Gaboriau
DivyaSheta246 visualizações

Software design

  • 1. Chapter : Design Engineering
  • 2. Design Engineering  It covers the set of principles, concepts, and practices that lead to the development of a high quality system or product.  Goal of design engineering is to produce a model or representation that depict:  Firmness – program should not have any bug that inhibits its functions.  Commodity – suitable to its intended use.  Delight - pleasurable to use  The design model provides detail about software data structures, architecture, interfaces, and components that are necessary to implement the system.
  • 3. Software Design  Software design model consists of 4 designs: Data/class Design Architectural Design Interface Design Component Design
  • 5.  Data/class design - Created by transforming the analysis model class-based elements into classes and data structures required to implement the software  Architectural design - defines the relationships among the major structural elements of the software, it is derived from the class-based elements and flow-oriented elements of the analysis model  Interface design - describes how the software elements, hardware elements, and end-users communicate with one another, it is derived from the analysis model scenario-based elements, flow-oriented elements, and behavioral elements  Component-level design - created by transforming the structural elements defined by the software architecture into a procedural description of the software components using information obtained from the analysis model class-based elements, flow-oriented elements, and behavioral elements
  • 6. Why design is so important?  It is place where quality is fostered.  It provides us with representation of software that can be assessed for quality.  Only way that can accurately translate a customer’s requirements into a finished software product.  It serves as foundation for all software engineering activities.  Without design difficult to assess:  Risk  Test  Quality
  • 7. Design Process and Design Quality  S/w design is an iterative process through which requirements are translated into a “blueprint” for constructing the s/w.  As design iteration occur, subsequent refinement leads to design representation at much lower levels of abstraction.
  • 8. Goal of design process  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.
  • 9. Quality Guidelines Characteristics of good design  A design should exhibit an architecture that  as been created using recognizable architectural styles or patterns,  is composed of components that exhibit good design characteristics and  can be implemented in an evolutionary fashion  A design should be modular; that is, the software should be logically partitioned into elements or subsystems  A design should contain distinct representations of data, architecture, interfaces, and components.  A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns.  A design should lead to components that exhibit independent functional characteristics
  • 10. Quality Guidelines (contd.)  A design should lead to interfaces that reduce the complexity of connections between components and with the external environment.  A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.  A design should be represented using a notation that effectively communicates its meaning.
  • 11. Design Principles  S/W design is both a process and a model.  Design process - sequence of steps that enable the designer to describe all aspects of the software to be built.  Design model - created for software provides a variety of different views of the computer software
  • 12.  The design process should not suffer from ‘tunnel vision.’ - Designer should consider alternative approaches.  The design should be traceable to the analysis model - a single element of the design model often traces to multiple requirements, it is necessary to have a means for tracking how requirements have been satisfied by the design model.  The design should not reinvent the wheel- use already exists design pattern because time is short and resource are limited.  The design should “minimize the intellectual distance” between the software and the problem as it exists in the real world. – design should be self-explanatory
  • 13.  The design should exhibit uniformity and integration – before design work begins rules of styles and format should be defined for a design team.  The design should be structured to accommodate change  The design should be structured to degrade gently, even when unusual data, events, or operating conditions are encountered.  Design is not coding, coding is not design.  The design should be assessed for quality as it is being created, not after the fact  The design should be reviewed to minimize conceptual (semantic) errors.
  • 14. Design concepts  Design concepts provide the necessary framework for “to get the thing on right way”.  Abstraction  Refinement  Modularity  Architecture  Control Hierarchy  Structural Partitioning  Data Structure  Software Procedure  Information Hiding
  • 15. Abstraction  At the highest level of abstraction – a solution is stated in broad terms  At lower level of abstraction – a more detailed description of the solution is provided.  Two types of abstraction:  Procedural abstraction: Sequence of instructions that have a specific and limited function. Ex. Open a door open implies long sequence of activities (e.g. walk to the door, grasp knob, turn knob and pull the door, etc).  Data abstraction: collection of data that describes a data object. Ex. Open a door. – door is data object.  Data abstraction for door would encompass a set of attributes that describe the door. (E.g. door type, swing direction, opening mechanism, etc.)
  • 16. Refinement  Refinement is actually a process of elaboration.  begin with a statement of function (or description of information) that is defined at a high level of abstraction.  That is, the statement describes function or information conceptually but provides no information about the internal workings of the function or the internal structure of the information.  Refinement causes the designer to elaborate on the original statement, providing more and more detail as each successive refinement (elaboration) occurs.  Abstraction and refinement are complementary concepts. Abstraction enables a designer to specify procedure and data and yet suppress low-level details.  Refinement helps the designer to expose low-level details as design progresses.
  • 17. Modularity  Architecture and design pattern embody modularity.  Software is divided into separately named and addressable components, sometimes called modules, which are integrated to satisfy problem requirement.  modularity is the single attribute of software that allows a program to be intellectually manageable  It leads to a “divide and conquer” strategy. – it is easier to solve a complex problem when you break into a manageable pieces.  Refer fig. that state that effort (cost) to develop an individual software module does decrease if total number of modules increase.  However as the no. of modules grows, the effort (cost) associated with integrating the modules also grows.
  • 19.  Undermodularity and overmodularity should be avoided. But how do we know the vicinity of M?  We modularize a design so that development can be more easily planned.  Software increments can be defined and delivered.  Changes can be more easily accommodated.  Testing and debugging can be conducted more efficiently and long-term maintained can be conducted without serious side effects.
  • 20. Architecture  Software architecture suggest “ the overall structure of the software and the ways in which that structure provides conceptual integrity for a system.  No. of different models can use to represent architecture.  Structural Model- represent architecture as an organized collection of components  Framework model – Increase level of design abstraction by identifying repeatable architectural design framework.  Dynamic model – address behavior of the program architecture and indicating how system or structure configuration may change as a function.  Process Model – focus on design of the business or technical process that the system must accommodate.  Functional models – used to represent the functional hierarchy of a system.
  • 21. Control Hierarchy  Control hierarchy, represents the organization of program components (modules) and implies a hierarchy of control.  Different notations are used to represent control hierarchy for those architectural styles that are amenable to this representation.  The most common is the treelike diagram that represents hierarchical control for call and return architectures.
  • 23.  In fig. depth and width provide an indication of the number of levels of control and overall span of control.  Fan-out is a measure of the number of modules that are directly controlled by another module. Fan-in indicates how many modules directly control a given module.  A module that controls another module is said to be superordinate to it, and conversely, a module controlled by another is said to be subordinate to the controller. Ex. Module M is superordinate to modules a, b, and c. Module h is subordinate to module e
  • 25. Structure partitioning  Two types of Structure partitioning:  Horizontal Partitioning  Vertical Partitioning  Horizontal partitioning defines separate branches of the modular hierarchy for each major program function.  Control modules, represented in a darker shade are used to coordinate communication & execution between its functions.  Horizontal partitioning defines three partitions—input, data transformation (often called processing) and output.  Benefits of Horizontal partitioning:  software that is easier to test  software that is easier to maintain  propagation of fewer side effects  software that is easier to extend
  • 26.  On the negative side (Drawback), horizontal partitioning often causes more data to be passed across module interfaces and can complicate the overall control of program flow.  Vertical partitioning, often called factoring, suggests that control (decision making) and work should be distributed top-down in the program structure.  Top-level modules should perform control functions and do little actual processing work.  Modules that reside low in the structure should be the workers, performing all input, computation, and output tasks.
  • 27.  A change in a control module (high in the structure) will have a higher probability of propagating side effects to modules that are subordinate to it.  A change to a worker module, given its low level in the structure, is less likely to cause the propagation of side effects.  For this reason vertically partitioned structures are less likely to be susceptible to side effects when changes are made and will therefore be more maintainable.
  • 28. Data Structure  Data structure is a representation of the logical relationship among individual elements of data  A scalar item is the simplest of all data structures. It represents a single element of information that may be addressed by an identifier.  When scalar items are organized as a list or contiguous group, a sequential vector is formed.  When the sequential vector is extended to two, three, and ultimately, an arbitrary number of dimensions, an n-dimensional space is created. Most common n-dimensional space is the two-dimensional matrix  A linked list is a data structure that organizes contiguous scalar items, vectors, or spaces in a manner (called nodes) that enables them to be processed as a list.  A hierarchical data structure is implemented using multilinked lists that contain scalar items, vectors, and possibly, n-dimensional spaces.
  • 29. Software Procedure  Software procedure focuses on the processing details of each module individually.  Procedure must provide a precise specification of processing, including sequence of events, exact decision points, repetitive operations, and even data organization and structure.
  • 30. Information Hiding  The principle of information hiding suggests that modules be "characterized by design decisions that (each) hides from all others modules.“  In other words, modules should be specified and designed so that information (algorithm and data) contained within a module is inaccessible to other modules that have no need for such information.  The intent of information hiding is to hide the details of data structure and procedural processing behind a module interface.  It gives benefits when modifications are required during testing and maintenance because data and procedure are hiding from other parts of software, unintentional errors introduced during modification are less.
  • 31. EFFECTIVE MODULAR DESIGN  Effective modular design consist of three things: Functional Independence Cohesion Coupling
  • 32. Functional Independence  Functional independence is achieved by developing modules with "single-minded“ function and an "aversion" to excessive interaction with other modules.  In other words - each module addresses a specific sub- function of requirements and has a simple interface when viewed from other parts of the program structure.  Independence is important –  Easier to develop  Easier to Test and maintain  Error propagation is reduced  Reusable module.
  • 33. Functional Independence  To summarize, functional independence is a key to good design, and design is the key to software quality.  To measure independence, have two qualitative criteria: cohesion and coupling  Cohesion is a measure of the relative functional strength of a module.  Coupling is a measure of the relative interdependence among modules.
  • 34. Cohesion  Cohesion is a natural extension of the information hiding concept  A cohesive module performs a single task within a software procedure, requiring little interaction with procedures being performed in other parts of a program  Simply state, a cohesive module should (ideally) do just one thing.  We always strive for high cohesion, although the mid- range of the spectrum is often acceptable.  Low-end cohesiveness is much "worse" than middle range, which is nearly as "good" as high-end cohesion.  So. designer should avoid low levels of cohesion when modules are designed.
  • 35. Cohesion  When processing elements of a module are related and must be executed in a specific order, procedural cohesion exists.  When all processing elements concentrate on one area of a data structure, communicational cohesion is present.  High cohesion is characterized by a module that performs one distinct procedural task.
  • 36. Types of cohesion  A 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.  At the low-end of the spectrum, a module that performs a set of tasks that relate to each other loosely, called coincidentally cohesive.
  • 37. Coupling  Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface  In software design, we strive for lowest possible coupling. Simple connectivity among modules results in software that is easier to understand and less prone to a "ripple effect" caused when errors occur at one location and propagate through a system.  It occur because of design decisions made when structure was developed.
  • 39. Coupling  Coupling is characterized by passage of control between modules.  “Control flag” (a variable that controls decisions in a subordinate or superordinate module) is passed between modules d and e (called control coupling).  Relatively high levels of coupling occur when modules are communicate with external to software.  External coupling is essential, but should be limited to a small number of modules with a structure.
  • 40.  High coupling also occurs when a number of modules reference a global data area.  Common coupling, no. of modules access a data item in a global data area  So it does not mean “use of global data is bad”. It does mean that a software designer must be take care of this thing.
  • 41. Evolution of Software Design  Early design work concentrated on criteria for the development of modular programs and methods for refining software structures in a top-down manner.  Later work proposed methods for the translation of data flow or data structure into a design definition.  Today, the emphasis in software design has been on software architecture and the design patterns that can be used to implement software architectures.
  • 42. Characteristics are common to all design methods  A mechanism for the translation of analysis model into a design representation,  A notation for representing functional components and their interfaces.  Heuristics for refinement and partitioning  Guidelines for quality assessment.
  • 43. Design quality attributes  Acronym FURPS – Functionality Usability Reliability Performance Supportability
  • 44.  Functionality – is assessed by evaluating the feature set and capabilities of the program.  Functions that are delivered and security of the overall system.  Usability – assessed by considering human factors, consistency & documentation.  Reliability – evaluated by  measuring the frequency and severity of failure.  Accuracy of output results.  Ability to recover from failure and predictability of the program.  Performance - measured by processing speed, response time, resource consumption, efficiency.  Supportability – combines the ability to extend the program (extensibility), adaptability and serviceability.

Notas do Editor

  1. As an example of low cohesion, consider a module that performs error processing for an engineering analysis package. The module is called when computed data exceed prespecified bounds. It performs the following tasks: (1) computes supplementary data based on original computed data, (2) produces an error report (with graphical content) on the user's workstation, (3) performs follow-up calculations requested by the user, (4) updates a database, and (5) enables menu selection for subsequent processing. Although the preceding tasks are loosely related, each is an independent functional entity that might best be performed as a separate module. Combining the functions into a single module can serve only to increase the likelihood of error propagation when a modification is made to one of its processing tasks.
  2. Modules a and d are subordinate to different modules. Each is unrelated and therefore no direct coupling occurs. Module c is subordinate to module a and is accessed via a conventional argument list, through which data are passed. As long as a simple argument list is present (i.e., simple data are passed; a one-to-one correspondence of items exists), low coupling (called data coupling) is exhibited in this portion of structure. A variation of data coupling, called stamp coupling, is found when a portion of a data structure (rather than simple arguments) is passed via a module interface. This occurs between modules b and a.
  3. Common coupling --Module c initializes the item. Later module g recomputed and updates the item. Let's assume that an error occurs and g updates the item incorrectly. Much later in processing module, k reads the item, attempts to process it, and fails, causing the software to abort. The apparent cause of abort is module k; the actual cause, module g. Diagnosing problems in structures with considerable common coupling is time consuming and difficult.