The document discusses software design and implementation. It describes the design phase as involving high-level architectural design to develop the overall structure of a software program, and low-level detailed design to develop specific algorithms and data structures. The implementation phase includes activities like constructing software components, testing, developing prototypes, training, and installing the system. Good design principles include modularity, low coupling between modules, and high cohesion within modules.
The document discusses key concepts in software design including:
- Software design is an iterative process that translates requirements into a blueprint for constructing the software. Models are created to describe data structures, architecture, interfaces, and components.
- Design patterns, modularity, information hiding, and functional independence are fundamental concepts in software design. Architectural, interface, procedural, and data designs are created.
- Refinement is a top-down design strategy where procedural details are elaborated. Refactoring improves internal structure without changing external behavior.
This document provides an overview of the unit 3 course material for Software Design taught by Dr. Radhey Shyam at SRMCEM Lucknow. The document discusses key concepts in software design including the importance of design, characteristics of good and bad design, coupling and cohesion, modularization, design models, high level design and architectural design. Specific topics covered include software design documentation, conceptual vs technical design, types of coupling and cohesion, advantages of modular systems, design frameworks, and strategies for design such as top-down, bottom-up, and hybrid approaches.
The document describes key components of software design including data design, architectural design, interface design, and procedural design. It discusses the goals of the design process which are to implement requirements, create an understandable guide for code generation and testing, and address implementation from data, functional, and behavioral perspectives. The document also covers concepts like abstraction, refinement, modularity, program structure, data structures, software procedures, information hiding, and cohesion and coupling.
The document discusses key concepts in software design including:
- Software design is an iterative process that translates requirements into a blueprint for constructing software through models.
- Models describe details like data structures, system architecture, interfaces and components.
- Design specifications include data, architectural, interface, procedural and component-level design.
- Fundamental concepts in design include abstraction, architecture, patterns, modularity, information hiding, and refinement.
The document discusses key concepts in software design including:
- Software design is an iterative process that translates requirements into a blueprint for constructing software through models.
- Models describe details like data structures, system architecture, interfaces and components.
- Design specifications include data, architectural, interface, procedural and component-level design.
- Fundamental concepts in design include abstraction, architecture, patterns, modularity, information hiding, and refinement.
Software design is a critical phase in the development of any software application, playing a pivotal role in its success and long-term sustainability.
This document discusses fundamentals of software engineering design. It explains that design creates a representation of software that provides implementation details beyond an analysis model. Four design models are described: data design, architectural design, user interface design, and component-level design. Design principles, concepts like abstraction and patterns are explained. Tools like CASE tools can support design, and evaluation ensures a quality design. A design specification document formally specifies the design.
The document discusses software design and implementation. It describes the design phase as involving high-level architectural design to develop the overall structure of a software program, and low-level detailed design to develop specific algorithms and data structures. The implementation phase includes activities like constructing software components, testing, developing prototypes, training, and installing the system. Good design principles include modularity, low coupling between modules, and high cohesion within modules.
The document discusses key concepts in software design including:
- Software design is an iterative process that translates requirements into a blueprint for constructing the software. Models are created to describe data structures, architecture, interfaces, and components.
- Design patterns, modularity, information hiding, and functional independence are fundamental concepts in software design. Architectural, interface, procedural, and data designs are created.
- Refinement is a top-down design strategy where procedural details are elaborated. Refactoring improves internal structure without changing external behavior.
This document provides an overview of the unit 3 course material for Software Design taught by Dr. Radhey Shyam at SRMCEM Lucknow. The document discusses key concepts in software design including the importance of design, characteristics of good and bad design, coupling and cohesion, modularization, design models, high level design and architectural design. Specific topics covered include software design documentation, conceptual vs technical design, types of coupling and cohesion, advantages of modular systems, design frameworks, and strategies for design such as top-down, bottom-up, and hybrid approaches.
The document describes key components of software design including data design, architectural design, interface design, and procedural design. It discusses the goals of the design process which are to implement requirements, create an understandable guide for code generation and testing, and address implementation from data, functional, and behavioral perspectives. The document also covers concepts like abstraction, refinement, modularity, program structure, data structures, software procedures, information hiding, and cohesion and coupling.
The document discusses key concepts in software design including:
- Software design is an iterative process that translates requirements into a blueprint for constructing software through models.
- Models describe details like data structures, system architecture, interfaces and components.
- Design specifications include data, architectural, interface, procedural and component-level design.
- Fundamental concepts in design include abstraction, architecture, patterns, modularity, information hiding, and refinement.
The document discusses key concepts in software design including:
- Software design is an iterative process that translates requirements into a blueprint for constructing software through models.
- Models describe details like data structures, system architecture, interfaces and components.
- Design specifications include data, architectural, interface, procedural and component-level design.
- Fundamental concepts in design include abstraction, architecture, patterns, modularity, information hiding, and refinement.
Software design is a critical phase in the development of any software application, playing a pivotal role in its success and long-term sustainability.
This document discusses fundamentals of software engineering design. It explains that design creates a representation of software that provides implementation details beyond an analysis model. Four design models are described: data design, architectural design, user interface design, and component-level design. Design principles, concepts like abstraction and patterns are explained. Tools like CASE tools can support design, and evaluation ensures a quality design. A design specification document formally specifies the design.
The document discusses key concepts in software design including:
- The goals of software design are to transform customer requirements into a suitable implementation while meeting constraints like budget and quality.
- Design involves iterations through high-level, detailed, and architectural design phases to identify modules, interfaces, data structures, and algorithms.
- Good design principles include correctness, simplicity, adaptability, and maintainability. This involves modular and hierarchical decomposition.
- Techniques like top-down and bottom-up design, as well as object-oriented design, are used to arrive at a solution through abstraction layers.
software design is very crusial thing to manage therfore software 'software design is very crusial thing to manage therfore software software design is very crusial thing to manage therfore software software design is very crusial thing to manage therfore software
This document provides an overview of software design concepts and best practices. It discusses that software design transforms user requirements into a suitable form for programming and implementation. The key aspects covered include architectural design using structural, framework and dynamic models. It also discusses modularization which divides a software system into independent modules. Other design tools discussed are design structure charts, pseudocode, flowcharts, and the importance of low coupling between modules and high cohesion within modules.
object oriented programming part inheritance.pptxurvashipundir04
The document discusses the key concepts in C++ program development including the Program Development Life Cycle (PDLC), variables and data types, operators, control structures, functions, arrays, pointers, identifiers, and keywords. The PDLC follows an iterative process with phases like planning, analysis, design, implementation, testing, deployment and maintenance. Variables store data of built-in types like integers while functions perform tasks. Arrays store multiple elements in contiguous memory and pointers reference the memory locations of other variables. Identifiers name program elements and keywords are reserved words with special meanings.
The document discusses key concepts in software design including:
- The main activities in software design are data design, architectural design, procedural design, and sometimes interface design. Preliminary design transforms requirements into architecture while detail design refines the architecture.
- Data design develops data structures to represent information from analysis. Architectural design defines program structure and interfaces. Procedural design represents structural components procedurally using notations like flowcharts.
- Other concepts discussed include modularity, abstraction, software architecture, control hierarchy, data structures, and information hiding. Modular design, abstraction and information hiding help manage complexity. Software architecture and control hierarchy define program organization.
The document discusses various aspects of software design including:
1. The differences between design and programming and the role of a design engineer.
2. The iterative software design process of translating requirements into a blueprint for building software.
3. Key attributes like functionality, efficiency, flexibility, and usability that software design should address.
4. Fundamental software design concepts such as abstraction, architecture, modularity, and information hiding.
The document discusses software design engineering. It describes how the analysis model is translated into a design model through data/class design, architectural design, interface design, and component-level design. It outlines characteristics of good design such as readability, completeness, and exhibiting recognizable architectural styles/patterns. The document also discusses design concepts like abstraction, architecture/patterns, modularity, information hiding, and functional independence. It provides examples of procedural and data abstraction, and the refinement process.
UNIT 3-DEMONSTRATING A COMPREHENSIVE UNDERSTANDING OF SOFTWARE DESIGN.pptxLeahRachael
This document outlines key concepts in software design, including:
- The three types of design activities are external, architectural, and detailed design.
- Fundamental design concepts include abstraction, information hiding, structure, modularity, concurrency, verification, and aesthetics.
- Modules should have loose coupling and high cohesion. Design notations include data flow diagrams and structure charts.
The document discusses object-oriented design and its role in software development. It describes how design builds upon analysis to provide implementation details. Key aspects of object-oriented design include defining a multilayered architecture, specifying subsystems and components, describing classes and objects, and defining communication mechanisms. The input to design comes from artifacts created in analysis like use cases and class models. The output of design serves as a blueprint to guide construction.
The document discusses key principles of software design including data design, architectural design, user interface design, abstraction, refinement, modularity, software architecture, control hierarchy, structural partitioning, software procedure, and information hiding. These principles provide a foundation for correctly designing software and translating analysis models into implementable designs.
Presentation covers all aspects about Software Designing that are followed by Software Engineering Industries. Readers can do detailed study about the Software Design Concepts like (Abstraction, Architecture, Patterns, Modularity, Information Hiding, Refinement, Functional Dependence, Cohesion, Coupling & Refactoring) plus Design Process.
Later then Design Principles are there to understand with Architectural Design, Architectural Styles, Data Centered Architecture, Data Flow Architecture, Call & Return Architecture, Object Oriented Architecture, Layered Architecture with other architectures are named at end of it.
Later then, Component Level Design is discussed. Then after UI Design & Rules of it, UI Design Models, Web Application Design, WebApp Interface Design are discussed at the end.
Comment back if you have any query about it.
This document discusses key concepts and principles of software design. It explains that software design transforms analysis models into a design model through activities like architectural design, interface design, data design, and component-level design. Some key design concepts discussed include abstraction, refinement, modularity, architecture, procedures, and information hiding. The document also covers principles of effective modular design such as high cohesion and low coupling between modules. Different types of cohesion and coupling are defined. Overall, the document provides an overview of the software design process and some fundamental concepts involved.
The document summarizes key aspects of architectural design for software systems. It defines software architecture as the structure of system components and relationships between them. Architecture is important for analyzing design effectiveness, considering alternatives, and managing risks. Key architectural styles described include data-centered, data flow, call and return, object-oriented, and layered. The document also discusses defining architectural context diagrams, archetypes, and components to design system architecture.
The document discusses various middleware technologies used in distributed systems. It describes two-tier and three-tier architectures, and compares them. It then explains concepts like Remote Method Invocation (RMI), JavaBeans, Enterprise JavaBeans (EJB), Common Object Request Broker Architecture (CORBA), and how they enable communication between distributed components and objects across different platforms and languages.
Software design is the process of envisioning and defining software solutions to one or more sets of problems. One of the main components of software design is the software requirements analysis (SRA).
The document discusses various middleware technologies in Java. It covers Java-based component models like JavaBeans, RMI, RMI-IIOP and EJB. It describes the features of JavaBeans like events, properties, introspection, customization and persistence. It also discusses RMI and how it facilitates distributed object computing. CORBA is introduced as a standard that supports interoperability across different languages.
The document discusses key concepts in software design including:
- The goals of software design are to transform customer requirements into a suitable implementation while meeting constraints like budget and quality.
- Design involves iterations through high-level, detailed, and architectural design phases to identify modules, interfaces, data structures, and algorithms.
- Good design principles include correctness, simplicity, adaptability, and maintainability. This involves modular and hierarchical decomposition.
- Techniques like top-down and bottom-up design, as well as object-oriented design, are used to arrive at a solution through abstraction layers.
software design is very crusial thing to manage therfore software 'software design is very crusial thing to manage therfore software software design is very crusial thing to manage therfore software software design is very crusial thing to manage therfore software
This document provides an overview of software design concepts and best practices. It discusses that software design transforms user requirements into a suitable form for programming and implementation. The key aspects covered include architectural design using structural, framework and dynamic models. It also discusses modularization which divides a software system into independent modules. Other design tools discussed are design structure charts, pseudocode, flowcharts, and the importance of low coupling between modules and high cohesion within modules.
object oriented programming part inheritance.pptxurvashipundir04
The document discusses the key concepts in C++ program development including the Program Development Life Cycle (PDLC), variables and data types, operators, control structures, functions, arrays, pointers, identifiers, and keywords. The PDLC follows an iterative process with phases like planning, analysis, design, implementation, testing, deployment and maintenance. Variables store data of built-in types like integers while functions perform tasks. Arrays store multiple elements in contiguous memory and pointers reference the memory locations of other variables. Identifiers name program elements and keywords are reserved words with special meanings.
The document discusses key concepts in software design including:
- The main activities in software design are data design, architectural design, procedural design, and sometimes interface design. Preliminary design transforms requirements into architecture while detail design refines the architecture.
- Data design develops data structures to represent information from analysis. Architectural design defines program structure and interfaces. Procedural design represents structural components procedurally using notations like flowcharts.
- Other concepts discussed include modularity, abstraction, software architecture, control hierarchy, data structures, and information hiding. Modular design, abstraction and information hiding help manage complexity. Software architecture and control hierarchy define program organization.
The document discusses various aspects of software design including:
1. The differences between design and programming and the role of a design engineer.
2. The iterative software design process of translating requirements into a blueprint for building software.
3. Key attributes like functionality, efficiency, flexibility, and usability that software design should address.
4. Fundamental software design concepts such as abstraction, architecture, modularity, and information hiding.
The document discusses software design engineering. It describes how the analysis model is translated into a design model through data/class design, architectural design, interface design, and component-level design. It outlines characteristics of good design such as readability, completeness, and exhibiting recognizable architectural styles/patterns. The document also discusses design concepts like abstraction, architecture/patterns, modularity, information hiding, and functional independence. It provides examples of procedural and data abstraction, and the refinement process.
UNIT 3-DEMONSTRATING A COMPREHENSIVE UNDERSTANDING OF SOFTWARE DESIGN.pptxLeahRachael
This document outlines key concepts in software design, including:
- The three types of design activities are external, architectural, and detailed design.
- Fundamental design concepts include abstraction, information hiding, structure, modularity, concurrency, verification, and aesthetics.
- Modules should have loose coupling and high cohesion. Design notations include data flow diagrams and structure charts.
The document discusses object-oriented design and its role in software development. It describes how design builds upon analysis to provide implementation details. Key aspects of object-oriented design include defining a multilayered architecture, specifying subsystems and components, describing classes and objects, and defining communication mechanisms. The input to design comes from artifacts created in analysis like use cases and class models. The output of design serves as a blueprint to guide construction.
The document discusses key principles of software design including data design, architectural design, user interface design, abstraction, refinement, modularity, software architecture, control hierarchy, structural partitioning, software procedure, and information hiding. These principles provide a foundation for correctly designing software and translating analysis models into implementable designs.
Presentation covers all aspects about Software Designing that are followed by Software Engineering Industries. Readers can do detailed study about the Software Design Concepts like (Abstraction, Architecture, Patterns, Modularity, Information Hiding, Refinement, Functional Dependence, Cohesion, Coupling & Refactoring) plus Design Process.
Later then Design Principles are there to understand with Architectural Design, Architectural Styles, Data Centered Architecture, Data Flow Architecture, Call & Return Architecture, Object Oriented Architecture, Layered Architecture with other architectures are named at end of it.
Later then, Component Level Design is discussed. Then after UI Design & Rules of it, UI Design Models, Web Application Design, WebApp Interface Design are discussed at the end.
Comment back if you have any query about it.
This document discusses key concepts and principles of software design. It explains that software design transforms analysis models into a design model through activities like architectural design, interface design, data design, and component-level design. Some key design concepts discussed include abstraction, refinement, modularity, architecture, procedures, and information hiding. The document also covers principles of effective modular design such as high cohesion and low coupling between modules. Different types of cohesion and coupling are defined. Overall, the document provides an overview of the software design process and some fundamental concepts involved.
The document summarizes key aspects of architectural design for software systems. It defines software architecture as the structure of system components and relationships between them. Architecture is important for analyzing design effectiveness, considering alternatives, and managing risks. Key architectural styles described include data-centered, data flow, call and return, object-oriented, and layered. The document also discusses defining architectural context diagrams, archetypes, and components to design system architecture.
The document discusses various middleware technologies used in distributed systems. It describes two-tier and three-tier architectures, and compares them. It then explains concepts like Remote Method Invocation (RMI), JavaBeans, Enterprise JavaBeans (EJB), Common Object Request Broker Architecture (CORBA), and how they enable communication between distributed components and objects across different platforms and languages.
Software design is the process of envisioning and defining software solutions to one or more sets of problems. One of the main components of software design is the software requirements analysis (SRA).
The document discusses various middleware technologies in Java. It covers Java-based component models like JavaBeans, RMI, RMI-IIOP and EJB. It describes the features of JavaBeans like events, properties, introspection, customization and persistence. It also discusses RMI and how it facilitates distributed object computing. CORBA is introduced as a standard that supports interoperability across different languages.
Similar to Software Engineering - SOFTWARE DESIGN Process (20)
Software Engineering REQUIREMENTS ANALYSIS AND SPECIFICATIONDr Anuranjan Misra
Software Requirements: Functional and Non-Functional, User requirements, System requirements, Software Requirements Document – Requirement Engineering Process: Feasibility Studies, Requirements elicitation and analysis, requirements validation, requirements management-Classical analysis: Structured system Analysis, Petri Nets- Data Dictionary
How to Setup Warehouse & Location in Odoo 17 InventoryCeline George
In this slide, we'll explore how to set up warehouses and locations in Odoo 17 Inventory. This will help us manage our stock effectively, track inventory levels, and streamline warehouse operations.
Level 3 NCEA - NZ: A Nation In the Making 1872 - 1900 SML.pptHenry Hollis
The History of NZ 1870-1900.
Making of a Nation.
From the NZ Wars to Liberals,
Richard Seddon, George Grey,
Social Laboratory, New Zealand,
Confiscations, Kotahitanga, Kingitanga, Parliament, Suffrage, Repudiation, Economic Change, Agriculture, Gold Mining, Timber, Flax, Sheep, Dairying,
This presentation was provided by Racquel Jemison, Ph.D., Christina MacLaughlin, Ph.D., and Paulomi Majumder. Ph.D., all of the American Chemical Society, for the second session of NISO's 2024 Training Series "DEIA in the Scholarly Landscape." Session Two: 'Expanding Pathways to Publishing Careers,' was held June 13, 2024.
A Visual Guide to 1 Samuel | A Tale of Two HeartsSteve Thomason
These slides walk through the story of 1 Samuel. Samuel is the last judge of Israel. The people reject God and want a king. Saul is anointed as the first king, but he is not a good king. David, the shepherd boy is anointed and Saul is envious of him. David shows honor while Saul continues to self destruct.
1. Software Engineering
KCS-601, Unit-III
Dr APJ Abdul Kalam Technical
University, Lucknow
By
Dr Anuranjan Misra
1
Dr Anuranjan Misra
innovation
Ambassador
Ministry of Education,
Government of India
& Professor & Dean,
GNIOT, Greater
Noida
3. Software design and implementation
The process of converting the system
specification into an executable system.
Software design
• Design a software structure that realises the
specification;
• Design a software structure that realises the
specification;
Implementation
• Translate this structure into an executable
program;
The activities of design and implementation are
closely related and may be inter-leaved.
4.
5. The Design Phase
High-level (architectural) design consists
of developing an architectural structure for
software programs, databases, the user
software programs, databases, the user
interface, and the operating environment.
Low-level (detailed) design entails
developing the detailed algorithms and
data structures that are required for
program development.
6.
7.
8.
9.
10. The Implementation Phase
Primary objectives are to ensure that:
System is built, tested and installed (actual
programming of the system)
The implementation phase includes five
The implementation phase includes five
activities:
Construct software components
Verify and test
Develop prototypes for tuning
Train and document
Install the system
11. Design
Designer plans to produce a s/w system such that it is
• Functional
• Reliable
• Easy to understand, modify, & maintain
SRS manifested with functional, information, and
SRS manifested with functional, information, and
behavioral models feed the design process.
Design produces
• Data Design
• Architecture Design
• Procedural Design
• Interface Design
13. Design Models ?
Data Design
• created by transforming the data dictionary and ERD into
implementation data structures.
• requires as much attention as algorithm design.
Architectural Design
• Defines relationship b/w structural elements of the s/w.
• Defines relationship b/w structural elements of the s/w.
• derived from the analysis model and the subsystem interactions
defined in the DFD.
Interface Design
• derived from DFD and CFD and describes communication of
software elements with other software elements, other systems,
and human users.
Procedural Design
• Transforms structural elements into procedural description.
14. The Software Design Process
R
equir
ements
specifica
tion
Design acti
vities
Ar
chitectur
al
design
Abstr
act
specifica
tion
Inter
face
design
Component
design
Da
ta
structur
e
design
Algorithm
design
System
architectur
e
Softw
are
specifica
tion
Inter
face
specifica
tion
Component
specifica
tion
Da
ta
structur
e
specifica
tion
Algorithm
specifica
tion
Design pr
oducts
15. Architectural Design
Layered Architecture Example (UNIX)
• Core Layer Kernel
• Utility Layer System Calls
• Application Layer Shell & Library routines
• User Interface Layer User Application
Data Centered Architecture: Central database is processed
through other components which add, delete, and update the
data.
Data Flow Architecture: Applied when input data is to be
transformed into output data through a series of components.
Generally uses concepts of pipes and filters.
Object Oriented Architecture: Data and operations
encapsulated together and communication among objects is
through message passing.
20. Importance of Design
Design is a phase where quality is fostered.
Without proper design we risk building an unstable
software.
Design acts as a foundation for all subsequent
Design acts as a foundation for all subsequent
phases.
22. What is a Module?
A lexically contiguous sequence of program
statements, bounded by boundary elements, with
an aggregate identifier.
• “Lexically contiguous”
• “Lexically contiguous”
• Adjoining in the code
• “Boundary elements”
• { ... }
• begin ... end
• “Aggregate identifier”
• A name for the entire module
23.
24. Modularity
Attribute of the s/w that allows it to be
managed intellectually.
A monolithic s/w can’t be easily grasped by a
reader
Degree of Modularity
Cost
of
Efforts
Cost to module
Cost to
Interface
Overall efforts
25. Modularity
Attribute of s/w that allows it to be managed intellectually. A
monolithic s/w can not be grasped by a reader easily.
Therefore, it is easier to solve a complex problem by dividing
it into manageable pieces (modules).
C(x): perceived complexity of the problem
C(x): perceived complexity of the problem
E(x): Effort required to solve the problem
For two problems P1 and P2
If C(P1) > C(P2) Then E(P1) > E(P2)
Also it has been observed that
C(P1)+C(P2) < C(P1+P2)
It therefore, follows that
E(P1)+E(P2) < E(P1+P2)
26. Control Hierarchy
Organization of program components is depicted
through
• Depth and Width of the structure (graph)
representing
representing
• Number of levels of control.
• and overall span of control.
• Concept of FAN-IN and FAN-OUT.
• Concept of Super ordinate and subordinate
modules.
• Concept of Visibility and Connectivity.
33. Coupling
The degree of interaction between two modules.
• Seven categories or levels of coupling
1. No direct coupling (Good)
1. No direct coupling (Good)
2. Data coupling
3. Stamp coupling
4. Control coupling
5. External coupling
6. Common coupling
7. Content coupling (Bad)
34. Content Coupling
Two modules are content coupled if one module
directly modifies content or branches into the
middle of the other module.
Examples:
• Module p modifies a statement of module q.
• Module p modifies a statement of module q.
• Module p refers to local data of module q in
terms of some numerical displacement within q.
• Module p branches into a local label of module q.
Why is Content Coupling So Bad?
Almost any change to module q, requires a change
to module p
36. Common Coupling
Two modules are common coupled if they share
or have write access to the global data.
Example 1:
• Modules cca and ccb can access and change the
value of global_variable
value of global_variable
37. Common Coupling (contd)
Example 2:
• Modules cca and ccb both have access to the same
database, and can both read and write the same record
Example 3:
• FORTRAN common
• COBOL common (nonstandard)
• COBOL-80 global
• C extern
39. External Coupling
Two modules are externally related by a common
data structure or device format etc.
A form of coupling in which a module has a
dependency to other module, external to the
dependency to other module, external to the
software being developed or to a particular type of
hardware.
This is basically related to the communication to
external tools and devices.
40. Control Coupling
Two modules are control coupled if one module
controls the other by passing control flag as
parameter to the other.
Example:
Example:
• A control switch passed as an argument.
41. Stamp Coupling
Some languages allow only simple variables as parameters
• part_number
• satellite_altitude
• degree_of_multiprogramming
Many languages also support the passing of data
Many languages also support the passing of data
structures
• part_record
• satellite_coordinates
• segment_table
Two modules are stamp coupled if a data structure is
passed as a parameter, but the called module operates on
some but not all of the individual components of the data
structure.
42. Data Coupling
Two modules are data coupled if all parameters are
homogeneous data items (simple parameters, or
data structures all of whose elements are used by
called module)
Examples:
• display_time_of_arrival (flight_number);
• compute_product (first_number, second_number);
• get_job_with_highest_priority (job_queue);
43. Coupling Values
Sr. No. Type of Coupling Value
1. Content Coupling 0.95
2. Common Coupling 0.70
3. External Coupling 0.60
3. External Coupling 0.60
4. Control Coupling 0.50
5. Stamp Coupling 0.35
6. Data Coupling 0.20
7. No Direct Coupling 0.00
44. Cohesion
The degree of interaction within a module. A
measure of the degree to which the elements of a
module are functionally related.
Seven categories or levels of cohesion
1. Functional cohesion (good)
1. Functional cohesion (good)
2. Sequential cohesion
3. Communicational cohesion
4. Procedural cohesion
5. Temporal cohesion
6. Logical cohesion
7. Coincidental cohesion (bad)
46. Coincidental Cohesion
Coincidental cohesion exists in modules containing
instructions that have little or no relationship to one another.
A module has coincidental cohesion if it performs multiple,
completely unrelated functions/actions.
X and Y have no conceptual relationship.
X and Y have no conceptual relationship.
Example: Module checks user security,authenticates and
also prints monthly payrol.
• print_next_line, reverse_string_of_characters_comprising_second_
parameter, add_7_to_fifth_parameter,
convert_fourth_parameter_to_ floating_point
It’s BAD BECAUSE:
It degrades maintainability.
A module with coincidental cohesion is not reusable.
47. Logical Cohesion
A module has logical cohesion when it performs a
series of logically related actions, one of which is
selected by the calling module.
Example 1:
• An object performing all inputs irrespective of the device
• An object performing all inputs irrespective of the device
it is coming from or the nature of use of the data.
Example 2:
• For more than one data items of type date in an input
transaction, separate code would be written to check that
each date is a valid date.
• A better way is to construct a DATECHECK module and
call it wherever necessary.
48. Temporal Cohesion
A module has temporal cohesion when it performs a
series of actions related in time. May be performed in
the same time span.
Example:
• open_old_master_file, new_master_file, transaction_file,
• open_old_master_file, new_master_file, transaction_file,
and print_file; initialize_sales_district_table,
read_first_transaction_record,
read_first_old_master_record (a.k.a. perform_initialization)
• The set of functions responsible for initialization, setting
start up values such as setting program counter or control
flags exhibit temporal cohesion. They should not be put in
the same function.
49. Procedural Cohesion
A module has procedural cohesion if it performs a
series of actions related by the procedure to be
followed by the product.
The two components X and Y are structured the
same way.
same way.
Example:
• Data entry, Checking, and manipulation are
three functions but performed in a proper
sequence.
• Calculate student GPA, print student record,
calculate cumulative GPA, Print cumulative GPA
50. A module has communicational cohesion if it performs a
series of actions related by the procedure to be followed
by the product, but in addition all the actions operate on
the same data
Two components operate on the same input data or
Communicational Cohesion
Two components operate on the same input data or
contribute to the same output data.
X and Y operate on the same i/p data or contribute to
same o/p data.
Example 1: Fetching of unrelated data from tape or disk
because it requires only one access.
Example 2:
calculate_new_coordinates_and_send_them_to_terminal
51. Functional Cohesion
A module with functional cohesion performs exactly
one action
X and Y are part of the same functional task.
Example 1:
Example 1:
• get_temperature_of_furnace
Example 2:
• compute_orbital_of_electron
Example 3:
• write_to_floppy_disk
Example 4:
• calculate_sales_commission
52. Sequential Cohesion
More than one functions performed by the module
occur in an order prescribed by the specifications.
X outputs some data which forms the input to Y.
X outputs some data which forms the input to Y.
54. Design Strength
Dependence Matrix
• Depicts quantitative measure of dependence of
modules.
• Used to find strength of design.
• Used to find strength of design.
• Primarily affected by the coupling and
cohesion.
• Gives the probability of having to change
module i given that module j is changed.
• First order dependence and complete
dependence matrix are found.
55. First Order Dependence Matrix
Represent coupling among various modules by a coupling matrix
C which will be symmetric i.e. Ci,j = Cj,I and diagonal elements
will be 1 i.e. Ci,i = 1.
Represent strength of various modules by the strength vector S.
FODM is constructed by the following formula
Di,j = 0.15*(Si+Sj)+0.7*Ci,j
Di,j = 0.15*(Si+Sj)+0.7*Ci,j
= 0 where Ci,j = 0
= 1 where Ci,j = 1
FODM can be represented by a undirected graph having
links labeled with the dependence values.
Initial connectivity status of modules can also be depicted by
a undirected graph having links assigned the coupling value
and nodes the strength value.
FODM does not give a clear picture of dependence because
it is not able to incorporate indirect connectivity.
57. Observation about FODM
Probability that module 3 changes if module 1 is changed
is not simply 0.2 as given by FODM .
This probability will be in fact higher than 0.2 because
change in module 1 leads to a change in 4 which in turn
leads to a change in 8. A change in 8 due to external
leads to a change in 8. A change in 8 due to external
coupling leads to a change in 7 due to external coupling 7
which leads to a change in 3.
FODM depicts that there is no dependence b/w module 1
and 9 which is really not correct.
Infact there is a dependence among all module but the
level of dependence may be high or low.
Due to this reason, a Complete Dependence Matrix
(CDM) is required for stability analysis of a program.
58. Complete Dependence Matrix
CDM is obtained by finding out all unique paths from
one module to all other modules.
Because these paths may not be mutually exclusive
to each other, hence addition law of probability is
not directly applicable.
not directly applicable.
IF there are three unique paths to B from A labeled
as x, y, and z respectively with probabilities as P(x),
P(y), and P(z) THEN
P(B changing) = P(x) + P(y) + P(z) - P(x)*P(y)
- P(y)*P(z) - P(x)*P(z) + P(x)*P(y)*P(z)
59. Undirected Graph & FODM
A B C D
A 1.0 0.4 0.3 0.0
B 0.4 1.0 0.4 0.5
C 0.3 0.4 1.0 0.2
D 0.0 0.5 0.2 1.0
60. Finding CDM
Assume that A changes, probability of B changing is not
0.4 as shown by FODM but is higher than this.
There are three possible chances of B changing as
there are three paths to B from A.
Probabilities of these paths are
Probabilities of these paths are
• P(x: A to B) = 0.4
• P(y: A to C to B) = 0.3 x 0.4 = 0.12
• P(z: A to C to D to B) = 0.3 x 0.2 x 0.5 = 0.030
P(B Changing)= (0.4+0.12+0.030) - (0.4x0.12) -
(0.12x0.030) - (0.4x0.030) + (0.4x0.12x0.030) = 0.4878
In similar way other probabilities and hence CDM can
be obtained.
61. Strength Measures
CDM can be used to find the following measures
• Expected Change Measure (ECM) which gives
a probability of changing the number of modules
if a particular module changes.
ECMi = ΣDi,j where i and j are not equal.
ECMi = ΣDi,j where i and j are not equal.
• Overall Design Measure (ODM) which gives the
expected number of modules to be changed
given a module changes.
ODM = Σ Σ Di,j /m for i,j = 1 to m
62. Design of Computer
A highly incompetent
computer architect
decides to build an
ALU, shifter, and 16
registers with AND,
registers with AND,
OR, and NOT gates,
rather than NAND or
NOR gates.
Figure 7.1
63. Design of Computer (contd..)
The architect
designs 3
silicon chips
Figure 7.2
64. Design of Computer (Contd..)
Redesign with
one gate type per
chip.
Resulting
Resulting
“masterpiece”.
Figure 7.3
65. Computer Design (contd)
The two designs are functionally equivalent but the
second design is
• Hard to understand.
• Hard to locate faults.
• Difficult to extend or enhance.
• Cannot be reused in another product.
Modules must be like the first design
• Maximal relationships within modules, and
• Minimal relationships between modules.
66.
67.
68.
69.
70.
71. Software Development Approaches
The past
Procedural programs
Deterministic execution
Program in control
The present
Interactive program
Event-driven execution
Objects
72. Structured Approach
Systematic approaches to develop a software
design.
The design is usually documented as a set of
graphical models.
graphical models.
Possible models
• Object model;
• Sequence model;
• State transition model;
• Structural model;
• Data-flow model.
73. Structured approach
Modeling techniques
DFD
ERD
ERD
Problems
Sequential and transformational
Inflexible solutions
No reuse
74. Structured Approach
The structured paradigm was successful initially
but started to fail with larger products (> 50,000
LOC)
Post delivery maintenance problems (today, 70 to
80 percent of total effort)
80 percent of total effort)
Reason: Structured methods are
• Action oriented (e.g., finite state machines,
data flow diagrams); or
• Data oriented (e.g., entity-relationship
diagrams);
• But not both
84. Modules to Objects
Objects with high cohesion and low coupling
Objects
Information hiding
Information hiding
Abstract data types
Data encapsulation
Modules with high cohesion and low coupling
Modules
85. Object-Oriented approach
Data-centric
Event-driven
Addresses emerging applications
Follows iterative and incremental process
Follows iterative and incremental process
87. Strengths of the Object-Oriented
Paradigm
Information hiding reduces post-delivery maintenance due to
reduced chances of regression faults.
Development is easier because Objects generally have physical
counterparts and this simplifies the modeling process.
Well-designed objects are independent units as everything that
relates to the real-world object being modeled is encapsulated in
relates to the real-world object being modeled is encapsulated in
the object.
• Communication is by sending messages.
• Independence is enhanced by responsibility-driven design.
A classical product conceptually consists of a single unit and
hence complex. But, object-oriented paradigm reduces complexity
because the product generally consists of independent units.
The object-oriented paradigm promotes reuse of objects as they
are independent entities.
89. In More Details
Classical paradigm
2. Analysis (specification) phase
• Determine what the product is
to do
3. Design phase
• Architectural design
• Detailed design
4. Implementation phase
Object-Oriented paradigm
2. Object-Oriented Analysis workflow
• Determine what the product is to
do
• Extract the classes
3. Object-Oriented Design workflow
• Detailed design
4. Object-Oriented Implementation
Objects enter here
Modules (objects) are introduced as early as the object-oriented
analysis workflow.
• This ensures a smooth transition from the analysis workflow to
the design workflow
The objects are then coded during the implementation workflow
• Again, the transition is smooth
4. Implementation phase
• Code the modules in an
appropriate programming
language.
• Integrate the coded modules.
4. Object-Oriented Implementation
workflow
• Code the modules in an
appropriate OO prog. language.
• Integrate
90. Modeling Primitives
Objects
• an entity that has state, attributes and services.
• Interested in problem-domain objects for requirements
analysis.
Classes
• Provide a way of grouping objects with similar attributes or
services.
services.
• Classes form an abstraction hierarchy though ‘is_a’
relationships.
Attributes
• Together represent an object’s state.
• May specify type, visibility and modifiability of each attribute.
Relationships
• ‘is_a’ classification relations.
• ‘part_of’ assembly relationships.
• ‘associations’ between classes.
91. Modeling Primitives
Methods (services, functions)
• These are the operations that all objects in a class
can do when called on to do so by other objects
• E.g. Constructors/Destructors (if objects are
created dynamically)
created dynamically)
• E.g. Set/Get (access to the object’s state)
Message Passing
• How objects invoke services of other objects.
Use Cases/Scenarios
• Sequences of message passing between objects.
• Represent specific interactions.
92. Key Principles
Classification (using inheritance)
• Classes capture commonalities of a number of
objects.
• Each subclass inherits attributes and methods
from its parent.
from its parent.
• Forms an ‘is_a’ hierarchy
Child class may ‘specialize’ the parent class.
• by adding additional attributes & methods.
• by replacing an inherited attribute or method with
another.
Multiple inheritance is possible where a class is
subclass of several different super classes.
93. Key Principles
Information Hiding
• internal state of an object need not be visible to
external viewers.
• Objects can encapsulate other objects, and keep
their services internal.
their services internal.
Aggregation
• Can describe relationships between parts and the
whole objects.
94. UML Diagram Types (9)
These can be classified into 'static' and 'dynamic' diagrams.
• Static
Structure
• Class diagram
• Object diagram
Implementation
• Component diagram
• Deployment diagram
• Dynamic
Functionality
• Use Case diagram
Behavior
• Activity diagram
• State chart diagram
Interaction
• Collaboration
diagram
• Sequence diagram
System
Model
95. Parts of UML
Class Diagrams
• Structure models
Object Diagrams
• example models
Use Case Diagrams
Use Case Diagrams
• document who can do what in a system
Sequence Diagrams
• shows interactions between objects used to implement a
use case
Collaboration Diagrams
• same as sequence diagrams but in different style
96. Parts of UML (Cont…)
State chart Diagrams
• possible states and responses of a class and what transitions
them.
Activity Diagrams
• describe the behavior of a class in response to internal
• describe the behavior of a class in response to internal
processing.
Component Diagrams
• Organization of and dependencies amongst software
implementation components.
Deployment Diagrams
• Describe the mapping of software implementation components
onto processing nodes.
97. • A concept, abstraction, or thing with crisp
boundaries and meaning for the problem at
hand
• promote understanding of the real world
• provide a practical basis for computer
implementation
Object
implementation
98. Problem Decomposition
Decomposition of a problem into
objects depends on
• Judgment
• The nature of the problem being solved
• The nature of the problem being solved
• Not only the domain: two analyses of the same
domain will turn out differently depending upon the
kind of programs we wish to produce.
99. Classes
A class describes a group of objects
with similar properties.
• Class: Instructor
• Object: David Penny
• Object: David Penny
• Object: Matthew Zaleski
Instructor Department
100. Example
• Class: Department
• Object: Department of Computer Science
• Object: Department of Electrical Engineering
101. Attributes
Data values held by the objects of a class
Instructor
name: string
age: integer
weight: integer
102. Operations
A function or a transformation that may be
applied to or by objects in a class.
• Not often used (not often terribly useful) in an
OOA
Instructor
Instructor
name
age
weight
teach
mark
listen_to_complaints
103. Links and Associations
The means for establishing
relationships among objects and
classes.
• link: a connection between two object
• link: a connection between two object
instances
• association: a collection of links with
common structure and semantics.
Instructor Department
teaches for
104. Object Diagrams
Models instances of things contained in class
diagrams.
Shows a set of objects and their links at a
point in time
Useful preparatory to deciding on class
structures.
Useful in order to better explain more
complex class diagrams by giving instance
examples.
105. i: Instructor
name = “Penny”
: Department
name = “DCS”
name = “Penny”
j: Instructor
name = “Zaleski”
: Department
name = “ECE”
106. Multiplicity
Used to indicate the number of potential
instances involved in the association when the
other associated classes are fixed.
Instructor Department
teaches
for
A given instructor
can teach for
potentially many
departments or none)
A given department
employs zero or
more instructors
*
*
107. N-ary Associations
Instructor Department
teaches
1 1
A given instructor
teaching for a given
There is exactly
one instructor
Course
*
teaching for a given
department may
teach zero or more
courses for that
department.
one instructor
teaching a given
course for a given
department
Try to avoid them!
111. Example
We are asked to build a system for
keeping track of the time our workers
spend working on customer projects.
We divide projects into activities, and
We divide projects into activities, and
the activities into tasks. A task is
assigned to a worker, who could be a
salaried worker or an hourly worker.
Each task requires a certain skill, and
resources have various skills at various
level of expertise.
112. Steps
Analyze the written requirements
• Extract nouns: make them classes
• Extract verbs: make them associations
• Draw the OOA UML class diagrams
• Determine attributes
• Determine attributes
• Draw object diagrams to clarify class diagrams
113. Steps (contd..)
Determine the system’s use cases
• Identify Actors
• Identify use case
• Relate use cases
Draw sequence diagrams
Draw sequence diagrams
• One per use case
• Use to assign responsibilities to classes
Add methods to OOA classes
114. Example
We are asked to build a system for
keeping track of the time our workers
spend working on customer projects.
Customer
Worker
Customer
Project
Time
spends *
1
*
*
*
*
*
1
contracts
115. Example
We divide projects into activities, and
the activities into tasks. A task is
assigned to a worker, who could be a
salaried worker or an hourly worker.
salaried worker or an hourly worker.
Project
Worker
SalariedWorker HourlyWorker
Activity
1..*
Task
1..*
*
1
Assignment
Time
spent on ◄
116. Example
Each task requires a certain skill, and
workers have various skills at various
level of expertise.
Worker
Skill
Task
requires
◄
ha
s
SkillLevel
1..*
*
*
1..*
117. Steps
Analyze the written requirements
• Extract nouns: make them classes
• Extract verbs: make them associations
• Draw the OOA UML class diagrams
• Determine attributes
• Determine attributes
• Draw object diagrams to clarify class diagrams
Determine the system’s use cases
• Identify Actors
• Identify use case
• Relate use cases
120. Example
Task
Activity
Constraint: A task may only
be assigned to a worker who
has the required skill.
description
startDate: date
estHours: int
Skill
Worker
requires
assigned to
has
123. Steps
Analyze the written requirements
• Extract nouns: make them classes
• Extract verbs: make them associations
• Draw the OOA UML class diagrams
• Determine attributes
• Draw object diagrams to clarify class diagrams
Determine the system’s use cases
• Identify Actors
• Identify use case
• Relate use cases
Draw sequence diagrams
• One per use case
• Use to assign responsibilities to classes
Add methods to OOA classes
125. Steps
Analyze the written requirements
• Extract nouns: make them classes
• Extract verbs: make them associations
• Draw the OOA UML class diagrams
• Draw object diagrams to clarify class diagrams
• Determine attributes
• Determine attributes
Determine the system’s use cases
• Identify Actors
• Identify use case
• Relate use cases
Draw sequence diagrams
• One per use case
• Use to assign responsibilities to classes
Add methods to OOA classes
126. Use Cases
Actors:
• Represent users of a system
• human users
• other systems
Use cases
• Represent functionality or services
provided by a system to its users
127. Use Case Diagrams
Time & Resource Management System
(TRMS)
resource
manager
Manage
Resources
Manage
project
manager
manager
worker
<<actor>>
Backup
System
Log Time
Manage
Projects
Administer
System
system
administrator
129. More Resource Manager Use
Cases
Add
Worker
Remove
Worker
Find
Worker
<<uses>>
resource
manager
Update
Worker
Find
Skill
<<uses>>
Assign Skill
to Worker
Unassign Skill
from Worker
<<extends>>
130. Steps
Analyze the written requirements
• Extract nouns: make them classes
• Extract verbs: make them associations
• Draw the OOA UML class diagrams
• Draw object diagrams to clarify class diagrams
• Determine attributes
• Determine attributes
Determine the system’s use cases
• Identify Actors
• Identify use case
• Relate use cases
Draw sequence diagrams
• One per use case
• Use to assign responsibilities to classes
Add methods to OOA classes
131. Sequence Diagram – Assign Skill to
Worker Use Case
resource
manager
Res. Mgr. Win: UI :Worker :Skill :SkillLevel
find worker
find worker
find skill
assign skill
to worker
find worker
by name
find skill by name
[worker does not currently have skill]
assign skill to worker
132. Steps
Analyze the written requirements
• Extract nouns: make them classes
• Extract verbs: make them associations
• Draw the OOA UML class diagrams
• Draw object diagrams to clarify class diagrams
• Determine attributes
• Determine attributes
Determine the system’s use cases
• Identify Actors
• Identify use case
• Relate use cases
Draw sequence diagrams
• One per use case
• Use to assign responsibilities to classes
Add methods to OOA classes
133. Add Methods
Read sequence diagrams to identify necessary
methods
Worker
Worker
name: string
+ static Worker findWorker(String name);
+ static list of Workers getWorkers();
134. In Design
Bring methods closer to implementation
Worker
name: string
name: string
+ static Worker findWorker(String name);
+ static int getNWorkers();
+ static Worker getWorker(int);
135. In Design
Bring methods closer to implementation
WorkList
Int getNumListElements(); ListModel
Worker
name: string
+ static Worker findWorker(String name);
Int getNumListElements();
String getListElement(int n);
ListModel
int getNumListElements();
String getListElement(int n);
136. Software Measurement
Software Measurement: Quantitative
determination of an attribute of the software.
Why to Measure the Software ?
Why to Measure the Software ?
To gain insight by providing mechanisms for
objective evaluation.
To improve understanding of particular entities
and attributes.
137. Developers measure software to check whether
Requirements are consistent and complete.
Design is of high quality.
Code is ready to be tested.
Project Managers measure software to
Decide about delivery date (Schedule).
Software Measurement
Decide about delivery date (Schedule).
Check the Budget.
Evaluate Attributes of process and product.
Customers measure software to check
Whether Requirements are met ?
Quality of the product.
Attributes of the final product.
Maintainers measure software to decide
What to be up-graded and improved ?
Aspects of adaptability.
138. Software Measurement Objectives
Indicate quality of the Software.
Assess the productivity of the people.
Assess benefits derived from new methods
and tools.
and tools.
Form baseline for future estimation.
Justifications for new tools and training.
To ensure control in project management.
“You can not control what you can not measure”
- DeMarco (1982)
139. What to Measure ?
Size
Complexity
Reliability
Quality
Coupling and Cohesion
Cost
Duration
Efforts
141. Function Point Equation
FP = T * (0.65 + 0.01 * Q)
Where T = unadjusted table total
Q = score from questionnaire
Q = score from questionnaire
(14 items with values 0 to 5)
Cost of producing one function point? May be
organization specific.
142. Function Point Questionnaire
1. Backup.
2. Data communication.
3. Distributed processes.
4. Optimal performance.
9. Complex inputs,
queries, outputs.
10. Complex internal
processing.
11. Reusable code.
5. Heavily used
operating system.
6. On-line data security.
7. Multiple screens.
8. On-line master file
update.
11. Reusable code.
12. Conversion or
installation.
13. Multiple user sites.
14. Ease of use.
143. Halstead’s Software Science
Assumptions
complete algorithm specification exist
programmer works alone
programmer knows what to do
programmer knows what to do
Based on counting of
n1 = # of unique operators
n2 = # of unique operands
N1 = # of occurrences of operators
N2 = # of occurrences of operands
144. Halstead Equations
Program Vocabulary (n) = n1+n2
Program Length (N) = N1+N2
Program Length (N) = n1* log2 (n1) + n2* log2 (n2)
Program Volume (V) = N* log2 (n)
Program Volume (V) = N* log2 (n)
Program Level (L) = V*/V = (2/n1)*(n2/N2)
Effort (E) = V/L = V2 /V*=V*[(n1*N2)/(2*n2)]
Language Level (l) = LV* (Constant)
Time (T)= E/B where B = (18) 5 to 20
148. Calculations (Example2)
n1 = 11 (BEGIN_END readln () , ; IF-THEN-ELSE
> := + writeln .)
n2 = 5 (a b c d m)
N1 = 22 (1+1+2+3+2+2+2+3+4+1+1)
N1 = 22 (1+1+2+3+2+2+2+3+4+1+1)
N2 = 19 (3+6+4+2+4)
V = 41*log(11+5) = 164
E = 164*[(11*19)/(2*5)] = 3427
149. Halstead Modified Theory
Certain operators and operands which are part of
control statements contribute extra in the count value.
Assign weights so that measures can reflect complexity
produced by the non sequential control structures.
Nw =Σx in T [1+µ(x)*{L(x)+Adw(x)}]
Nw1 =Σx in T [1+µ(x)*{L(x)+Adw(x)}]
Nw2 =Σx in R [1+µ(x)*{L(x)+Adw(x)}]
Where µ(x) = 1 if x is the part of control statement
= 0 otherwise
L(x) is the level of the statement and Adw(x) is the
additional weight assigned depending on the number of
test conditions checked for taking decision.
150. Calculations (Example2)
n1 = 11 (BEGIN_END readln () , ; IF-THEN-ELSE >
:= + writeln . )
n2 = 5 (a b c d m)
Nw1 = N1+6 = 28
Nw1 = N1+6 = 28
Nw2 = N2+6 = 25
Vw = 53*log(11+5) = 212
Ew = 212*[(11*25)/(2*5)] = 5830
152. Cyclomatic Complexity
Cyclomatic complexity of the program is computed
from its flow graph using the formula
• CC(G) = E – N + 2*k where k is number of
connected components.
connected components.
• CC(G)=P+1 where P is the number of predicate
nodes which can be counted by the conditional
statements in the PDL representation.
• CC(G)= R+1 where R is the number of closed
regions in the flow graph.
153. Basis Path Testing
Determine the basis set of linearly independent
paths.
Cardinality of this set is the program cyclomatic
complexity
Prepare test cases that will force the execution
of each path in the basis set.