7.

1 The Software Engineering Discipline

Definition and Scope

Software Engineering: The branch of computer science that seeks principles to guide the
development of large, complex software systems.

Important Note: Problems in developing large software systems are NOT just enlarged
versions of small program problems. They involve fundamentally different challenges
including:

• Multi-person collaboration requirements

• Extended development timeframes
• Changing requirements during development
• Personnel turnover during projects
• Management and coordination needs

Broader Scope: Software engineering includes topics traditionally associated with business
management (personnel management, project management) rather than just computer
science.

Understanding the Complexity

Analogy Approach: To appreciate software engineering problems, consider designing and

supervising construction of:

• An automobile
• A multi-storey office building
• A cathedral

Key Questions That Must Be Answered:

Question Category Specific Challenges

Cost Estimation How to estimate time, money, and other resources needed?
Project Division How to divide project into manageable pieces?
Compatibility How to ensure pieces are compatible?
Communication How to enable communication between workers?
Progress
How to measure and track progress?
Measurement
How to cope with wide range of details (doorknobs to structural
Detail Management
pillars)?

Critical Point: These same scope questions must be answered during large software system
development.
Fundamental Differences from Traditional Engineering

1. Prefabricated Components Problem

Traditional Engineering Advantage:

• Uses "off-the-shelf" components as building blocks

• Example: Automobile designer uses previously designed engines and transmissions
• Reduces development time and cost
• Leverages proven, tested components

Software Engineering Challenge:

• Historically, complex software systems built from scratch

• Previously designed components were domain specific
o Domain specific = internal design based on specific application
o Limited use as generic components
o Not easily transferable to other contexts

Current Status:

• Significant progress being made

• More work remains to be done
• Object-oriented programming helping address this issue

Impact: Lack of reusable components means:

• Higher development costs

• Longer development times
• More opportunities for errors
• Repeated solving of similar problems

2. Metrics Problem

Definition of Metrics: Quantitative techniques for measuring properties of software

The Challenge:

Traditional Engineering Software Engineering

Can measure physical properties (stress, Cannot easily measure "complexity" of
temperature, voltage) software
Can measure mean time between failures (wear- Software doesn't "wear out" - different
based) failure modes
Quality measures are evasive and
Has established quality measures
subjective

Why This Matters:

 • Cannot accurately project development costs without complexity measures
• Cannot objectively evaluate software quality
• Difficult to compare different design approaches
• Hard to justify resource allocation decisions

Example Problem: How do you measure if one program design is "better" than another
when you can't quantify complexity?

3. Foundational Science Problem

Traditional Engineering Foundation:

• Mechanical engineering: Based on physics

• Electrical engineering: Based on physics and electromagnetic theory
• Chemical engineering: Based on chemistry
• Result: Rigorous, mathematical foundation

Software Engineering Challenge:

• Still searching for fundamental theoretical roots

• Lacks rigorous mathematical foundation like physics
• Built more on experience and practice than theory
• Harder to establish universal principles

Consequence: Software engineering has struggled to achieve the same level of rigor as
mechanical and electrical engineering

Two-Level Research Approach

Research in software engineering progresses on two parallel levels:

Level 1: Practitioners

• Focus: Developing techniques for immediate application

• Approach: Practical, experience-based
• Output: Methodologies, tools, best practices
• Challenge: Many methodologies developed in past have been replaced
o May become obsolete over time
o Based on subjective foundations
o Subject to changing technology and understanding

Level 2: Theoreticians

• Focus: Searching for underlying principles and theories

• Approach: Academic, research-based
• Output: Fundamental theories for stable techniques
 • Challenge: Progress is slow
o Requires deep mathematical and logical analysis
o Must be broadly applicable
o Takes time to develop and validate

Both Are Necessary: Society's dependence on software systems demands progress from both
practitioners (for current needs) and theoreticians (for future stability)

Society's Dependence on Software

Critical Systems Dependent on Software:

Sector Dependency
Economy Banking, trading, financial systems
Healthcare Patient records, medical devices, diagnosis systems
Government Administration, record-keeping, services
Law Enforcement Criminal databases, dispatch systems, forensics
Transportation Traffic control, navigation, vehicle systems
Defense Weapons systems, communications, intelligence

The Problem: Despite this dependency, major reliability problems continue to exist

Real-World Software Failures

Historical Disasters and Near-Disasters Caused by Software Errors:

Incident Impact
Rising Moon Early warning system interpreted rising moon as nuclear
Misinterpretation attack
Bank of New York Loss One-day loss of $5 million due to software error
Space Probe Losses Multiple space missions failed due to software bugs
Medical radiation machines delivered fatal doses, killing and
Radiation Overdoses
paralyzing patients
Telephone Disruptions Simultaneous disruption of communications over large regions

Lesson: Software errors can have catastrophic consequences in terms of:

• Financial losses
• Loss of life
• Loss of critical services
• National security risks
Progress and Solutions

CASE (Computer-Aided Software Engineering)

Definition: Application of computer technology to the software development process to

streamline and simplify development

CASE Tools Categories:

Tool Category Purpose Examples

Project Planning Cost estimation, project Gantt charts, PERT diagrams,
Systems scheduling, personnel allocation
resource allocators
Project Management Monitor development project Progress tracking, milestone
Systems progress management, reporting
Document generators, help
Documentation Tools Write and organize documentation
systems, technical writers
Prototyping & Mockup tools, simulation
Develop and test prototypes
Simulation environments
Interface Design
Develop GUIs UI designers, screen layout tools
Systems
Programming Editors, compilers, debuggers,
Write and debug programs
Systems version control

Evolution of CASE Tools:

• Simple Tools: Generic tools adapted for software engineering

o Word processors for documentation
o Spreadsheets for planning
o Email for communication
• Sophisticated Tools: Specifically designed for software engineering
o Integrated Development Environments (IDEs)
o Specialized modeling tools
o Automated testing frameworks

Integrated Development Environments (IDEs)

Definition: Systems that combine multiple software development tools into a single,
integrated package

Components of an IDE:

Component Function
Editor Write and modify code with syntax highlighting, auto-completion
Compiler Translate code into executable form
Debugger Find and fix errors in code
 Component Function
Build Tools Compile and link complete projects
Version Control Track changes and manage different versions

Example: Smartphone Application Development IDEs

Features:

• Programming tools for writing and debugging software

• Simulators with graphical displays
o Show how software would perform on actual device
o Test different screen sizes and orientations
o Simulate various device capabilities
• Integrated testing frameworks
• Deployment tools for app stores

Benefit: Developers can see and test their applications without needing physical devices for
every development iteration

Professional Organizations

ACM (Association for Computing Machinery)

Background:

• Founded: 1947
• Type: International scientific and educational organization
• Headquarters: New York
• Mission: Advancing the arts, sciences, and applications of information technology

Structure - Special Interest Groups (SIGs):

SIG Focus Area Description

Computer Architecture Hardware design and organization
Artificial Intelligence AI research and applications
Biomedical Computing Medical and biological applications
Computers and Society Social and ethical impacts
Computer Science Education Teaching methods and curricula
Computer Graphics Visual computing and rendering
Hypertext/Hypermedia Web technologies and information systems
Operating Systems OS design and implementation
Programming Languages Language design and theory
Simulation and Modeling Computational simulation
Software Engineering Development methodologies
Important Resources:

• Website: [Link]
• Code of Ethics and Professional Conduct: [Link]

Significance: Provides professional standards, ethical guidelines, and community for

computing professionals

IEEE (Institute of Electrical and Electronics Engineers)

Pronunciation: "I-triple-E" (not "I-E-E-E")

Background:

• Formed: 1963
• Origin: Merger of two organizations:
1. American Institute of Electrical Engineers (founded 1884)
§ Founded by 25 electrical engineers including Thomas Edison
2. Institute of Radio Engineers (founded 1912)
• Operation Center: Piscataway, New Jersey

Technical Societies Include:

Society Focus
Aerospace and Electronic Systems Aviation and space systems
Lasers and Electro-Optics Optical technologies
Robotics and Automation Robotic systems
Vehicular Technology Transportation systems
Computer Society Computing technologies

Standards Development:

Example: Floating-Point Standards

• IEEE developed single-precision and double-precision floating-point standards

• Introduced in Chapter 1 of the textbook
• Used in most of today's computers
• Ensures consistency across different computer systems

Important Resources:

• IEEE Website: [Link]

• IEEE Computer Society: [Link]
• IEEE Code of Ethics: [Link]

Role in Software Engineering:

 • Establishes standards for software development
• Provides professional certification programs
• Publishes research and best practices
• Offers guidelines for quality improvement

Organizational Efforts for Improvement

Joint Efforts by ISO, ACM, and IEEE:

Initiative Type Purpose

Codes of Professional
Enhance professionalism of software developers
Conduct
Counter nonchalant attitudes toward individual
Ethics Standards
responsibilities
Quality Measurement Establish metrics for measuring software development
Standards organization quality
Improvement Guidelines Help organizations improve their development processes

Impact: These efforts work to:

• Raise professional standards

• Increase accountability
• Improve software quality
• Reduce failures and errors
• Protect public interest

7.2 The Software Life Cycle

Fundamental Concept

Definition: The software life cycle is the most fundamental concept in software engineering.
It represents the complete lifespan of software from initial conception through retirement.

Development Use

Maintenance

Key Understanding: Software, like manufactured products, has a life cycle. However, the
nature of this cycle differs significantly from physical products.
The Cycle as a Whole

Main Phases of the Software Life Cycle

Phase Description Duration

Development Initial creation of software system Months to years
Usage Software in active production use Years to decades
Maintenance Ongoing corrections and updates Continues throughout usage

Important Characteristics:

Cyclical Nature:

• Once developed, software enters a continuous cycle

• Usage and maintenance alternate and overlap
• Cycle continues for the rest of the software's life
• Similar pattern exists for manufactured products, but with key differences

Maintenance Phase: Software vs Physical Products

Critical Difference:

Physical Products Software

Maintenance = Repair Maintenance = Correction/Updating
Wear and tear cause failures No physical wear
Parts degrade over time Code doesn't degrade physically
Preventive maintenance possible Different maintenance drivers

Why Software Enters Maintenance Phase

Three Primary Reasons:

1. Error Discovery

• Description: Bugs found during actual use that weren't caught during testing
• Examples:
o Incorrect calculations under specific conditions
o Memory leaks that appear over time
o Race conditions in multi-threaded code
o Edge cases not considered during development
• Challenge: Users encounter scenarios developers didn't anticipate

2. Application Changes
 • Description: Changes in how software is used require corresponding software
changes
• Examples:
o New business requirements (tax law changes, new regulations)
o Integration with new systems
o Support for new hardware or platforms
o Expansion to new user groups or markets
• Reality: Requirements don't stay static even after deployment

3. Induced Problems

• Description: Previous modifications introduce new problems elsewhere

• Technical Term: Regression
• Examples:
o Fix in module A breaks functionality in module B
o Performance optimization causes accuracy issues
o Security patch introduces compatibility problems
• Why It Happens: Complex interdependencies not fully understood

The Maintenance Challenge

The Process Required:

Step 1: Understanding

• Person performing maintenance (often NOT original author) must:

o Study the underlying program
o Review all documentation
o Understand pertinent parts of the program
o Trace through code logic
o Identify dependencies and relationships

Step 2: Analysis

• Determine impact of proposed changes

• Identify what else might be affected
• Evaluate risks of modification

Step 3: Implementation

• Make changes carefully

• Update documentation
• Test thoroughly

Why This Is Difficult:

• Even well-designed, well-documented software is hard to understand

• Original developers may no longer be available
 • Documentation may be incomplete or outdated
• Code may have been modified multiple times by different people
• System complexity may have grown over time

The Discard Decision

When Maintenance Becomes Untenable:

Common Scenario:

• Software enters maintenance phase

• Understanding proves too difficult
• Modification attempts introduce more problems than they solve
• Decision: Discard software, develop new system from scratch

The Pretense (Too Often True):

• "It is easier to develop a new system from scratch than to modify the existing package
successfully"

This Represents:

• Failure of original development to consider maintainability

• Loss of institutional investment in existing system
• High cost of redevelopment
• Disruption to users

Critical Lesson: A little effort during development can make tremendous difference during
maintenance

The Development vs. Maintenance Leverage

Key Principle: Most software engineering research focuses on the development stage
because of the effort-versus-benefit leverage

The Leverage Concept:

Small Effort During Development Huge Impact During Maintenance

Use constants instead of literals Easy to change values across entire program
Write clear documentation Others can understand code quickly
Design modular structure Can modify one part without affecting others
Follow coding standards Consistent, readable code
Include comprehensive tests Can verify changes don't break existing functionality

Example from Chapter 6:

 • Using Constants vs. Literals:
o With Literals: if (age >= 65) scattered throughout code
§ Changing retirement age requires finding all occurrences
§ Risk of missing some
§ Error-prone
o With Constants: const RETIREMENT_AGE = 65
§ Change one value
§ Automatically updates everywhere
§ No risk of inconsistency

Research Focus:

• Most software engineering research targets the development stage

• Goal: Take advantage of this effort-versus-benefit leverage
• Small improvements in development process yield large benefits in maintenance

The Traditional Development Phase

Requirements
Analysis

Design

Implementation

Testing

Four Major Steps:

Step Primary Question Answered

Requirements Analysis What should the system do?
Design How should the system do it?
Implementation Building the system
Testing Does the system work correctly?

1. Requirements Analysis

Definition: The process of determining what services the proposed system will provide,
identifying conditions on those services, and defining how the outside world will interact
with the system.

Primary Goal: Create a clear, complete specification of what the system must do
Key Activities:

A. Service Specification

• Identify all functions the system must perform

• Define inputs and outputs
• Specify performance requirements
• Determine capacity requirements

Example - Hospital Patient Records System:

• Must store patient medical history

• Must allow doctors to retrieve records
• Must update records with new information
• Must be accessible 24/7
• Must protect patient privacy

B. Constraint Identification

• Time Constraints: Response time requirements, processing deadlines

• Security Constraints: Access controls, encryption requirements, audit trails
• Reliability Constraints: Uptime requirements, data integrity requirements
• Compatibility Constraints: Must work with existing systems
• Regulatory Constraints: HIPAA, GDPR, industry standards

C. Interaction Definition

• How users will interact with system (GUI, command line, API)
• How system will interact with other systems
• Data exchange formats and protocols

Stakeholder Involvement

Definition of Stakeholders: All people and organizations with interest in the proposed
system

Types of Stakeholders:

Stakeholder Type Interest in System

End Users Will use system daily; concerned with usability, features
Management Concerned with ROI, strategic alignment, costs
Legal/Compliance Ensure regulatory compliance, manage risks
Financial Budget, funding, cost justification
IT Department Integration, maintenance, support
Stakeholder Type Interest in System
Customers External parties who benefit from system

Important Note: Requirements analysis involves "significant input" from stakeholders - not
just passive acceptance of requirements, but active collaboration and negotiation

Different Starting Points

Scenario 1: User-Initiated Project

• User entity (company, government agency) hires software developer

• May start with feasibility study conducted solely by user
• User determines if project is viable before engaging developer
• User has clear need they're trying to address

Scenario 2: Commercial Off-The-Shelf (COTS) Software

• Software developer produces for mass market

• Sold in retail stores or downloaded via Internet
• User is less precisely defined entity
• May begin with market study by software developer
• Developer identifies market need rather than specific user

The Requirements Analysis Process

Step-by-Step Process:

Step 1: Needs Compilation

• Gather information from all stakeholders

• Interview users about current processes and pain points
• Observe current workflows
• Review existing systems and documentation
• Identify problems to be solved

Step 2: Needs Analysis

• Analyze collected information

• Identify patterns and common themes
• Prioritize needs (must-have vs. nice-to-have)
• Resolve conflicting requirements

Step 3: Negotiation

• Trade-offs between:
 oWants (desired features)
oNeeds (essential features)
oCosts (budget constraints)
oFeasibility (technical constraints)
• Example Negotiations:
o "We want real-time updates, but that would triple the cost. Can we accept 5-
minute delays?"
o "This feature would require technology that doesn't exist yet. Can we postpone
it to version 2.0?"

Step 4: Requirements Specification Development

• Create formal document identifying all requirements

• Features the finished system must have
• Services it must provide
• Constraints it must satisfy

Software Requirements Specification Document

Purpose: Written agreement between all parties concerned

Functions:

• Guide software's development

• Provide means of resolving disputes
• Serve as contract between parties
• Define acceptance criteria

Significance Indicators:

• Professional organizations (IEEE) have adopted standards for its composition

• Large clients (U.S. Department of Defense) require specific formats
• Legal standing in contracts

Challenges in Requirements Analysis

The Stability Problem:

Ideal Scenario:

• Software requirements specification defines firm, unchanging objective

• Development proceeds according to this stable target

Reality:

• Document often fails to provide this stability

 • Requirements change during development

Major Causes of Cost Overruns and Late Delivery (According to Practitioners):

Cause Why It Happens Example

Poor Stakeholders and developers Users say "fast" meaning seconds;
Communication don't understand each other developers think "fast" means minutes
Changing Business needs evolve, System for subsidiary must expand to
Requirements technology advances entire corporation
Additional features added "While you're at it, can you also
Scope Creep
during development add...?"
Technology New capabilities become Original plan used 2015 technology,
Changes available but by 2017 better options exist

Real-World Example of Changing Requirements:

Physical Construction Analogy:

• Few customers would insist on major floor plan changes after foundation is
constructed
• Physical construction makes changes very expensive
• Consequences are visible and obvious

Software Reality:

• Organizations frequently expand or alter desired capabilities well after construction is

underway
• Changes seem "easy" because software is malleable
• Consequences not immediately visible
• Example Scenarios:
o Company decides system for one subsidiary should apply to entire corporation
o Advances in technology supplant capabilities available during initial analysis
o Regulatory changes require new features
o Competitive pressures demand additional functionality

Solution: Communication

Mandatory Approach:

• Straightforward and frequent communication with project's stakeholders

• Regular status meetings
• Demonstration of work in progress
• Continuous validation that system meets current needs
• Change management process for handling requirement changes

Change Management Process:

 1. Document proposed change
2. Analyze impact (cost, schedule, technical)
3. Get stakeholder approval
4. Update requirements specification
5. Adjust project plan accordingly

2. Design

Definition: Creating a plan for the construction of the proposed system

Fundamental Relationship:

Requirements Analysis Design

About identifying the PROBLEM About developing a SOLUTION
Describes what system must do Describes how system will do it

Layperson's Perspective (with Caveats):

Common Description:

• Requirements Analysis = Deciding WHAT system is to do

• Design = Deciding HOW system will do it

Why Software Engineers Argue This Is Flawed:

• In actuality, much HOW is considered during requirements analysis

o How users will interact with system
o How data will flow
o How system integrates with existing systems
• Much WHAT is considered during design
o What specific algorithms to use
o What data structures to employ
o What modules to create

Better Understanding: Requirements and design exist on a continuum rather than being
completely separate

The Design Stage Output

What Is Produced:

• Internal structure of the software system is established

• Detailed description of software system's structure
• Description can be converted into programs
Level of Detail:

• Specific enough that programmers can implement

• Abstract enough to allow implementation flexibility
• Includes:
o Module definitions
o Interface specifications
o Data structure definitions
o Algorithm selections
o Processing flows

Architecture Analogy

If Constructing an Office Building:

Design Stage Would Produce:

• Collection of blueprints
• Detailed structural plans
• Building described at various levels of detail
o Overall structure
o Floor plans
o Individual room specifications
o Electrical systems
o Plumbing systems
o HVAC systems

From These Documents:

• Actual building would be constructed

• Construction workers know exactly what to build
• Can estimate costs and timeline

Architectural Design Characteristics:

• Standardized notational systems (drafting symbols, conventions)

• Established modeling methodologies
• Well-understood principles
• Evolved over many years

Software Design Reality

Contrast with Architecture:

 Architectural Design Software Design
Stable methodologies (centuries old) Dynamic, changing methodologies
Standardized notation Multiple competing notation systems
Well-established discipline Relatively young discipline
Universal principles Evolving best practices

Why Software Design Is Less Stable:

• Software engineering is relatively young field

• Technology changes rapidly
• New paradigms emerge (procedural → object-oriented → functional)
• Researchers continue searching for better approaches

Current State:

• Multiple diagramming and modeling methodologies exist

• Different notational systems in use
• Field appears very dynamic compared to architecture
• Continuous struggle to find better approaches

Important Topics:

Section 7.3: Will explore the shifting terrain of software design methodologies

• Different development paradigms

• Evolution of approaches
• Modern methodologies

Section 7.5: Will investigate current notational systems and modeling methodologies

• UML (Unified Modeling Language)

• Dataflow diagrams
• Other design tools

3. Implementation

Definition: The actual writing of programs, creation of data files, and development of
databases that make up the software system

Primary Activities:

Activity Description Output

Program Writing Converting design into code Source code files
 Activity Description Output
Configuration files, data
Data File Creation Creating files for storing data
files
Database Designing and implementing
Database schemas, tables
Development databases

Role Distinction: Software Analyst vs. Programmer

Software Analyst (Sometimes Called System Analyst):

Involvement:

• Engaged with entire development process

• Present from requirements through deployment
• Emphasis often on requirements analysis and design steps

Responsibilities:

• Understand business needs

• Create system designs
• Make high-level technical decisions
• Coordinate between stakeholders and developers
• Often leads project teams

Skills:

• Strong communication abilities

• Business domain knowledge
• Technical expertise
• System thinking
• Problem-solving

Programmer:

Involvement:

• Primarily involved with implementation step

• May have some involvement in design and testing
• Focus on writing code

Narrowest Interpretation:

• Charged with writing programs that implement design produced by software analyst
• Translates design documents into working code
• Follows specifications provided by analyst
Broader Reality:

• May be involved in detailed design decisions

• Often contributes to testing
• May participate in requirements discussions

Terminology Blurring

Important Reality Check:

• No central authority controlling terminology in computing community

• Many carrying title "Software Analyst" are essentially programmers
• Many with title "Programmer" (or "Senior Programmer") are actually full software
analysts

Why Terminology Blurs:

• Steps in software development often intermingled

• Roles overlap in practice
• Small teams may not have distinct roles
• Individual capabilities vary
• Companies use titles differently

Modern Trend:

• Agile methodologies encourage role blurring

• Team members wear multiple hats
• Less rigid separation of responsibilities
• Example: "Full-stack developer" combines many traditional roles

Institute of Electrical and Electronics Engineers (IEEE) - Detailed

Historical Background:

Formation (1963):

• Result of merger between two organizations

American Institute of Electrical Engineers:

• Founded: 1884
• Founding Members: 25 electrical engineers
• Notable Founder: Thomas Edison
• Original Focus: Electrical power systems

Institute of Radio Engineers:

 • Founded: 1912
• Original Focus: Radio and wireless technologies
• Evolution: Expanded to all electronics

Modern Organization:

• Operation Center: Piscataway, New Jersey

• Membership: Hundreds of thousands worldwide
• Scope: All aspects of electrical and electronics engineering

Technical Societies (Partial List):

Relevance to Software
Society Name Focus Area
Engineering
Aerospace and Electronic Aviation, space, defense Embedded software, real-time
Systems Society systems systems
Lasers and Electro-Optics Data transmission, storage
Optical technologies
Society systems
Robotics and Automation Robotic systems, Control software, AI
Society automation applications
Automotive software,
Vehicular Technology Society Transportation systems
navigation
Software engineering,
Computer Society Computing technologies
computer science

Standards Development Role:

Why Standards Matter:

• Ensure interoperability between systems

• Provide common reference points
• Enable innovation by establishing stable foundations
• Protect consumers and users

Example: Floating-Point Standards

Problem Before Standards:

• Different computers represented decimal numbers differently

• Programs behaved differently on different computers
• Numerical calculations gave inconsistent results
• Portability was nearly impossible

IEEE Solution:
 • Developed single-precision floating-point standard (32-bit)
• Developed double-precision floating-point standard (64-bit)
• Specified exact bit layouts
• Defined behavior for special cases (infinity, NaN)
• Introduced in Chapter 1 of textbook

Impact:

• Now used in most of today's computers

• Programs produce consistent results across platforms
• Simplified software development
• Enabled scientific computing advances

Software Engineering Standards from IEEE:

• Software requirements specifications format

• Software design documentation
• Software testing procedures
• Software quality assurance
• Software configuration management

4. Testing

Evolution of Testing Concept

Traditional View (Past):

Activity Scope
Debugging Programs Finding and fixing coding errors
Specification Confirmation Verifying final product matches requirements specification

Limitations of Traditional View:

• Too narrow in scope

• Only focused on end-stage activities
• Missed opportunities for early error detection
• Treated testing as separate, final step

Modern View of Testing:

Expanded Scope:

• Testing is no longer just about programs

 • Results of each intermediate step should be tested for accuracy
• Testing occurs throughout development process

What Gets Tested:

Development Stage What Is Tested

Requirements Requirements specification document - is it complete, consistent,
Analysis testable?
Design documents - are they complete, feasible, traceable to
Design
requirements? |
Implementation Code - does it work correctly, efficiently, securely?
Integration Combined modules - do they work together correctly

Quality Assurance Integration

Modern Recognition:

• Testing is only one segment in overall struggle for quality assurance

• Quality assurance is objective that permeates entire software life cycle
• Not confined to single step

Implication:

• Quality must be built in from the start

• Cannot be "tested in" at the end
• Requires continuous attention throughout development

Proposed Restructuring of Development Steps

Some Software Engineers Argue:

• Testing should not be viewed as separate step

• Instead, incorporate testing and manifestations into other steps

New Three-Step Process:

Traditional Step Integrated Step

Requirements Analysis Requirements Analysis and Confirmation
Design Design and Validation
Implementation Implementation and Testing

Note: "Testing" step disappears as separate phase but becomes integrated throughout
The Reality of Software Errors

Despite Modern Techniques:

• Large software systems continue to contain errors

• Errors persist even after significant testing efforts
• Cannot eliminate all errors no matter how much testing

Fate of Errors:

Error Type Outcome

Undetected May go undetected for life of system
Minor Discovered but cause only inconvenience
Major Cause significant malfunctions
Critical Can lead to disasters (financial loss, injury, death)

The Goal:

• Software engineering research aims to eliminate errors

• Particularly critical errors

The Reality:

• Errors still prevalent in software systems

• Indicates much research remains to be done
• Perfect software may be unattainable goal
• Focus on reducing critical and major errors

Why Perfect Software Is Hard:

Factors:

• Complexity: Modern systems have millions of lines of code

• Interdependencies: Components interact in complex ways
• Requirements Evolution: What's correct today may be wrong tomorrow
• Human Factor: Programmers make mistakes
• Incomplete Specifications: Cannot test what isn't specified
• Emergent Behavior: Systems behave in unexpected ways when integrated
• Environmental Factors: Different usage patterns, different hardware, different data

7.3 Software Engineering Methodologies

Introduction: The Evolution from Waterfall

Historical Context:

Early Approach:

• Software engineers insisted on strict sequential process

• No variations allowed
• Each phase must be completely finished before next begins

Rationale:

• "Too much was at risk during development of large software system"

• Belief that structure and control were necessary
• Fear that flexibility would lead to chaos

Result: The Waterfall Model

The Waterfall Model

Definition: Development process that flows in only one direction (like water flowing down
waterfall)

Strict Requirements:

Phase Completion Requirement

Requirements
Must be completely finished before beginning design
Specification
Must be completely finished before beginning
Design
implementation
Implementation Must be completely finished before beginning testing
Analogy: Like a waterfall - water flows in one direction and cannot flow backwards

Characteristics of Waterfall Model:

Advantages (Theoretical):

• Clear structure and milestones

• Easy to manage and understand
• Well-defined deliverables at each stage
• Good for projects with stable requirements
• Extensive documentation produced

Disadvantages (Discovered in Practice):

• Rigid and inflexible

• Assumes requirements fully known upfront
• Late discovery of problems
• User doesn't see working software until late
• Difficult to accommodate changes
• Integration happens at end (risky)

The Fundamental Contradiction:

Waterfall Model Imposed:

• Highly structured environment

• Rigid sequential process
• No variation allowed
• Complete each phase before next

Reality of Problem Solving:

• "Free-wheeling," trial-and-error process often vital

• Creativity requires flexibility
• Learning occurs through iteration
• Solutions emerge through exploration
• Requirements understanding improves over time

Result: Waterfall model contradicts natural problem-solving process

The Incremental Model

Emergence: Response to limitations of waterfall model

Core Concept: Construct desired software system in increments

How Incremental Model Works:

Step-by-Step Process:

Version 1.0 (First Increment):

• Simplified version of final product

• Limited functionality
• Core features only
• Purpose: Get something working quickly

Testing and Evaluation:

• Test this version thoroughly

• Evaluate with future users
• Gather feedback
• Identify issues and needs

Version 2.0 (Second Increment):

• Add more features

• Expand functionality
• Based on feedback from Version 1.0
• Key: Building on working foundation

Subsequent Increments:

• Continue adding features

• Test each increment
• Evaluate with users
• Process: Incremental manner until system is complete
Real-World Example: Hospital Patient Records System

Version 1.0:

• Functionality: View patient records only

• Scope: Small sample of entire record system
• Purpose: Demonstrate concept, get user feedback
• Timeline: Weeks to deliver

Version 2.0:

• Added Functionality: Ability to add new records

• Scope: Larger sample of records
• Purpose: Expand capabilities based on feedback
• Timeline: Additional weeks

Version 3.0:

• Added Functionality: Update existing records

• Scope: Complete record system
• Purpose: Full functionality
• Timeline: Additional weeks

Final Version:

• Complete system with all features

• Thoroughly tested through incremental development
• Users familiar with system from early involvement

Key Principle: EXTENDING

• Each version extends functionality

• Adds new features to existing base
• Previous features remain and are enhanced
• System grows larger and more capable with each increment

Advantages of Incremental Model:

Advantage Explanation
Early Delivery Users get working software quickly
User Feedback Can incorporate user input throughout development
Risk Reduction Problems discovered early when cheaper to fix
Flexibility Can adjust priorities based on feedback
Morale Team sees progress, users see value
 Advantage Explanation
Revenue Can deploy and use early versions while developing later ones

Challenges:

Challenge Consideration
Architecture Initial design must accommodate future growth
Scope Creep Users may request unlimited additions
Integration Must ensure new increments work with existing code
Documentation Must keep pace with incremental changes

The Iterative Model

Relationship to Incremental Model:

• Similar to incremental model

• Sometimes equated with it
• But distinct in important way

Key Distinction:

Incremental Model Iterative Model

EXTENDING each version REFINING each version
Adding new features Improving existing features
Making system larger Making system better
Focus on breadth Focus on depth

How Iterative Model Works:

Cycle Process:

Draft Version:

• Create initial version

• May be incomplete or rough
• Purpose: Get something to evaluate

Refinement:

• Improve the version

• Fix problems
• Enhance quality
• Optimize performance
• Purpose: Make it better
Testing:

• Evaluate refined version

• Identify remaining issues
• Purpose: Determine if satisfactory

Repeat:

• If not satisfactory, refine again

• Continue iterating
• Stop When: Version reaches acceptable quality

Reality Check:

• Incremental involves iterative: Each increment goes through iterations

• Iterative may add features: Refinement may include new capabilities
• Models overlap: In practice, most projects use both approaches
• Pure distinction: Theoretical rather than practical

Example: Word Processor Development

Iteration 1:

• Basic text editing

• Evaluation: Works but slow
• Refinement: Optimize performance

Iteration 2:

• Same features, better performance

• Evaluation: Fast but crashes with large documents
• Refinement: Fix memory management

Iteration 3:

• Same features, stable and fast

• Evaluation: Satisfactory
• Result: Move to next increment (add new features)

Rational Unified Process (RUP)

Background and Significance:

Creation:
 • Developer: Rational Software Corporation
• Now: Division of IBM
• Status: Widely applied throughout software industry

What RUP Is:

• Software development paradigm (comprehensive framework)

• Redefines steps in development phase of software life cycle
• Provides guidelines for performing those steps
• Not just a methodology but a complete process framework

RUP Characteristics:

Components:

• Process Framework: How to organize development activities

• Best Practices: Proven techniques and approaches
• Guidelines: Detailed instructions for applying process
• CASE Tools: Software tools to support the process
• Templates: Standard documents and formats

Commercial Aspect:

• Guidelines marketed by IBM

• CASE tools sold by IBM
• Training and certification available
• Consulting services offered

Significance in Industry:

Popularity:

• Widely applied throughout software industry

• Used by many large organizations
• Considered industry standard by many

Influence:

• Led to development of Unified Process (nonproprietary version)

• Influenced other methodologies
• Established iterative development as mainstream

The Unified Process:

Relationship to RUP:

• Nonproprietary version of RUP

• Based on same principles
• Available on noncommercial basis
• Open and accessible

Significance:

• Makes RUP principles available to all

• Community can contribute improvements
• Not tied to specific vendor tools
• Free for academic and research use

RUP Key Principles:

Principle Description
Iterative Development Build system through repeated cycles
Requirements Management Systematic approach to changing requirements
Component-Based Architecture Build from reusable components
Visual Modeling Use UML and other visual representations
Quality Verification Continuous testing and quality checks
Change Control Manage changes systematically

Prototyping

Definition: Building incomplete versions of proposed system (called prototypes)

Usage Context:

• Used with incremental model

• Used with iterative model
• Can stand alone as development approach

Purpose of Prototypes:

• Explore design alternatives

• Demonstrate concepts to users
• Test technical feasibility
• Gather user feedback
• Clarify requirements

Evolutionary Prototyping
Definition: Prototypes evolve into complete, final system

Process:

Initial Prototype:

• Built with core functionality

• May be rough or incomplete
• Purpose: Get something working

Evolution:

• Prototype is refined
• Features are added
• Quality is improved
• Key Point: Same code base evolves

Final System:

• Evolved from original prototype

• Continuous improvement process
• No separate "final implementation"

Characteristics:

Aspect Details
Starting Point Simple, working prototype
Development Continuous evolution
Code Base Single, evolving code base
User Involvement Throughout development
End Result Prototype becomes product

When to Use:

• Requirements are unclear

• Technology is new or experimental
• Users need to see working system to understand needs
• Risk of misunderstanding requirements is high

Relationship to Incremental Model:

• Evolutionary prototyping aligns with incremental model

• Each increment is evolution of previous version
• Prototype grows into full system
Throwaway Prototyping

Definition: Prototypes are discarded in favor of fresh implementation

Process:

Build Prototype:

• Quick and dirty implementation

• Focus on demonstrating concept
• Not production quality
• Purpose: Learning and exploration

Use Prototype:

• Show to users
• Test technical approaches
• Clarify requirements
• Explore alternatives

Discard Prototype:

• Throw away prototype code

• Important: Don't try to "clean up" prototype for production

Implement Final System:

• Fresh implementation based on what was learned

• Production quality from start
• Clean architecture
• Proper design

Why Discard Instead of Evolve?

Prototype Code Production Code Requirements

Quick and dirty Clean and maintainable
Focused on demo Focused on all requirements
May use shortcuts Must be robust
Incomplete error handling Complete error handling
Poor architecture OK Good architecture essential
No documentation needed Full documentation required

Key Principle: Easier to start fresh with good design than to fix bad prototype

Relationship to Iterative Model:

 • Throwaway prototyping fits iterative model
• Each prototype iteration improves understanding
• Final implementation incorporates learning
• Prototypes refined, then discarded

Rapid Prototyping

Definition: Throwaway prototyping performed quickly in early development stages

Characteristics:

Speed:

• Built very quickly (days or weeks, not months)

• Minimal functionality
• Focus on appearance and interaction

Simplicity:

• May consist of only few screen images

• Shows how system will look
• Demonstrates capabilities
• Not a working system

Purpose of Rapid Prototypes:

Purpose Explanation
Demonstrate Interaction Show how users will interact with system
Show Capabilities Illustrate what system will do
Clarify Communication Help developers and users understand each other
Validate Requirements Confirm understanding of needs

Important Point: Goal is NOT to produce working version of product

Common Uses:

During Requirements Analysis:

• Build quick prototype of user interface

• Show to stakeholders
• Get feedback on requirements
• Before committing to detailed design
• Benefit: Discover misunderstandings early when cheap to fix
Sales Presentations:

• Show potential clients what system could look like

• Demonstrate capabilities
• Win contracts
• Benefit: Visual demonstration more effective than written proposal

Example Scenario:

Problem: Client says "I want easy-to-use interface"

• Developer understanding: Simple menus

• Client expectation: Graphical with icons

Without Rapid Prototype:

• Developer builds menu-based interface

• Client sees it late in project
• "This isn't what I wanted!"
• Cost: Major rework, delays, conflict

With Rapid Prototype:

• Developer builds quick screen mockup

• Shows to client early
• "Oh, I meant graphical with icons"
• Cost: Few hours to create new mockup
• Build right system from start

Tools for Rapid Prototyping:

• Screen designers: Drag-and-drop UI creation

• Presentation software: PowerPoint, Keynote for screen mockups
• Prototyping tools: Figma, Adobe XD, Sketch
• HTML mockups: Quick web page layouts

Open-Source Development

Definition: Less formal incarnation of incremental and iterative ideas used by computer
enthusiasts/hobbyists

Significance:

• Means by which much of today's free software is produced

• Community-driven development model
• Collaborative approach
 • Transparent process

Most Prominent Example: Linux Operating System

Background:

• Original Leader: Linus Torvalds

• Started: As personal project
• Grew: Into major operating system
• Current Status: Powers servers, smartphones (Android), embedded systems

Impact:

• Demonstrated viability of open-source model

• Inspired thousands of other open-source projects
• Challenged proprietary software development model

The Open-Source Development Process:

Step 1: Initial Version

• Single author writes initial version

• Motivation: Usually to fulfill his or her own needs
• Quality: May be rough but functional
• Example: Linus Torvalds needed Unix-like system for his PC

Step 2: Publication

• Author posts:
o Source code (complete program code)
o Documentation (how to use and modify)
• Platform: Internet (GitHub, SourceForge, etc.)
• License: Usually open-source license (GPL, MIT, Apache)

Step 3: Download and Use

• Others download: From Internet

• Cost: Without charge (free)
• Freedom: Can use, study, modify
• Community forms: Around the software

Step 4: Modification

• Users have source code so they can modify

• Users have documentation so they understand it
• Reasons for modification:
 o Fit their own specific needs
o Add features they want
o Correct errors they find
o Improve performance
o Port to different platforms

Step 5: Contribution

• Users report changes to original author

• Include:
o Description of changes
o Modified code
o Explanation of why changes made
• Community review: Others can review and test changes

Step 6: Integration

• Original author:
o Reviews submitted changes
o Decides which to incorporate
o Integrates approved changes into main version
• Quality control: Author maintains standards

Step 7: Publication of Extended Version

• Author posts: Updated version with incorporated changes

• Available: For further modifications
• Cycle repeats: New users download, modify, contribute

Timeline Reality:

Speed of Evolution:

• In practice, software package can evolve through several extensions in single week
• Much faster than traditional development
• Example:
o Monday: User reports bug and submits fix
o Tuesday: Author reviews and integrates
o Wednesday: New version posted
o Thursday: Another user adds feature
o Friday: Feature integrated, new version posted

Contrast with Traditional Development:

• Traditional: Months or years between releases

• Open-source: Days or weeks between versions
• Traditional: Limited number of developers
• Open-source: Potentially thousands of contributors
Characteristics of Open-Source Development:

Aspect Description
Collaboration Worldwide community of developers
Transparency All code visible to all
Meritocracy Good code gets accepted regardless of who wrote it
Rapid Evolution Multiple updates per week possible
Diverse Input Different perspectives and needs drive improvements
Quality "Many eyes" find and fix bugs
Free No cost to use or modify

Advantages:

Advantage Explanation
Rapid Improvement Many contributors accelerate development
Diverse Testing Used in many environments, reveals more bugs
Innovation Users can experiment with new ideas
Cost Free for users and contributors
Longevity Community can maintain even if original author stops
Security Public code review can find vulnerabilities

Challenges:

Challenge Concern
Quality Control Who ensures quality?
Direction Who decides what features to add?
Support Who helps users with problems?
Documentation Often lags behind code
Coordination Managing many contributors difficult
Sustainability Depends on volunteer effort

Success Stories Beyond Linux:

• Apache Web Server: Powers majority of web servers

• Mozilla Firefox: Web browser
• LibreOffice: Office productivity suite
• Python, Perl, Ruby: Programming languages
• WordPress: Website platform
• Android: Smartphone operating system (based on Linux)
Agile Methods

Definition: Collection of methodologies representing pronounced shift from waterfall model

Core Philosophy: Complete departure from rigid, sequential approach

Fundamental Characteristics:

Characteristic Description Contrast with Waterfall

Waterfall: Long planning before
Early Implementation Start coding quickly
coding
Quick Implementation Get working software fast Waterfall: All planning first
Waterfall: Build everything at
Incremental Basis Build in small increments
once
Welcome changing
Responsive to Change Waterfall: Resist changes
requirements
Reduced Less emphasis on formal Waterfall: Extensive
Documentation documents documentation
Less upfront analysis and Waterfall: Complete planning
Reduced Planning
design upfront

Agile Manifesto Values (Background):

The Agile movement formally articulated values:

We Value More Than

Individuals and interactions Processes and tools
Working software Comprehensive documentation
Customer collaboration Contract negotiation
Responding to change Following a plan

Note: Right side has value, but left side valued more

Why "Agile"?

Name Significance:

• Agile = able to move quickly and easily

• Flexible
• Responsive
• Adaptive
Metaphor:

• Waterfall conjures image of rigid, inflexible flow

• Agile conjures image of nimble, responsive adaptation

Extreme Programming (XP)

Definition: One example of agile method; one of most well-known

"Extreme" Because:

• Takes good practices to extreme levels

• Example: If code review is good, review code all the time (pair programming)
• Example: If testing is good, test all the time (continuous testing)

Team Structure:

Team Size:

• Less than dozen individuals

• Why Small:
o Easier communication
o Less coordination overhead
o Faster decision-making
o Everyone knows everyone

Work Environment:

• Communal work space

• Not: Individual offices or cubicles
• Layout: Open area where all can see each other
• Purpose: Facilitate communication and collaboration

Team Dynamics:

• Freely share ideas: No gatekeepers

• Assist each other: Pair programming, collective ownership
• Continuous communication: Talk face-to-face rather than email

Development Process:

Daily Cycles:

Cycle Components:
 1. Informal Requirements Analysis
o Quick discussion of what to build today
o User stories (brief descriptions)
o Priority decisions
o Duration: Minutes to hours, not days
2. Designing
o Quick design discussions
o Whiteboard sketches
o Focus on immediate need
o No: Elaborate design documents
3. Implementing
o Write code in pairs
o Test as you go
o Integrate frequently
o Result: Working code by end of day
4. Testing
o Automated tests run continuously
o Manual testing as needed
o User acceptance testing
o Goal: Ensure everything still works

Repeat Daily:

• New cycle each day

• Build on previous day's work
• Continuous forward progress

Regular New Versions:

Release Frequency:

• New expanded versions appear regularly

• Could be: Daily, weekly, bi-weekly
• Much faster than traditional months/years between releases

Stakeholder Evaluation:

• Each version can be evaluated by stakeholders

• Get feedback quickly
• Adjust priorities based on feedback

Point Toward Further Increments:

• Feedback guides next increments

• Continuous course correction
• Adaptive rather than predictive
Contrast with Waterfall:

Aspect Waterfall Extreme Programming

Physical Space Individual offices Communal workspace
Work Style Independent tasks Collaborative pairs
Structure Rigid phases Flexible cycles
Tasks Well-defined portions Emergent tasks
Communication Formal documents Face-to-face conversation
Planning Extensive upfront Continuous adaptation
Change Resisted Welcomed

Visual Metaphor:

• Waterfall: Managers and programmers in separate offices, following rigid plans,

formal communication
• XP: Team in open space, pair programming, constant communication, rapid
adaptation

XP Practices (Brief Overview):

Practice Description
Pair Programming Two programmers, one computer; one writes, one reviews
Test-Driven Development Write tests before writing code
Continuous Integration Integrate code many times per day
Collective Ownership Anyone can modify any code
Simple Design Simplest thing that could work
Refactoring Continuous code improvement
Sustainable Pace 40-hour weeks, avoid burnout

Advantages of Agile/XP:

Advantage Benefit
Flexibility Can respond to changing requirements
Customer Satisfaction Frequent delivery of valuable software
Team Morale Collaboration and shared ownership
Early Problem Detection Continuous testing finds issues early
Working Software Always have deployable product
Adaptation Learn and adjust as you go

Challenges:
 Challenge Consideration
Discipline Required Practices must be followed consistently
Not for All Projects Some projects need more upfront planning
Scalability Harder with large teams or distributed teams
Documentation May lack comprehensive documentation
Client Availability Requires accessible, engaged customer
Cultural Change Organizations must adapt

The Breadth of Methodologies

Spectrum of Approaches:

From Waterfall (rigid, sequential, plan-driven) To XP (flexible, iterative, change-driven)

What This Reveals:

Aspect Range
Structure Highly rigid to highly flexible
Planning Extensive upfront to minimal upfront
Documentation Comprehensive to minimal
Change Resist to welcome
Process Heavy to light

No Single "Right" Methodology:

Different Projects Need Different Approaches:

Project Type Better Approach

Safety-Critical (aircraft, medical More waterfall-like (extensive planning,
devices) documentation)
Web Applications More agile (rapid changes, quick delivery)
Large Government More waterfall-like (accountability, documentation)
Startup Product More agile (flexibility, speed to market)

Current State of Software Engineering:

Ongoing Research:

• Field is in state of exploration

• Researchers continue trying different approaches
• Goal: Find better ways to construct reliable software efficiently
• Reality: No universal solution yet found
Progress Being Made:

• Better understanding of what works when

• More sophisticated methodologies
• Better tools
• More experienced practitioners

Much Work Remains:

• Software projects still fail

• Cost overruns still common
• Quality issues persist
• New challenges emerge (security, scale, complexity)

Conclusion: Software engineering continues to evolve, seeking better approaches

7.4 Modularity

Introduction and Definition

Key Point from Section 7.2: To modify software, one must understand the program or at
least the pertinent parts of the program.

The Challenge:

• Understanding is difficult for small programs

• Would be close to impossible for large software systems without modularity

Definition of Modularity: Division of software into manageable units (called modules),

each of which deals with only a part of the software's overall responsibility.

Purpose:

• Make large systems comprehensible

• Enable understanding of parts without understanding whole
• Facilitate modification and maintenance
• Allow multiple developers to work simultaneously
• Enable reuse of components

What Is a Module?

Generic Definition: A module is a manageable unit of software that:

• Has specific, defined responsibility

• Can be understood independently
 • Has clear boundaries
• Interacts with other modules through defined interfaces

Module Characteristics:

Characteristic Description
Self-Contained Contains everything needed for its function
Single Responsibility Focuses on one aspect of overall system
Defined Interface Clear specification of how to interact with it
Independent Can be developed, tested, modified separately
Reusable Potentially usable in different contexts

Modular Implementation

Module Forms Vary by Paradigm:

Critical Understanding: The form modules take is determined by the programming

paradigm being used. This is important because the paradigm determines the underlying
goal during initial software design.

Imperative Paradigm

Module Form: Functions (also called procedures or subroutines)

Design Goal Question: "Is the goal to represent the overall task as individual, manageable
processes?"

Focus:

• Actions that must be performed

• Processes that must execute
• Sequence of operations
• Data transformations
Approach: Identify what needs to be done, break into functions

Object-Oriented Paradigm

Class Objects

Class name PlayerClass

instance of PlayerA
skill
Attributes
endurance
instance o PlayerB
f
serve
Methods
returnVolley

]Module Form: Objects (instances of classes)

Design Goal Question: "Is the goal to identify the objects in the system and understand how
they interact?"

Focus:

• Entities in the system

• Relationships between entities
• Responsibilities of each entity
• Collaborations between entities

Approach: Identify things that exist in problem domain, model as objects

Illustrative Example: Tennis Game Simulation

The Task: Develop a simple modular program to simulate a tennis game

We'll Compare:

1. Imperative paradigm approach

2. Object-oriented paradigm approach

Purpose: Illustrate how paradigm choice affects design thinking

Imperative Paradigm Approach

Design Philosophy: Begin by considering the actions that must take place
Step-by-Step Design Process:

Step 1: Identify First Action

• Each volley begins with a player serving the ball

• Action Needed: Serve
• Function Identified: Serve

Function Serve:

• Inputs: Player's characteristics, some probability

• Processing: Compute initial speed and direction of ball
• Output: Ball trajectory

Step 2: Identify Next Action

• After serve, need to determine path of ball

• Questions to Answer:
o Will it hit the net?
o Where will it bounce?
o Will it land in bounds?
• Function Identified: ComputePath

Function ComputePath:

• Inputs: Ball's initial trajectory

• Processing: Calculate physics of ball motion
• Output: Path information (net hit? bounce location? in bounds?)

Step 3: Continue Process

• Next, determine if other player can return ball

• If yes, compute ball's new speed and direction
• Function Identified: Return

Function Return:

• Inputs: Ball location, player characteristics

• Processing: Determine if player can reach ball, compute return trajectory
• Output: New ball trajectory or miss indication

Step 4: Additional Functions

• Need to update score

 • Function Identified: UpdateScore

Function UpdateScore:

• Inputs: Result of volley (who won point)

• Processing: Update game score
• Output: Updated score

Step 5: Overall Control

• Need function to oversee entire game

• Function Identified: ControlGame

Function ControlGame:

• Purpose: Main game loop, coordinates other functions

• Calls: Serve, Return, ComputePath, UpdateScore

Conclusion of Imperative Approach:

What We've Achieved:

• Very simplistic outline of desired program

• Point has been made about design approach

Key Observation: In accordance with the imperative paradigm, we have been:

• Designing program by considering activities that must be performed

• Obtaining design in which modules are functions
• Focusing on what needs to be done and in what order

Object-Oriented Paradigm Approach

Design Philosophy: Begin by considering the entities (objects) in the system

Step 1: Identify First Objects

Initial Thought:

• There are two players in a tennis game

• Should represent them as two objects: PlayerA and PlayerB

Analysis of Players:
 • Same Functionality: Both can serve and return volleys
• Different Characteristics: May have different skill and strength
• Conclusion: These objects will be instances of the same class

Class Concept Review (from Chapter 6):

Class Definition: A template that defines:

• Methods (functions) to be associated with each object

• Instance Variables (attributes) to be associated with each object

For Our Tennis Game:

• Create class called PlayerClass

• All player objects will be instances of this class

PlayerClass Design:

Attributes (Instance Variables):

Attribute Description Example Values

skill Player's skill level Beginner, Intermediate, Expert
endurance Player's stamina Low, Medium, High

Note: Values reflect the player's characteristics

Methods:

Method Description Purpose

serve() Simulates player serving ball Generate serve based on player's skill
 Method Description Purpose
returnVolley() Simulates player returning ball Generate return based on player's ability

Note: Methods simulate corresponding actions of the player

Design Representation:

┌──────────────────────────────┐
│ PlayerClass │
├──────────────────────────────┤
│ Attributes: │
│ • skill │
│ • endurance │
├──────────────────────────────┤
│ Methods: │
│ • serve() │
│ • returnVolley() │
└──────────────────────────────┘
↑ ↑
│ │
┌────────┐ ┌────────┐
│PlayerA │ │PlayerB │
└────────┘ └────────┘
(instance) (instance)

Important Notation: In Figure 7.4, names of objects are underlined to distinguish them from
names of classes

Object Characteristics:

Object Class Skill Value Endurance Value

PlayerA PlayerClass Expert High
PlayerB PlayerClass Intermediate Medium

Step 2: Identify Next Object

Need: An official to determine whether actions performed by players are legal

Questions the Official Must Answer:

• Did the serve clear the net?

 • Did the serve land in appropriate area of court?
• Was the return legal?
• Did the return land in bounds?

Object Identified: Judge

Judge Object Methods:

Method Description Decision

evaluateServe() Determines if serve is legal Good serve or fault
evaluateReturn() Determines if return is legal Good return or miss

Judge Object Behavior:

• If serve or return is acceptable → play continues

• Otherwise → sends message to another object to record results

Step 3: Identify Scoring Object

Need: Object to keep track of score

Object Identified: Score

Score Object Responsibilities:

• Maintain current game score

• Update score when points are won
• Determine when game/set/match is over

Interaction:

• Judge object sends message to Score object to record results

• Example: "PlayerA won point" or "PlayerB won point"

Current Design Summary:

Four Objects in Tennis Program:

Object Class Type Responsibility

PlayerA PlayerClass Serve and return as first player
PlayerB PlayerClass Serve and return as second player
Judge (Judge class) Evaluate legality of serves and returns
Score (Score class) Maintain and update score
Object Interaction: Sequence of Events

Diagram Notation:

Element Representation
Objects Rectangles
Time Vertical axis (top to bottom = chronological)
Communication Horizontal arrows
Method Calls Labeled arrows

Event Sequence During a Volley:

Event 1: PlayerA Serves

• Action: serve() method called within PlayerA object

• Result: Ball trajectory calculated

Event 2: PlayerA Reports to Judge

• Communication: Arrow from PlayerA to Judge

• Method Called: evaluateServe()
• Data Passed: Serve trajectory information
• Purpose: Judge determines if serve is legal

Event 3: Judge Evaluates Serve

• Decision: Serve is good (cleared net, in service box)

• Action: Judge asks PlayerB to return

Event 4: Judge Asks PlayerB to Return

 • Communication: Arrow from Judge to PlayerB
• Method Called: returnVolley()
• Data Passed: Ball location and trajectory
• Purpose: PlayerB attempts to return ball

Event 5: PlayerB Returns

• Action: returnVolley() method executes

• Result: Return trajectory calculated
• Report: PlayerB reports return to Judge

Event 6: Judge Evaluates Return

• Method Called: evaluateReturn()

• Decision: Return is good
• Action: Continue volley

Event 7: Continue Volley

• Similar sequence continues

• Players alternate returns
• Judge evaluates each shot

Event 8: Volley Terminates

• Trigger: Judge determines PlayerA erred (ball out of bounds)

• Action: Judge sends message to Score object

Event 9: Update Score

• Communication: Arrow from Judge to Score

• Method Called: (update score method)
• Data Passed: PlayerB won point
• Result: Score updated

Comparison to Imperative Example:

Simplicity Level:

• Object-oriented program is very simplistic at this stage

• Similar to imperative example
• Just an outline, not complete implementation

Point Has Been Made: Even at this early stage, can see how object-oriented paradigm
leads to modular design in which fundamental components are objects

Key Differences:
 Imperative Approach Object-Oriented Approach
Modules are functions Modules are objects
Focus on actions Focus on entities
Design around what happens Design around who does what
Structure chart shows function calls Sequence diagram shows object interactions
Data passed between functions Data encapsulated within objects

Coupling

Introduction to the Concept:

Modularity Goal: Produce manageable software where future modifications apply to only a
few modules

The Assumption: Person making modification can concentrate on relevant portion rather
than struggling with entire package

Critical Dependency: This assumption depends on: Changes in one module will not
unknowingly affect other modules in the system

Therefore: A goal when designing modular system should be to maximize independence

among modules

Definition of Coupling:

Coupling: The linkage between modules (known as intermodule coupling)

Design Goal: Minimize coupling

• In other words: Minimize the linkage between modules

• Maximize independence among modules

Coupling as a Metric:

Measurement Purpose: Coupling has been used as a metric to:

• Measure complexity of software system

• Estimate expense of maintaining software

Logic:

• Higher coupling = More interconnected = More complex

• More complex = More expensive to maintain
 • Change in one module likely affects many others

Types of Coupling

Intermodule coupling occurs in several forms

1. Control Coupling

Definition: Occurs when a module passes control of execution to another

Most Common Example: Function call

In Imperative Paradigm:

Example from Structure Chart:

• Arrow from ControlGame to Serve

• Indicates: ControlGame passes control to Serve
• How: Function call - ControlGame calls Serve function
• What Happens:
1. ControlGame executing
2. Calls Serve
3. Control transfers to Serve
4. Serve executes
5. Serve returns
6. Control returns to ControlGame

In Object-Oriented Paradigm:
 PlayerA PlayerB Judge Score

evaluateServe

returnVolley
PlayerA calls the
method evalu ateServe evaluateReturn
in Judge.
returnVolley

evaluateReturn
updateS core

Example from Interaction Diagram:

• Arrows trace path of control

• Passed from object to object
• Example Sequence:
1. Control in PlayerA (executing serve method)
2. PlayerA calls [Link]()
3. Control passes to Judge
4. Judge executes evaluateServe
5. Judge calls [Link]()
6. Control passes to PlayerB
7. And so on...

Characteristics of Control Coupling:

Aspect Description
Visibility Usually explicit and visible in code
Impact Change in called module's interface affects caller
Necessity Some control coupling is necessary for modules to work together
Mitigation Stable interfaces reduce impact of control coupling

2. Data Coupling

Definition: Refers to the sharing of data between modules

Why It's Coupling: If two modules interact with the same item of data:

• Modifications made to one module may affect the other

• Modifications to the format of the data could have repercussions in both modules

Example Problems:
 • Module A expects data in format X
• Module B changes data to format Y
• Module A breaks when it receives format Y
• Module B doesn't know Module A exists or is affected

Two Forms of Data Coupling:

Form 1: Explicit Data Coupling (Parameters)

Mechanism: Explicitly passing data from one function to another in the form of parameters

Structure Chart Representation:

ControlGame

r Id
ye
Pla y
tor
r ajec
T
Serve Return ComputePath UpdateScore

Notation:

• Arrow between functions

• Labeled to indicate data being passed
• Direction of arrow indicates direction of transfer

Example from Figure 7.6:

ControlGame to Serve:

• Data Passed: Player characteristics

• Direction: ControlGame → Serve
• Purpose: Tell Serve which player's characteristics to simulate
• Arrow: Labeled with "PlayerInfo" or similar

Serve to ControlGame:

• Data Passed: Ball trajectory

• Direction: Serve → ControlGame
• Purpose: Report results of serve
• Arrow: Labeled with "BallTrajectory" or similar
Detailed Example:

Function ControlGame:
playerInfo = getPlayerA_Info()
trajectory = Serve(playerInfo) ← Passing data IN
↑ Receiving data OUT
Data coupling

What Happens:

1. ControlGame has playerInfo data

2. Passes it as parameter to Serve
3. Serve uses playerInfo to calculate serve
4. Serve returns trajectory data
5. ControlGame receives and uses trajectory

In Object-Oriented Design:

Similar Data Coupling Occurs Between Objects

Example from Tennis Game:

PlayerA to Judge:

• When PlayerA asks Judge to evaluate its serve

• Must pass trajectory information to Judge
• Judge needs this data to evaluate serve

Sequence:

[Link]():
trajectory = calculateServe()
result = [Link](trajectory) ← Data passed
↑
Data coupling

Benefit of Object-Oriented Paradigm:

Inherent Reduction of Data Coupling:

Why: Methods within an object tend to include all functions that manipulate the object's
internal data

Example:
 • Object PlayerA contains:
o Information about that player's characteristics (skill, endurance)
o All methods that require that information (serve, returnVolley)

Result:

• No need to pass player characteristics to other objects

• Information stays within PlayerA
• Other objects don't need access to PlayerA's internal data

Contrast with Imperative Approach:

• In imperative paradigm:
o Player characteristics might be in separate data structure
o Must be passed to Serve function
o Must be passed to Return function
o More data coupling

Conclusion: Inter-object data coupling is minimized in well-designed object-oriented

systems

Form 2: Implicit Data Coupling (Global Data)

Definition: Data can be shared among modules implicitly in the form of global data

Global Data:

• Data items automatically available to all modules throughout system

• Accessible without explicitly passing as parameters

Contrast:

Global Data Local Data

Accessible to all modules Accessible only within particular module
No need to pass as parameter Must be explicitly passed to other modules
Shared memory location Private to module
Changes visible everywhere Changes only visible in module

Programming Language Support:

Most high-level languages provide ways of implementing both:

• Global data: Declared at program level, all modules can access

• Local data: Declared within module, only that module can access
The Problem with Global Data:

Caution: Use of global data should be employed with caution

Primary Problem: Person trying to modify module dependent on global data may find it
difficult to identify how the module in question interacts with other modules

Why This Is Difficult:

Scenario:

• Module A uses global variable currentScore

• You're modifying Module A
• Questions:
o Which other modules also use currentScore?
o When do they modify it?
o What values might it have?
o Will your changes affect other modules?
o Will other modules' changes break your code?

Without explicit passing:

• No way to see in code which modules share data

• Must search entire program
• Easy to overlook dependencies
• Changes can have unexpected ripple effects

Impact on Modularity:

Problem: Use of global data can degrade the module's usefulness as an abstract tool

Abstract Tool Concept:

• Module should be self-contained

• User of module shouldn't need to know internals
• Module should be "black box"

Global Data Violates This:

• Module depends on external data

• Must understand what other modules do to that data
• Can't use module in isolation
• Not truly self-contained
Example Problem:

Global Variable: gameMode = "normal"

Module A:
if gameMode == "normal":
do_something()

Module B (written later):

gameMode = "training" ← Unintended side effect

Module A now behaves differently!

User of Module A didn't know it depended on gameMode

When Global Data Might Be Acceptable:

Scenario Justification
True constants Values that never change (like π, MAX_PLAYERS)
Configuration Read-only application settings
Carefully managed With clear ownership and access rules
Small programs Where all code is visible and understood

Best Practice:

• Minimize use of global data

• Prefer explicit parameter passing
• Use encapsulation (object-oriented approach)
• If must use global, document dependencies clearly

Cohesion

Equally Important Principle: Just as important as minimizing coupling between modules is

maximizing the internal binding within each module

Definition of Cohesion:

Cohesion: The internal binding within a module

More Specifically: The degree of relatedness of a module's internal parts

Think of it as: How well do the parts of the module "belong together"?

Why Cohesion Matters:

Must Look Beyond Initial Development: To appreciate importance of cohesion, must

consider entire software life cycle

The Problem: If it becomes necessary to make changes in a module, the existence of a

variety of activities within it can confuse what would otherwise be a simple process

Example:

• Need to fix bug in customer name formatting

• Module contains:
o Name formatting
o Email validation
o Address formatting
o Phone number validation
o Shipping calculation
• Problem: Hard to change name formatting without affecting other functions
• Confusion: Which parts relate to names? Which are independent?

Design Goal:

Two-Part Goal:

1. Seek low intermodule coupling (minimize connections between modules)

2. Strive for high intramodule cohesion (maximize internal binding within modules)

Remember:

• Intermodule = between modules (coupling)

• Intramodule = within modules (cohesion)

Types of Cohesion

Cohesion exists on a spectrum from weak to strong

Logical Cohesion (Weaker Form)

Definition: Cohesion within a module induced by the fact that its internal elements perform
activities logically similar in nature
The "Glue" That Holds Module Together: Activities are logically similar

But: Activities may be quite different in implementation and purpose

Example: Communication Module

Module Purpose: Perform all of system's communication with outside world

What It Contains:

Activity Logical Category Actual Purpose

Get user input Communication Obtaining data
Display results Communication Reporting results
Read from file Communication Data retrieval
Write to file Communication Data storage
Send network message Communication External communication
Receive network message Communication External communication

The Cohesion:

• All activities deal with communication

• That's their logical similarity
• That's what holds them together

The Problem:

• Topics of communication vary greatly

• Some obtain data, others report results
• Different data formats
• Different error handling
• Different protocols
• Result: Weak internal binding despite logical similarity

Why Logical Cohesion Is Weak:

Modification Scenario:

• Need to change how user input is obtained

• Must find relevant code within large communication module
• Must ensure change doesn't affect file I/O or network communication
• Hard to separate concerns
• Changes risky due to variety of activities
Functional Cohesion (Stronger Form)

Definition: All the parts of the module are focused on the performance of a single activity

The Key: Single activity - not just logically related, but truly working together toward one
specific goal

Characteristics:

Aspect Description
Purpose One clear, focused purpose
Parts All parts contribute to that one purpose
Independence Module can be understood in isolation
Naming Module name is a verb phrase (like "CalculatePayroll")
Understandability Easy to understand what module does
Modifiability Easy to modify without unintended effects

Example: CalculateTax Module

Single Purpose: Calculate tax on a purchase

What It Contains:

Part Contribution to Single Purpose

Get subtotal Necessary for tax calculation
Determine tax rate Necessary for tax calculation
Apply rate to subtotal Core tax calculation
Round to currency Necessary for final result
Return tax amount Deliver result

The Cohesion:

• Every part exists to support the single goal of calculating tax

• Nothing extra
• Nothing unrelated
• Strong internal binding

How to Increase Functional Cohesion:

In Imperative Design:

Technique: Isolate subtasks in other modules, then use these modules as abstract tools
Example from Tennis Simulation:

Module: ControlGame

Single Purpose: Oversee the game

How It Achieves Functional Cohesion:

• Uses other modules as abstract tools:

o Serve - abstract tool for serving
o Return - abstract tool for returning
o ComputePath - abstract tool for path calculation
o UpdateScore - abstract tool for scoring

Result:

• ControlGame can concentrate on overseeing the game

• Not distracted by details of serving, returning, scoring
• Each of those is handled by functionally cohesive module
• ControlGame itself is functionally cohesive (single purpose: game control)

Benefits of Functional Cohesion:

Benefit Explanation
Understandability Clear single purpose easy to grasp
Maintainability Changes localized to relevant module
Testability Can test single function thoroughly
Reusability Focused modules more reusable
Reliability Easier to ensure correctness

In Object-Oriented Designs:

Challenge: Entire objects are usually only logically cohesive

Why: Methods within an object often perform loosely related activities

The Common Bond: Only common bond is that they are activities performed by the same
object

Example from Tennis Simulation:

Each Player Object Contains:

Method Activity Type

serve() Serving ball
returnVolley() Returning ball

Analysis:

• Serving and returning are significantly different activities

• Different calculations
• Different physics
• Different decision-making

Result: Object as a whole is only logically cohesive

• Bound together by being "player activities"

• Not all focused on single activity

Solution for Object-Oriented Designs:

Object

Each method
Perform within the object is
action A functionally cohesi ve

Perform Perform
action B action C

Each object is only logically cohesi ve

Strive for Functional Cohesion at Method Level:

Even though object in its entirety is only logically cohesive, each individual method within
object should perform only one functionally cohesive task

Diagram Explanation:

Object Level (Logical Cohesion):

┌────────────────────────────┐
│ PlayerObject │
│ (Logically Cohesive) │
├────────────────────────────┤
│ serve() │ ← Functionally cohesive
│ returnVolley() │ ← Functionally cohesive
│ updatePosition() │ ← Functionally cohesive
└────────────────────────────┘

Each Method (Functional Cohesion):

• serve() method:
o Single purpose: Calculate and execute serve
o All code in method supports this one purpose
o Functionally cohesive
• returnVolley() method:
o Single purpose: Calculate and execute return
o All code in method supports this one purpose
o Functionally cohesive

Best Practice:

Two-Level Cohesion in OOP:

Level Cohesion Type Strategy

Object Logical Group related responsibilities
Method Functional Each method has single, focused purpose

Result:

• Objects provide logical organization

• Methods provide functional implementation
• Best of both worlds

Information Hiding
Introduction:

One of the Cornerstones of Good Modular Design: Captured in the concept of

information hiding

Definition of Information Hiding:

Information Hiding: The restriction of information to a specific portion of a software

system

Broad Interpretation of "Information":

The term "information" should be interpreted in a broad sense, including any knowledge
about the structure and contents of a program unit

What "Information" Includes:

Type of Information Examples

Data Variables, constants, data values
Data Structure Types Arrays, linked lists, trees, hash tables
Encoding Systems Character encoding, number representation
Internal Compositional Structure How module is organized internally
Logical Structure of Procedural Units Algorithms, control flow
Any Other Internal Properties Implementation details, optimizations

The Point of Information Hiding:

Primary Goal: Keep the actions of modules from having unnecessary dependencies or
effects on other modules

What Could Go Wrong Without Information Hiding:

Problem 1: Data Corruption

• Module does not restrict use of its internal data from other modules
• Other modules can access and modify the data
• Data may become corrupted by other modules
• Original module doesn't know why its data is wrong

Problem 2: Structural Dependencies

• One module is designed to take advantage of another's internal structure

• Later, that internal structure is altered (perhaps for optimization)
 • First module malfunctions
• Developer who changed internal structure didn't know other module depended on it

Example of Information Hiding Violation:

Bad Design:

Module A:
data stored in array at positions 0-99

Module B (poorly designed):

directly accesses Module A's array
assumes array size is 100

Components

Background: The Building Block Problem

Previously Mentioned Obstacle: One major obstacle in the field of software engineering is
the lack of prefabricated "off-the-shelf" building blocks from which large software systems
can be constructed.

The Promise: The modular approach to software development promises hope in addressing
this obstacle.

Why Object-Oriented Programming Offers Special Promise

Characteristics of Objects:

Objects Form Complete Units:

• Self-contained packages
• Everything needed for their function is included
• Independent of specific application context

Objects Have Clear Interfaces:

• Well-defined boundaries with their environments

• Specified ways to interact with them
• Hidden internal implementation

The Reusability Potential:

Once an object, or more correctly a class, has been designed to fulfill a certain role:
 • It can be used to fulfill that role in any program requiring that service
• Not limited to original application
• Can be "dropped in" to different systems
• Acts as true building block

Example of Reusable Object:

Class: EmailValidator

Original Use: Created for user registration system

Reusable In:

• Contact forms
• Newsletter signup
• Account recovery
• Any system needing email validation

Why It's Reusable:

• Self-contained (doesn't depend on specific registration system)

• Clear interface (give email string, get valid/invalid result)
• Hidden implementation (caller doesn't care how validation works)

The Role of Inheritance

Inheritance Provides: A means of refining prefabricated object definitions

When Needed: In cases where definitions must be customized to conform to needs of a

specific application

Without Inheritance:

• Would need to modify original class (risky)

• Or create completely new class (wasteful)
• Lose benefit of existing, tested code

With Inheritance:

• Start with existing class

• Add application-specific features
• Keep all original functionality
• Don't modify original (safe)
Example of Inheritance for Customization:

Scenario: Building graphics application

Existing Class: Generic Shape class (from library)

• Has position, color, visibility

• Has draw(), move(), hide() methods

Your Need: Circle with radius

Solution:

Class Circle inherits from Shape:

Add attribute: radius
Add method: calculateArea()
Override method: draw() (to draw circle specifically)

Keep from Shape:

- position, color, visibility
- move(), hide() methods

Benefit:

• Don't rebuild basic shape functionality

• Customize only what's needed
• Tested Shape code remains reliable

Prefabricated Templates in Modern Languages

It's Not Surprising: Object-oriented programming languages C++, Java, and C# are
accompanied by collections of prefabricated "templates" from which programmers can easily
implement objects for performing certain roles.

Language-Specific Libraries:

Language Library Name Purpose

C++ Standard Template Library
C++ Generic data structures and algorithms
(STL)
Java Application Programmer Comprehensive class library for all
Java
Interface (API) development needs
Complete framework for Windows and web
C# .NET Framework Class Library
applications
What These Libraries Provide:

Data Structures:

• Lists (dynamic arrays)

• Sets (unique collections)
• Maps/Dictionaries (key-value pairs)
• Stacks, Queues
• Trees, Graphs

Algorithms:

• Sorting (quicksort, mergesort, etc.)

• Searching (binary search, etc.)
• String manipulation
• Mathematical operations

Input/Output:

• File reading/writing
• Console I/O
• Stream processing
• Serialization

Networking:

• HTTP clients/servers
• Socket programming
• Web services
• Email protocols

GUI Components:

• Buttons, text fields

• Windows, dialogs
• Menus, toolbars
• Graphics and drawing

Database Access:

• Connection management
• Query execution
• Result set handling
• Transaction management

And Much More:

• Threading and concurrency

• Security and encryption
• XML/JSON processing
 • Regular expressions

The Limitation of Objects as Building Blocks

Important Recognition:

The fact that objects and classes have the potential of providing prefabricated building blocks
for software design does not mean that they are ideal.

The Problem:

Objects and classes provide relatively small blocks from which to build.

Analogy:

Building a House Building Software

With Objects: Small units, many needed,
With Bricks: Small, many needed, slow
complex assembly
With Prefab Panels: Large sections, With Components: Larger units, fewer needed,
fewer needed, faster simpler assembly

Specific Issues:

Too Granular:

• Individual objects often too fine-grained

• Need dozens or hundreds for complete feature
• Assembly becomes complex task itself

Example: To build shopping cart functionality:

• Need Product object

• Need Inventory object
• Need Cart object
• Need Item object
• Need PriceCalculator object
• Need TaxCalculator object
• Need ShippingCalculator object
• Need PaymentProcessor object
• ...and many more

Problem: Managing all these small pieces is itself a major task

The Solution: Components (Higher-Level Building Blocks)

Component Definition:

An object is actually a special case of the more general concept of a component, which is, by
definition, a reusable unit of software.

Key Distinction:

Object Component
Typically small, focused Larger, more complete
Single responsibility Multiple related responsibilities
Fine-grained Coarse-grained
Building block Sub-system

In Practice:

Most components are based on the object-oriented paradigm and take the form of a collection
of one or more objects that function as a self-contained unit.

Component Characteristics:

Self-Contained:

• Contains everything needed for its function

• Multiple objects working together
• Internal coordination handled internally
• External users see unified interface

Example Component: Shopping Cart Component

Contains Internally:

• Product objects
• Cart object
• Item objects
• PriceCalculator object
• TaxCalculator object
• DiscountCalculator object

Provides External Interface:

• addItem(product, quantity)
• removeItem(itemId)
• updateQuantity(itemId, newQuantity)
• getTotal()
• checkout()

Hides Internal Complexity:

 • User doesn't manage individual objects
• Component handles object coordination
• Single, coherent interface

Component Architecture

Emerging Field:

Research in the development and use of components has led to the emerging field known as
component architecture (also known as component-based software engineering)

Traditional Role vs New Role:

Traditional Programmer Component Assembler

Writes code from scratch Selects prefabricated components
Designs algorithms Connects components
Debugs logic Configures components
Low-level focus High-level focus

The Component Assembler Role:

Definition: Person who constructs software systems from prefabricated components

Working Environment: In many development environments, components are displayed as

icons in a graphical interface

Methodology: Rather than be involved with internal programming of components:

1. Select pertinent components from collections of predefined components

2. Connect them (with minimal customization)
3. Obtain desired functionality

Visual Development:

• Drag and drop components onto design surface

• Set properties through property sheets
• Connect components by drawing connections
• Configure behavior through dialogs

Well-Designed Component Properties:

Key Property: A property of a well-designed component is that it can be extended to

encompass features of a particular application without internal modifications
How This Works:

Through Configuration:

• Components have configurable properties

• Set through external parameters
• No code changes needed

Through Standardized Extension Points:

• Components provide "hooks" for extensions

• Plug in custom behavior
• Component manages integration

Example:

Report Generator Component:

Out of Box:

• Generates basic reports

• Standard formatting
• Common data sources

Configuration:

• Set report title through property

• Choose columns to display
• Select sorting order
• No programming needed

Extension:

• Plug in custom data formatter

• Add custom calculation
• Component calls your code at right time
• Component handles rest

Component Architecture in Smartphone Systems

Fertile Ground: An area where component architectures have found fertile ground is in
smartphone systems

Why Smartphones Use Component Architecture:

Primary Motivation: Due to the resource constraints of these devices

Resource Constraints:
 Constraint Impact
Limited Memory Can't load entire application at once
Limited Battery Can't keep everything running
Limited Processing Must be selective about what runs
User Expectations Must appear fast and responsive

How Smartphone Applications Are Structured:

Application Structure: Applications are actually a set of collaborating components, each

of which provides some discrete function for the application

Lifecycle Management: Each of these components is individually started and stopped as

needed to service the user efficiently

User Experience: However, the application appears as a seamless series of displays and
actions

Examples of Smartphone Components:

Display Components:

Each Screen is a Component:

• Login screen = LoginComponent

• Main menu = MenuComponent
• Settings screen = SettingsComponent
• Profile screen = ProfileComponent

Starting/Stopping:

• User navigates to Settings

• System starts SettingsComponent
• System may stop MenuComponent to free memory
• User presses Back
• System starts MenuComponent
• System may stop SettingsComponent

User Doesn't Notice:

• Appears continuous
• No visible loading (if well-designed)
• Smooth transitions

Service Components (Behind the Scenes):

Memory Card Access Component:

• Purpose: Store and access information on memory card

• Started: When app needs to save/load data
• Stopped: When operation complete
• Example: Photo app saves picture

Music Player Component:

• Purpose: Perform continuous function (playing music)

• Started: When user plays song
• Continues: Even when user switches to other app
• Stopped: When user stops playback
• Example: Music plays while using other apps

Internet Access Component:

• Purpose: Access information over Internet

• Started: When app needs network data
• Stopped: When data retrieved
• Example: News app fetches latest stories

Efficiency Benefits:

Resource Management:

Without Components:

• Entire app loaded in memory

• All features running
• Battery drains quickly
• Memory fills up

With Components:

• Only active components loaded

• Inactive components stopped
• Memory freed when not needed
• Battery lasts longer

Example:

User reading email:

• Email display component running

• Compose component stopped (not needed)
• Settings component stopped (not needed)
• Network component stopped (already loaded emails)
Result: Less memory used, longer battery life

Integration Between Applications

Aside from Resource Limitations: The component architecture of smartphones pays

dividends in integration between applications

Key Concept: Applications can use components from other applications

Example 1: Facebook Integration

Scenario:

Facebook Application: When executed on smartphone, may use components of the contacts
application to add all Facebook friends as contacts

How It Works:

Contacts Application Provides:

• ContactManager component
• addContact() method
• getContact() method
• Other contact management methods

Facebook Application:

• Doesn't build its own contact management

• Uses ContactManager component from Contacts app
• Calls addContact() for each Facebook friend
• Data stored in central contact database

User Benefit:

• Facebook friends appear in contacts

• Can call/text friends directly from contacts
• Don't need to manually enter contact info

Example 2: Caller ID Integration

Multiple Apps Working Together:

Telephony Application: The application that handles functions of the phone

(making/receiving calls)
Contacts Application: Stores contact information

Facebook Application: Has friend photos and status updates

Integration Sequence:

Incoming Call Received:

Step 1: Telephony app receives call

• Gets caller's phone number

Step 2: Telephony app accesses Contacts component

• Looks up phone number

• Retrieves contact name

Step 3: Contacts app provides Facebook link

• Contact is linked to Facebook friend

Step 4: Telephony app accesses Facebook component

• Retrieves friend's profile picture

• Retrieves friend's last status update

Step 5: Telephony app displays:

• Caller's name (from Contacts)

• Caller's photo (from Facebook)
• Caller's last post (from Facebook)

Visual Example:

Phone rings, screen shows:

┌─────────────────────────┐
│ Incoming Call │
├─────────────────────────┤
│ [Photo of friend] │ ← From Facebook
│ │
│ John Smith │ ← From Contacts
│ Mobile │
│ │
│ "Just landed in NYC!" │ ← Last Facebook post
│ │
│ [Answer] [Decline] │
└─────────────────────────┘

Without Component Integration:

┌─────────────────────────┐
│ Incoming Call │
├─────────────────────────┤
│ 555-1234 │ ← Just phone number
│ │
│ [Answer] [Decline] │
└─────────────────────────┘

Technical Implementation:

Component Sharing Mechanism:

Android Example:

• Uses "Content Providers" to share data

• Uses "Intents" to share functionality
• Applications declare components they provide
• Other applications can use declared components
• Operating system manages access and security

Benefits:

Benefit Description
No Duplication Don't reimplement contact management in every app
Consistency All apps use same contact data
Richer Features Apps can leverage each other's capabilities
Smaller Apps Don't need to include functionality already available
Better Integration System feels unified, not fragmented

Security Considerations:

Component Permissions:

Applications must declare what components they want to access:

• User must grant permission

• Example: Facebook asks permission to access contacts
 • User can deny if concerned about privacy

Component Isolation:

Each application's components are protected:

• Can't access another app's components without permission

• Operating system enforces boundaries
• Malicious apps can't steal data

7.5 Tools of the Trade - Study Notes

Overview
This section explores modeling techniques and notational systems used during the analysis
and design stages of software development. It covers both traditional tools from the
imperative paradigm era and modern object-oriented tools.

Some Old Friends

Dataflow Diagrams

Purpose: Represent how data moves through a system by studying data flow to identify
processing points.

Components:

• Arrows: Represent data paths

• Ovals: Represent points where data manipulation occurs
• Rectangles: Represent data sources and stores

Example Application: Hospital patient billing system

• Shows how Payments and PatientRecords merge at ProcessPayments

• Shows UpdatedRecords flowing back to hospital files
 tient records
pa

nts Process Hospital

me Files
ay Payments

p
pd s

u
Patient a te d re c o r d

ds
c or
Process re
b ill
s Bills p at ie nt

Benefits:

• Assists in identifying procedures during design stage

• Useful for understanding proposed systems during analysis stage
• Improves communication between clients and software engineers
• Continues to be valuable even as imperative paradigm has faded

Data Dictionary

Definition: A central repository of information about data items appearing throughout a

software system.

Information Included:

• Identifier used to reference each item

• Valid entries for each item (numeric, alphabetic, value ranges)
• Storage location (file or database)
• Where the item is referenced in the software (which modules)

Goals:

1. Improve Communication
o Ensures important details are revealed during analysis stage
o Example: Discovering that part numbers are not actually numeric
2. Establish Uniformity
o Surfaces redundancies and contradictions
o Examples:
§ PartNumber in inventory vs. PartId in sales records
§ "Name" referring to employees vs. parts in different departments

Unified Modeling Language (UML)

Introduction
Definition: A modern collection of tools developed specifically for the object-oriented
paradigm.

Use Case Diagrams

Purpose: Capture the image of the proposed system from the user's point of view.

Components:

• Large rectangle: Represents the proposed system

• Ovals: Represent interactions (called use cases)
• Stick figures: Represent users (actors) - even if not actual people

Example: Hospital Records System

• Actors: Physicians and Nurses

• Use case: Retrieve Medical Records

Hospital R ecords System

Retrieve Medical
Record

Update Medical
Physician Record Nurse

Retrieve Laboratory
Results

Update Laboratory
Results

Laboratory
Technician
Retrieve Financial
Records

Update Financial
Administrator Records

Class Diagrams

Purpose: Represent the structure of classes and relationships (associations) between classes.
Components:

• Rectangles: Represent classes

o Can show class name, attributes, and methods
• Lines: Represent associations between classes
• Labels: May appear on association lines
• Bold arrowhead: Indicates direction to read the label

Example Relationships:

• Physician "cares for" Patient

• Patient "occupies" Room / Room "hosts" Patient

Physician
1
Patient Room
*0 or 1 occupies
1
hosts
cares for

Association Multiplicities

Definition: Indicates how many instances of one class may be associated with instances of
another.

Notation:

• Numbers at ends of association lines

• Asterisk (*): Arbitrary nonnegative number
• "0 or 1": Zero or one instance
• "1": Exactly one instance

Example Interpretations (from hospital system):

• Each patient can occupy one room

• Each room can host zero or one patient (private rooms)
• Each physician may care for many patients (*)
• Each patient is cared for by one physician (primary physician only)

Three Basic Forms:

1. One-to-One Relationship
o Example: Patients and occupied private rooms
o Each patient → one room
o Each room → one patient
2. One-to-Many Relationship
o Example: Physicians and patients
o One physician → many patients
o Each patient → one (primary) physician
 3. Many-to-Many Relationship
o Example: Including consulting physicians
o Each physician → many patients
o Each patient → many physicians

One-to-one One-to-many Many-to-many

Entities of Entities of Entities of Entities of Entities of Entities of

type x type y type x type y type x type y

Generalizations in Class Diagrams

Definition: When one class represents a more specific version of another class.

Notation:

• Arrows with hollow arrowheads: Represent generalization associations

• Rectangle format shows: class name, attributes, and methods

Example: Medical Records Hierarchy

• MedicalRecord (general class)

o Contains: patient, doctor, date of record
o Method: printRecord
• SurgicalRecord (specialized)
o Inherits all from MedicalRecord
o Additional attributes: surgical procedure, hospital, discharge date
o Additional method: discharge patient
o Specialized printRecord method
• OfficeVisitRecord (specialized)
o Inherits all from MedicalRecord
o Additional attributes: symptoms, diagnosis
o Specialized printRecord method
 MedicalR ecord

dateOfRecord
patient
doctor

printRecord

SurgicalRecord OfficeVisitRecord

surgicalProcedure symptoms
hospital diagnosis
dateOfDischarge

dischargePatient printRecord
printRecord

Important Caution About Inheritance

Warning: Inheritance should not be used for all cases of generalization.

Reason: Inheritance introduces strong coupling between classes that may not be desirable
later.

Problem: Changes within a class are automatically reflected in all classes that inherit from it,
potentially causing unforeseen consequences.

Example of Problematic Use:

• Creating RecreationMember class from Employee class

• Works initially (all recreation members are employees)
• Fails when company expands facility to:
o Dependents of employees
o Company retirees
• Requires severing the coupling between Employee and RecreationMember classes

Best Practice: Use inheritance only for immutable generalizations, not just for convenience.

Interaction Diagrams

Purpose: Express dynamic features and sequences of events during execution (unlike class
diagrams which show static features).

Types: Various types exist within UML; we focus on sequence diagrams.

Sequence Diagrams

Purpose: Depict communication between individuals (actors, software components, or

objects) involved in performing a task.

Components:

• Rectangles: Represent individuals

• Dashed lines extending downward: Part of life line
• Life line: Rectangle + dashed line together
• Labeled arrows: Represent communication/requested actions
o Connect appropriate life lines
o Label indicates action being requested
• Unlabeled arrows pointing back: Represent return of control (like return from
procedure)
• Chronological order: Read from top to bottom

Frame Components:

• Rectangle: Encloses entire diagram

• Pentagon (upper left): Contains "sd" (sequence diagram) + identifier
o Identifier may be: name of sequence OR name of initiating method

Advanced Features:

1. Interaction Fragments: Represent alternative sequences a. "loop" fragment:

o Like while structure
o Events repeat while condition is true
o Example: "while validPlay is true"

b. "alt" fragment:

o Like if-else structure

o One alternative performed based on condition
o Example: "if fromServer is true or false"

Example: Tennis game volley

• Shows generic volley, not specific instance

• Players represented as objects of "PlayerClass"
• One player designated "self" (initiates serve)
• Demonstrates symmetry between players in single diagram
 sd serve

self : PlayerClass : PlayerClass Judge Score

evaluateServe

loop [validPlay == true]

Designates the
condition
alt [fromServer == true] controlling the
interaction
returnVolley
fragment
Designates the
interaction fragment evaluateReturn
type
[fromServer == false]
returnVolley

evaluateReturn

updateScore

CRC Cards (Class-Responsibility-Collaboration)

Note: Not part of UML but important for validating object-oriented designs.

Definition: Physical cards (like index cards) containing object descriptions.

Methodology:

1. Create one card for each object in proposed system

2. Use cards to represent objects in system simulation
3. Conduct simulation via:
o Desktop arrangement, OR
o "Theatrical" experiment where team members hold cards and play roles

Alternative Name: Structured walkthroughs

Purpose: Identify flaws in design before implementation.

Design Patterns
Definition

Design pattern: A predeveloped model for solving a recurring problem in software design.
The Adapter Pattern

Problem Addressed: Incompatible interfaces when using prefabricated modules.

Scenario:

• Prefabricated module has needed functionality

• BUT has incompatible interface with current application

Solution:

• "Wrap" original module inside another module

• Wrapper translates between original module's interface and outside world
• Allows use of original prefabricated module in application

The Decorator Pattern

Problem Addressed: Systems performing different combinations of same activities

depending on situation.

Challenge: Can lead to explosion of options and enormously complex software.

Solution: Provides standardized way of implementing such systems, leading to manageable

solution.

Design Pattern Development Process

Ongoing Activities:

• Identifying recurring problems

• Creating design patterns to solve them
• Cataloging patterns for reuse

Goals:

• Not just finding solutions

• Finding high-quality solutions
• Providing flexibility later in software life cycle
• Incorporating good design principles:
o Minimizing coupling
o Maximizing cohesion

Design Patterns in Modern Tools

Examples of Implementation:

• Java programming environments (provided by Oracle)

• .NET Framework (provided by Microsoft)

Library Contents: Many templates are essentially design pattern skeletons providing ready-
made, high-quality solutions.

Historical Connection

Origins: Research of Christopher Alexander in traditional architecture.

Alexander's Goal:

• Identify features contributing to high-quality architectural designs

• Develop design patterns incorporating those features
• Applied to buildings and building complexes

Current Impact:

• Many ideas incorporated into software design

• Work continues to inspire software engineers
• Example of how diverse fields contribute to each other

Key Takeaways
1. Traditional Tools (dataflow diagrams, data dictionaries) remain useful despite
paradigm shifts
2. UML provides comprehensive toolkit for object-oriented design:
o Use case diagrams: User perspective
o Class diagrams: Static structure
o Sequence diagrams: Dynamic behavior
3. Design patterns provide tested solutions to recurring problems
4. Cross-disciplinary inspiration: Software engineering benefits from traditional
architecture concepts

9.1 Database Fundamentals - Study Notes

Overview
A database is a collection of data that is multidimensional, with internal links between
entries making information accessible from multiple perspectives. This contrasts with
traditional flat files (one-dimensional storage presenting information from a single point of
view).
Example:

• Flat file: Compositions listed by composer only

• Database: Works by single composer, composers of specific music types, composers
who wrote variations of other works

The Significance of Database Systems

Historical Context

Problem in Early Computing:

• Each application implemented as separate system with own data collection

• Payroll → payroll file
• Personnel → employee records
• Inventory → inventory file
• Result: Information duplicated throughout organization, related items stored
separately

Emergence of Database Systems

Purpose: Integrate information stored and maintained by an organization

 a. File-oriented information system

Customer Payroll Employee Inventory Sales

records records records records records

Customer
service Payroll Per sonnel Purchasing Mark eting
department department department department department

b. Database-oriented information system

Management

Customer
Mark eting
service
department
department

Integrated
database

Payroll Purchasing
department department

Per sonnel
department

Benefits of Integration:

• Same sales data used for multiple purposes:

o Produce restocking orders
o Create market trend reports
o Direct advertisements to likely customers
o Generate sales force bonus checks

Modern Database Applications

Management Tool:

• Combined with data mining techniques

• Extracts pertinent information from enormous data amounts
• Covers all aspects of organization and environment

Web Integration:

• Underlying technology for popular websites (Google, eBay, Amazon)

• Process:
 1. Server interrogates database in response to client request
2. Organizes results as web page
3. Sends page to client

New Role: Database as company's product (not just record storage)

Impact: Internet has become major worldwide information source

The Role of Schemas

Security Concerns

Problem: Proliferation of database technology creates risk of unauthorized access to

sensitive data

Examples of Needed Restrictions:

• Website customer → should NOT access company's financial data

• Benefits department employee → needs employee records, NOT inventory/sales
records

Key Principle: Ability to control access is as important as ability to share information

Schema Definition

Schema: Description of entire database structure used by database software to maintain the
database

Subschema: Description of only the portion of database pertinent to a particular user's needs

University Database Example

Schema Contents:

• Student records contain:

o Current address and phone number
o Academic record
• Links to faculty adviser records
• Faculty records contain:
o Address
o Employment history
o Other information
• Linkage system connects student information to faculty employment history
Subschema for Registrar:

• Can access: Which faculty member is student's adviser

• Cannot access: Employment history of faculty
• Prevents: Obtaining privileged information about faculty

Subschema for Payroll Department:

• Can access: Employment history of each faculty member

• Cannot access: Linkage between students and advisers
• Result: Can modify faculty salary but cannot obtain names of advised students

Database Management Systems

Software Layer Architecture

Two Major Layers:

1. Application Layer
o Handles communication with database user
o Can be complex (e.g., website-based access)
o Components:
§ Clients throughout Internet
§ Server using database to fill client requests
2. Database Management Layer
o Contains DBMS
o Performs actual database manipulation

Application Database Actual

User software management database
system

Database seen in Database seen in Database seen in

terms of the terms of a its actual
application database model organization

DBMS Role and Functionality

Key Principle: Application software does NOT directly manipulate database

DBMS Functions:

• Application software determines user's request

• Uses DBMS as abstract tool to obtain results
 • For add/delete requests: DBMS alters database
• For retrieval requests: DBMS performs required searches

Benefits of Application/DBMS Separation

1. Abstract Tool Construction

• Isolates database storage details within DBMS

• Simplifies application software design
• Example: Application doesn't need to know if database is:
o Stored on single machine, OR
o Scattered across network (distributed database)
• DBMS handles these issues transparently

2. Access Control

• DBMS performs all database access

• Can enforce restrictions imposed by subschemas
• Process:
o DBMS uses entire database schema for internal needs
o Requires application software to remain within user's subschema bounds

3. Data Independence

• Definition: Ability to change database organization without changing application

software

Example Scenario:

• Personnel department adds field to employee records (health insurance participation)

• Without DBMS separation:
o Would require modifications to ALL application programs
o Changes payroll program, mailing label program, etc.
• With DBMS separation:
o Change only overall schema
o Change subschemas of involved users
o Other users' subschemas remain unchanged
o Their application software doesn't need modification

Distributed Databases
Definition

Distributed database: Database consisting of data residing on different machines

Example: International corporation storing local employee records at local sites, linked via
network

Types of Distribution

1. Fragmented Data

• Different fragments stored in different locations

• Example: Employee records split by location

2. Replicated Data

• Duplicates of same database component at different locations

• Purpose: Reduce information retrieval time

Challenges

Problems Not Present in Centralized Databases:

1. How to disguise distributed nature so system functions coherently

2. How to ensure replicated portions remain duplicates as updates occur

Current Status: Active area of research

Database Models
Purpose of Abstraction

DBMS Use of Abstraction:

• Hides complexities of database's internal structure

• Allows users to imagine information arranged in more useful format
• Contains routines translating conceptual commands into actual storage actions

Database Model Definition: Conceptual view of the database

Relational Database Model

Conceptual View: Collection of tables with rows and columns

Example: Employee information

 • Table structure:
o One row per employee
o Columns: name, address, employee ID, etc.

DBMS Capabilities (even though not actually stored in rows/columns):

• Select entries from particular table row

• Report range of values in salary column

How Application Software Uses Models

Integration with Programming Languages:

• Application software written in general-purpose languages (Chapter 6)

• These languages provide:
o Basic ingredients for algorithmic expressions
o Lack database manipulation instructions
• Solution: Use DBMS routines as prewritten subroutines
• Effect: Extends language capabilities to support database model

Routines as Abstract Tools:

• Application software accesses database through DBMS routines

• Can interact as if database stored in conceptual model format

Ongoing Research

Goals:

• Find models allowing easy conceptualization of complex data systems

• Lead to concise ways of expressing information requests
• Produce efficient database management systems

Key Takeaways
1. Database vs. Flat File: Multidimensional vs. one-dimensional access
2. Integration: Database systems integrate organizational information
3. Security: Schemas and subschemas control access
4. Layered Architecture: Application layer + DBMS layer
5. Benefits: Abstraction, access control, data independence
6. Distributed Systems: Active research area with unique challenges
7. Models: Conceptual views that simplify database interaction
9.2 The Relational Model - Study Notes
Overview
The relational database model portrays data as stored in rectangular tables called relations,
similar to spreadsheet format.

Basic Terminology
Tuple

Definition: A row in a relation

• Pronunciation: "TOO-pul" or "TUH-pul"

• Example: In employee relation, each tuple = information about one particular
employee

Attribute

Definition: A column in a relation

• Reason for name: Each column entry describes some characteristic (attribute) of the
entity
• Example: Name, Address, SSN are attributes of employee

Issues of Relational Design

The Challenge

Key Point: Designing relations is NOT a simple task despite appearances—many subtleties
await unwary designers
Example Problem: Adding Job History

Initial Scenario: Extend employee relation to include job information

Desired Attributes:

• Job title (secretary, office manager, floor supervisor)

• Job identification code (unique to each job)
• Skill code associated with job
• Department where job exists
• Start date and termination date
• Asterisk (*) = current position

First Approach: Single Extended Relation

Method: Add job attributes as additional columns

Problems Identified:

1. Inefficiency Due to Redundancy

• No longer one tuple per employee

• Now one tuple per job assignment
• Result: Multiple tuples for employees with multiple jobs
o Baker's personal info repeated (held multiple jobs)
o Smith's personal info repeated (held multiple jobs)
• Job descriptions duplicated when multiple employees held same position
o Floor manager job duplicated (multiple employees held it)

2. Information Loss Problem Scenario: Joe E. Baker is only employee to hold job D7

• If Baker leaves company and is deleted

• Result: Lose all information about job D7
 • Only tuple containing "job D7 requires skill level K2" is Baker's tuple

3. Partial Tuple Complications

• Could erase only portion of tuple, but introduces complications:

o Should job F5 info be retained in partial tuple?
o Does this info reside elsewhere?
• Temptation to use partial tuples = strong indication design can be improved

Root Cause Analysis

Problem: Combined more than one concept in single relation

Extended Relation Contains:

1. Employee information: name, ID, address, SSN

2. Job information: job ID, title, department, skill code
3. Relationship information: start date, termination date

Solution: Three-Relation Design

Approach: Create separate relation for each category

Three Relations:

1. EMPLOYEE relation

• Original relation from Figure 9.3

• Contains employee information

2. JOB relation

• Contains available jobs information

• Attributes: Job ID, Job Title, Skill Code, Dept

3. ASSIGNMENT relation

• Contains job history/relationship information

• Attributes: Empl ID, Job ID, Start Date, Term Date

Benefits of Three-Relation Design

Direct Information Storage:

• Employee info → EMPLOYEE relation

• Job info → JOB relation
• Job history → ASSIGNMENT relation

Implicit Information (obtained by combining relations): Example Process (finding

departments where employee worked):

1. Use employee ID in ASSIGNMENT relation → find all jobs held

2. Use job IDs in JOB relation → find departments for those jobs
Result: Any information from large single relation obtainable from three smaller relations
WITHOUT previous problems

Caution: Decomposition Problems

Important: Dividing relations not always trouble-free

Example of Problematic Decomposition:

Original Relation: EmplId, JobTitle, Dept (single relation)

Proposed Decomposition: Two relations

Problem:

• Appears to contain same information

• Actually does NOT

Specific Issue (finding employee's department):

• Single-relation system:
o Interrogate tuple with employee ID
o Extract corresponding department
o ✓ Works correctly
• Two-relation system:
o Can find employee's job title
o Can find department with that job title
o ✗ Does NOT mean employee works in that department
o Reason: Several departments might have jobs with same title

Lossless Decomposition

Definition: Decomposition that does NOT cause loss of information

Alternative Names:

• Lossless decomposition
• Nonloss decomposition

Design Considerations:

• Important relational characteristic

• Goals:
1. Identify relational characteristics that can lead to problems
2. Find ways to reorganize relations to remove problematic characteristics

Relational Operations
Overview

Purpose: Extract information from database consisting of relations

SELECT Operation

Purpose: Select certain tuples from a relation based on characteristics

Examples of Use:

• Retrieve employee information (select tuple with specific ID)

• Obtain job titles in certain department (select tuples with specific department)

Result: New relation consisting of selected tuples from parent relation

Syntax:

NEW ← SELECT from EMPLOYEE where EmplId = '34Y70'

Semantics: Create new relation (NEW) containing tuples from EMPLOYEE where EmplId
equals 34Y70

Typical Results:

• Selecting specific employee → relation with ONE tuple

• Selecting tuples for certain department → relation with SEVERAL tuples

PROJECT Operation

Purpose: Extract columns from a relation (contrast to SELECT which extracts rows)
Example Scenario:

1. Already SELECTed tuples from JOB relation for target department → NEW1
2. Need JobTitle column from NEW1

Syntax:

NEW2 ← PROJECT JobTitle from NEW1

Result: New relation (NEW2) containing single column of JobTitle values

Another Example:

MAIL ← PROJECT Name, Address from EMPLOYEE

Result: Two-column relation (MAIL) with all employee names and addresses

JOIN Operation

Purpose: Combine different relations into one relation

Result Structure:

• Attributes: Combination of attributes from original relations

• Naming Convention: Prefixed by relation of origin
 o Example: Relation A (attributes V, W) JOIN Relation B (attributes X, Y, Z)
o Result attributes: A.V, A.W, B.X, B.Y, B.Z
• Reason: Ensures unique attribute names even if originals have common names

JOIN with Equal Condition

Syntax:

C ← JOIN A and B where A.W = B.X

Process: Concatenate tuples where designated attributes have same value

Example:

• Tuple (r, 2) from A + Tuple (2, m, q) from B → appears in result

o Reason: W value (2) = X value (2)
• Tuple (r, 2) from A + Tuple (5, g, p) from B → does NOT appear
o Reason: W value (2) ≠ X value (5)

JOIN with Comparison Condition

Syntax:

C ← JOIN A and B where A.W < B.X

Result: Tuples where attribute W in relation A is less than attribute X in relation B

Practical Application: Employee Departments

Goal: List all employee IDs with their current departments

Observation: Information distributed over multiple relations (requires more than SELECT
and PROJECT)

Solution - Step 1 (JOIN):

NEW1 ← JOIN ASSIGNMENT and JOB where [Link] = [Link]

Complete Sequence:

NEW1 ← JOIN ASSIGNMENT and JOB where [Link] = [Link]

NEW2 ← SELECT from NEW1 where [Link] = '*'
LIST ← PROJECT [Link], [Link] from NEW2

Explanation:

1. JOIN relations to combine information

2. SELECT tuples where TermDate = '*' (still employed)
3. PROJECT desired attributes (EmplId, Dept)

SQL (Structured Query Language)

Overview and Context

Database System Structure Recap:

• Database stored in mass storage system

• DBMS relieves programmer from storage details
• Application software written in terms of database model
• DBMS converts model commands into storage actions

Traditional DBMS Approach:

 • Include routines for SELECT, PROJECT, JOIN operations
• Application software calls these routines
• Can write as if database stored in simple tabular form

Modern Approach

Key Point: Modern relational DBMS don't necessarily provide raw SELECT, PROJECT,
JOIN

Instead: Provide routines combining these basic steps

SQL Role: Forms backbone of most relational database query systems

Example: MySQL ("My-S-Q-L") - used by many Internet database servers

SQL Popularity Reasons

1. Standardization

• American National Standards Institute standardized SQL

2. Industry Support

• Originally developed and marketed by IBM

• Benefited from high level of exposure

SQL Nature: Declarative vs. Imperative

Important Distinction:

• Appears: Imperative-sounding form

• Actually: Essentially declarative statement

How to Read SQL: As description of information desired (NOT sequence of activities)

Significance: SQL relieves programmers from:

• Developing algorithms for manipulating relations

• Instead: Merely describe desired information

SQL Query Structure

Three Clauses:

1. SELECT clause: Lists attributes to PROJECT

2. FROM clause: Lists relations to JOIN
3. WHERE clause: Specifies conditions for tuple selection

Note: Terminology somewhat reversed (select clause identifies PROJECT attributes)

SQL Examples

Example 1: Three-Step Query in Single SQL Statement

Previous approach (three separate operations):

NEW1 ← JOIN ASSIGNMENT and JOB where [Link] = [Link]

NEW2 ← SELECT from NEW1 where [Link] = '*'
LIST ← PROJECT [Link], [Link] from NEW2

SQL equivalent (single statement):

sql
SELECT EmplId, Dept
FROM Assignment, Job
WHERE [Link] = [Link]
AND [Link] = '*';

Example 2: PROJECT Operation

sql
SELECT Name, Address
FROM Employee;

Result: Listing of all employee names and addresses

Example 3: SELECT Operation

sql
SELECT EmplId, Name, Address, SSNum
FROM Employee
WHERE Name = 'Cheryl H. Clark';
Result: All information about Cheryl H. Clark

Example 4: SELECT + PROJECT Combination

sql
SELECT Name, Address
FROM Employee
WHERE Name = 'Cheryl H. Clark';

Result: Only name and address of Cheryl H. Clark

Example 5: JOIN + SELECT + PROJECT

sql
SELECT [Link], [Link]
FROM Employee, Assignment
WHERE [Link] = [Link];

Result: All employee names with dates of initial employment

Process:

1. JOIN Employee and Assignment relations

2. SELECT appropriate tuples (matching EmplId)
3. PROJECT Name and StartDate attributes

SQL Data Modification Statements

Beyond Queries: SQL includes statements for:

• Defining relation structure

• Creating relations
• Modifying relation contents

INSERT INTO Statement

sql
INSERT INTO Employee
VALUES ('42Z12', 'Sue A. Burt', '33 Fair St.', '444661111');
Effect: Adds tuple to Employee relation with given values

DELETE FROM Statement

sql
DELETE FROM Employee
WHERE Name = 'G. Jerry Smith';

Effect: Removes G. Jerry Smith's tuple from Employee relation

UPDATE Statement

sql
UPDATE Employee
SET Address = '1812 Napoleon Ave.'
WHERE Name = 'Joe E. Baker';

Effect: Changes Joe E. Baker's address in Employee relation

Key Takeaways
Relational Model Basics

1. Relations: Rectangular tables with tuples (rows) and attributes (columns)

2. Design Challenges: Avoiding redundancy and information loss

Design Principles

1. Separation: Divide concepts into separate relations

2. Lossless Decomposition: Ensure no information loss when dividing relations
3. Three-relation approach: Better than single extended relation

Operations

1. SELECT: Extract rows based on conditions

2. PROJECT: Extract columns
3. JOIN: Combine relations based on conditions

SQL

1. Declarative language: Describes desired information

2. Three clauses: SELECT (project), FROM (join), WHERE (select)
3. Comprehensive: Handles queries and data modification
4. Industry standard: Widely used (MySQL, etc.)