Children’s Education Society
THE OXFORD COLLEGE OF ENGINEERING, BANGALORE -560 068
(Approved by AICTE, New Delhi, Accredited by NBA, NAAC Grade A &
Affiliated to VTU, Belagavi-590 018)
Module-4
Software Engineering: The Software Engineering Discipline, The Software Life Cycle, Software
Engineering Methodologies, Modularity, Tools of the Trade.
Database Systems: Database Fundamentals, The Relational Model.
Software Engineering
1.Software Engineering Discipline
1. Introduction to Software Engineering
•
Software engineering is a branch of computer science that focuses on the development of
large, complex software systems.
•
Unlike simple programming, software engineering involves:
•
o
Long-term development
o
Multiple developers
o
Changing requirements
o
Project and personnel management
It deals with technical issues and organizational aspects.
1.1 Need for Software Engineering
•
•
Large software systems are comparable to designing complex physical structures like:
o
Automobiles
o
Office buildings
o
Cathedrals
Questions that illustrate complexity:
o
How to estimate cost, time, and resources?
o
How to divide work into manageable pieces?
o
How to ensure compatibility of components?
o
How to measure progress?
o
How to coordinate communication among team members?
1BESC104E / PREPARED BY SAKTHIDEVI
1
These are engineering concerns, thus requiring systematic and disciplined approaches.
1.2 Challenges in Software Engineering
Software engineering borrowed many techniques from traditional engineering (mechanical,
electrical), but major differences exist:
Lack of Prefabricated Components
•
Other engineering fields have standardized components.
•
Software components were traditionally domain-specific.
•
Reusability was limited historically, causing:
•
o
Long development time
o
Duplication of effort
Modern software engineering is progressing toward generic components, libraries, and
design patterns.
1.3 Measuring Software Properties – Metrics
•
In traditional engineering, metrics (e.g., strength, durability) are well established.
•
In software engineering:
•
o
Complexity is difficult to measure.
o
Software does not “wear out”.
o
Quality assessment (e.g., reliability) is challenging.
Example metric challenges:
o
Lines of code ≠ complexity
o
Error counting is tedious and subjective
Hence, software engineering lacks robust quantitative methods.
1.4 Limitations in the Field
•
Difficulty in establishing a strong scientific foundation like physics-based engineering.
•
Many methodologies created by practitioners were subjective.
•
New methods often replace older ones before proving stable or universal.
1.5 Need for Progress
•
Society is highly dependent on software systems in:
o
Economy
o
Healthcare
o
Government
1BESC104E / PREPARED BY SAKTHIDEVI
2
•
•
o
Law enforcement
o
Transportation
o
Defense
Failures have caused:
o
Space probe losses
o
Bank financial losses
o
Airplane crashes
o
Communication outages
Despite huge dependency, reliability issues persist.
1.6 CASE – Computer-Aided Software Engineering
Progress includes application of computing to the development process:
CASE Tools
CASE tools help automate and streamline activities such as:
•
Project planning systems
(cost estimation, scheduling, manpower allocation)
•
Project management systems
(monitor project progress)
•
Documentation tools
(writing and organizing documentation)
•
Prototyping/simulation tools
(building and testing prototypes)
•
Interface design systems
(creation of GUIs)
•
Programming systems
(writing and debugging code)
1.7 Integrated Development Environments (IDEs)
•
IDEs combine multiple tools into a single integrated package:
o
Editors
o
Compilers
o
Debuggers
o
Build tools
Examples:
•
IDEs for smartphone app development with simulators to preview performance on a device.
1BESC104E / PREPARED BY SAKTHIDEVI
3
1.8 Professional Organizations Supporting Software Engineering
Association for Computing Machinery (ACM)
•
Founded in 1947.
•
Promotes computing sciences, research, education, and professional ethics.
•
Offers:
•
o
Conferences
o
Journals
o
Special interest groups (SIGs)
o
Curriculum standards
o
Code of ethics
Enhances professionalism and overall quality within the field.
1.9 Summary of Software Engineering Progress
Progress is occurring on two levels:
•
Practitioners → develop methods for immediate use
•
Theoreticians → develop foundations for long-term stable solutions
Software engineering continues to evolve to improve:
•
Reliability
•
Reusability
•
Methodologies
•
Development tools
2. The Software Life Cycle
2.1. The Cycle as a Whole
1BESC104E / PREPARED BY SAKTHIDEVI
4
•
•
•
Once created, software enters a continuous cycle of:
o
Use
o
Maintenance
Maintenance in software is not physical repair, but:
o
Correcting errors
o
Updating features
o
Adapting software to new environments
Software enters the maintenance phase due to:
o
Newly discovered bugs
o
New requirements
o
Changes in hardware or system environment
2.2. The Traditional Development Phase
Traditional development includes four major steps (Figure 7.2):
1. Requirements Analysis
2. Design
3. Implementation
4. Testing
2.2.1 Requirements Analysis
Definition
The process of determining:
•
What services the system should provide
1BESC104E / PREPARED BY SAKTHIDEVI
5
•
Under what conditions it must operate
•
How the system interacts with external actors
Stakeholders
People with interests in the system, such as:
•
Future users
•
Legal departments
•
Financial officers
Requirement Process Includes
•
Studying user needs
•
Negotiating conflicting requirements
•
Balancing needs vs. feasibility
•
Producing a Software Requirements Specification (SRS)
SRS (Software Requirements Specification)
•
A formal document recording the system’s requirements
•
A guide and agreement among all parties
•
Used to settle disputes later in development
•
Supported by organizations like IEEE and U.S. DoD
2.2.2 Design
Goal
To create a blueprint for the software’s internal structure.
It Includes
•
Architecture design
•
Module decomposition
•
Interfaces and data structures
Key Idea
Requirements analysis focuses on what the system must do.
Design focuses on how to accomplish it.
However, in practice, the boundary between “what” and “how” is not always clean.
2.2.3 Implementation
It defines to implement entire software. The Activities includes,
•
Writing programs
1BESC104E / PREPARED BY SAKTHIDEVI
6
•
Creating data files
•
Building databases
•
Integrating components
It contains various roles. They are,
•
Software Analyst / System Analyst: involved in whole process
•
Programmer: traditionally only in implementation, but today these roles commonly overlap
→ Modern development blurs the distinction between analysts and programmers.
2.2.4 Testing
Traditional View
Testing defines that debugging and checking compatibility with requirements of the software.
Modern testing is more complex and includes:
•
Unit tests
•
Integration tests
•
System tests
•
Acceptance tests
Testing ensures the product meets the SRS and is defect-free.
3. Software Engineering Methodologies
In early approaches to software engineering insisted on performing
Requirement analysis , design , implementation and testing in a sequential
manner.
3.1. The Waterfall Model : It allows development process is in only one
direction.
Characteristics
•
Strict linear sequence
•
Finish one phase before starting next
•
Requirements → Design → Implementation → Testing
Drawback
•
No room for changes
•
Real-world development often requires flexibility
3.2. The Incremental Model
1BESC104E / PREPARED BY SAKTHIDEVI
7
Definition
System built and delivered in increments:
•
First version has small and limited functionality
•
Additional features added step-by-step
Example
Hospital patient records:
•
Increment 1: View records
•
Increment 2: Add and update records
•
Increment 3: Reporting features
3.3. The Iterative Model
• Extending version to larger version and refining each version iterative
manner.
Key Idea
•
Refining the system repeatedly
•
Each cycle improves or modifies previous versions
•
Often confused with incremental model, but:
Incremental defines add new functionality
Iterative defines refine existing functionality
3.4. Rational Unified Process (RUP)
•
It was Created by Rational Software Corporation (now IBM).It redefines the software
development process in each steps.
•
A highly structured iterative methodology
•
Defines stages and activities across the entire life cycle
•
Supports teams with extensive CASE tools
•
Led to the unified process, an open standard
3.5. Prototyping:
Incomplete version of the proposed software is known as prototypes.
Evolutionary Prototyping
•
Prototype gradually evolves into the final system
Throwaway Prototyping
1BESC104E / PREPARED BY SAKTHIDEVI
8
•
•
Prototype built only for:
o
Understanding requirements
o
Communication with clients
Then discarded
Rapid Prototyping
•
Very quick, simple mock-up of proposed systems.
•
Helps clarify user expectations early on stages.
3.6. Open-Source Development
•
Developer posts early version online and produced as free.
•
Community modifies or enhances it
•
Changes submitted back to the original author
•
New versions released frequently
Characteristics:
•
Highly collaborative
•
Code and documentation publicly available
•
Example: Linux
3.7. Agile Methods
Purpose
•
Respond to changing requirements
•
Emphasize flexibility
•
Quick incremental implementation
3.8. Extreme Programming (XP)
Key Features
•
Software is developed by team.
•
Daily cycles of:
•
o
Requirements
o
Design
o
Implementation
o
Testing
Developers work in pairs (pair programming)
1BESC104E / PREPARED BY SAKTHIDEVI
9
•
Constant collaboration with stakeholders
•
Adapts quickly to change
Contrast with Waterfall:
•
Waterfall defines rigid, sequential
•
XP defines flexible, iterative, stakeholder-driven
4 Modularity
Meaning of Modularity
•
Modularity is the process of dividing a software system into manageable, independent units
called modules.
•
Each module handles a specific part of the overall functionality.
•
Modularity helps in:
o
Easy understanding
o
Maintenance
o
Testing
o
Reuse
o
Future modification
Need for Modularity
•
Large software systems are complex.
•
Without modularity, understanding or modifying software becomes nearly impossible.
•
Changes in one module should not affect other modules.
Modular Implementation
Imperative Paradigm
•
Modules are functions/procedures.
•
Example (Tennis Game Simulation):
o
Serve
o
Return
o
ComputePath
o
UpdateScore
o
Controlled by ControlGame
1BESC104E / PREPARED BY SAKTHIDEVI
10
Structure Chart
•
Represents modules as rectangles
•
Arrows show dependencies and control flow
•
Example:
ControlGame
/ |
|
\
Serve Return ComputePath UpdateScore
Structure chart shows who calls whom, not how tasks are performed.
Note that the structure chart does not indicate how each function is to perform its task. Rather, it
merely identifies the functions and indicates the dependencies among the functions. In reality, the
function ControlGame might perform its task by first calling the Serve function, then repeatedly calling
on the functions ComputePath and Return until one reports a miss, and finally calling on the services
of UpdateScore before repeating the whole process by again calling on Serve.
Object-Oriented Paradigm
Objects as Modules
•
Software is organized around objects, not functions.
•
Objects combine:
o
Attributes (data)
o
Methods (operations)
1BESC104E / PREPARED BY SAKTHIDEVI
11
At this point the design for our tennis program consists of four objects:
PlayerA, PlayerB, Judge, and Score. To clarify our design, consider the sequences of events that may
occur during a volley as depicted in Figure 7.5 where we have represented the objects involved as
rectangles. The figure is intended to present the communication between these objects as the result
of calling the serve method within the object PlayerA. Events appear chronologically
as we move down the figure. As depicted by the first horizontal arrow, PlayerA reports its serve to the
object Judge by calling the method evaluateServe. The Judge then determines that the serve is good
and asks PlayerB to return it by calling PlayerB’s returnVolley method. The volley terminates when the
Judge determines that PlayerA erred and asks the object Score to record the results.
As in the case of our imperative example, our object-oriented program is very simplistic at this stage.
However, we have progressed enough to see how the object-oriented paradigm leads to a modular
design in which fundamental components are objects.
Example Objects
•
PlayerA, PlayerB
•
Judge
•
Score
Class and Objects
•
•
PlayerClass
o
Attributes: skill, endurance
o
Methods: serve(), returnVolley()
PlayerA and PlayerB are instances of PlayerClass
1BESC104E / PREPARED BY SAKTHIDEVI
12
Coupling
a goal when designing a modular system should be to maximize independence among
modules or, in other words, to minimize the linkage between modules (known as intermodule
coupling). Indeed, one metric that has been used to measure the complexity of a software
system (and thus obtain a means of estimating the expense of maintaining the software)
is to measure its intermodule coupling. Intermodule coupling occurs in several forms. One is
control coupling, which occurs when a module passes control of execution to another, as in a
function call. The structure chart in Figure 7.3 represents the control coupling that exists
between functions. In particular, the arrow from the module ControlGame
Definition
Coupling is the degree of interdependence between modules.
•
Goal: Minimize coupling
•
Less coupling → More independent modules → Better software
Types of Coupling
1. Control Coupling
•
One module passes control to another.
•
Occurs when a module calls another module.
•
Example:
o
ControlGame calls Serve, Return, etc.
Control coupling is unavoidable but should be limited.
1BESC104E / PREPARED BY SAKTHIDEVI
13
2. Data Coupling
•
Modules share data by passing parameters.
•
Example:
o
•
Serve passes trajectory data to ControlGame
Data coupling is better than control coupling.
3. Global Data Coupling
•
Modules share global variables.
•
Dangerous because:
•
o
Hard to track changes
o
Unexpected side effects
Should be avoided as much as possible.
Coupling in Object-Oriented Systems
•
Objects interact by sending messages (method calls).
•
OO design naturally reduces coupling because:
o
Data is encapsulated inside objects
o
Objects do not directly access internal data of others
Cohesion
Definition
The term cohesion refers to this internal binding or, in other words, the degree of relatedness of a
module’s internal parts. A weak form of cohesion is known as logical cohesion. A stronger form of
cohesion is known as functional cohesion, which means that all the parts of the module are focused
on the performance of a single activity.
1BESC104E / PREPARED BY SAKTHIDEVI
14
Cohesion is the degree of relatedness of elements within a module.
•
Goal: Maximize cohesion
•
High cohesion → Clear purpose → Easier maintenance
Types of Cohesion
1. Logical Cohesion (Weak)
•
Module groups logically similar operations
•
Example:
o
•
A module handling all communication tasks
Problem:
o
Activities may be unrelated internally
2. Functional Cohesion (Strong)
•
Module performs only one well-defined task
•
Best form of cohesion
•
Example:
o
ComputePath only calculates ball trajectory
Cohesion in Object-Oriented Design
•
An object may be logically cohesive
1BESC104E / PREPARED BY SAKTHIDEVI
15
•
Each method inside the object should be functionally cohesive
•
Example:
o
serve() → only serving action
o
returnVolley() → only return action
Relationship Between Coupling and Cohesion
Aspect
Good Design
Coupling
Low
Cohesion
High
✔ High cohesion does not increase coupling
✔ Both goals are compatible
Information Hiding
Definition
Information Hiding means restricting access to the internal details of a module.
information hiding, which refers to the restriction of information to a specific portion of a software
system. Here the term information should be interpreted in a broad sense, including any knowledge
about the structure and contents of a program
unit.
•
Modules expose what they do, not how they do it
•
Internal data should not be accessed directly by other modules
Why Information Hiding?
•
Prevents accidental data corruption
•
Reduces dependencies
•
Improves security and maintainability
Examples
•
Private variables in a class
•
Local variables inside functions
•
Encapsulation in OOP
Two Views of Information Hiding
1BESC104E / PREPARED BY SAKTHIDEVI
16
Information hiding has two incarnations—one as a design goal, the other as an implementation goal.
A module should be designed so that other modules do not need access to its internal information,
and a module should be implemented in a manner that reinforces its boundaries. Examples of
the former are maximizing cohesion and minimizing coupling. Examples of the latter involve the use
of local variables, applying encapsulation, and using well-defined control structures.
1. Design Goal
o
Other modules do not depend on internal details
2. Implementation Goal
o
Enforce boundaries using access control
Information hiding supports:
•
Encapsulation
•
Abstraction
•
Modularity
Components
an object is actually a special case of the more general concept of a component, which is, by definition,
a reusable unit of software. 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.
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) in which the
traditional role of a programmer is replaced by a component assembler who constructs software
systems from prefabricated components that, in many development environments, are displayed as
icons in a graphical interface. Rather than be involved with the internal programming of the
components, the methodology of a component assembler is to select pertinent components from
collections of predefined components and then connect them, with minimal customization, to obtain
the desired functionality. Indeed, a property of a well-designed component is that it can be extended
to encompass features of a particular application without internal modifications.
Definition
•
A component is a reusable, self-contained software unit.
•
Built from one or more objects
•
It has:
o
Well-defined interface
o
Specific functionality
Component-Based Software Engineering (CBSE)
•
Software is built by assembling prefabricated components
•
Example:
1BESC104E / PREPARED BY SAKTHIDEVI
17
o
UI components
o
Service components
o
Database components
Real-World Example (Smartphones)
•
Contacts app
•
Phone app
•
Facebook app
•
Calendar app
Apps share components to reduce resource usage and improve integration.
Software Engineering in the Real World
Problem Scenario
•
Employees create small custom programs
•
Over time:
o
Programs become undocumented
o
Hard to maintain
o
Integrated poorly
Result
•
System becomes:
o
Error-prone
o
Difficult to modify
o
Poorly designed
Solution
•
Proper modular design
•
High cohesion
•
Low coupling
•
Use of components
Good software design is achieved by high cohesion, low coupling, effective information hiding, and
component-based modularity.
Tools of the Trade
1BESC104E / PREPARED BY SAKTHIDEVI
18
1. Introduction to Software Engineering Tools
Software engineering uses various models and diagrams to:
•
Understand user requirements
•
Analyze system behavior
•
Design system structure
•
Communicate ideas clearly among stakeholders
2. Dataflow Diagrams (DFDs)
2.1 Concept of Dataflow Analysis
•
Focuses on how data moves through a system
•
Identifies:
o
Where data enters the system
o
How it is processed
o
Where it is stored
o
How results are produced
2.2 Components of a Dataflow Diagram
Symbol
Meaning
Arrows
Data flow
Ovals
Processes (data manipulation)
Rectangles
External entities
Open rectangles
Data stores
2.3 Example: Hospital Billing System (Figure 7.8)
A dataflow diagram is a means of representing the information gained from such dataflow studies. In
a dataflow diagram, arrows represent data paths, ovals represent points at which data manipulation
occurs, and rectangles represent data sources and stores. As an example, Figure 7.8 displays an
elementary dataflow diagram representing a hospital’s patient billing system. Note that the diagram
shows that Payments (flowing from patients) and PatientRecords (flowing from the hospital’s files)
merge at the oval ProcessPayments from which UpdatedRecords flow back to the hospital’s files.
1BESC104E / PREPARED BY SAKTHIDEVI
19
Entities & Processes
•
Patient sends payments
•
Process Payments updates Hospital Files
•
Process Bills generates bills
•
Updated records flow back to hospital files
Advantages of DFDs
•
Easy to understand
•
Helps identify system functions
•
Useful during requirements analysis
Limitations
•
Does not show control flow
•
Less suitable for object-oriented systems
3. Data Dictionary
3.1 Definition
Data dictionary, which is a central repository of information about the data items
appearing throughout a software system.
A data dictionary is a centralized repository containing:
•
Data item names
•
Data types
•
Possible values
•
Storage locations
•
Modules using the data
3.2 Purpose
1BESC104E / PREPARED BY SAKTHIDEVI
20
•
Improves communication between:
o
Clients
o
Software engineers
•
Avoids ambiguity
•
Ensures consistency across the system
3.3 Benefits
•
Early detection of inconsistencies
•
Eliminates redundancy
•
Helps during maintenance
4. Unified Modelling Language (UML)
4.1 Introduction
UML is a standard modelling language used to visualize, specify, construct, and document software
systems.
UML is:
•
Object-oriented
•
Graphical
•
Platform-independent
5. Use Case Diagram
5.1 Purpose
•
It is used to Captures functional requirements
•
It is used to Show system behavior from the user’s perspective
5.2 Components
•
Actors: Users or external systems
•
Use Cases: System functionalities
•
System Boundary: Defines system scope
5.3 Example: Hospital Records System (Figure 7.9)
A use case diagram depicts the proposed system as a large rectangle in which interactions
(called use cases) between the system and its users are represented as ovals and users of the
system (called actors) are represented as stick figures (even though an actor may not be a
person). Thus, the diagram in Figure 7.9 indicates that the proposed Hospital Records System
will be used by both Physicians and Nurses to Retrieve Medical Records. Whereas use case
diagrams view a proposed software system from the outside, UML offers a variety of tools for
1BESC104E / PREPARED BY SAKTHIDEVI
21
representing the internal object-oriented design of a system. One of these is the class diagram,
which is a notational system for representing the structure of classes and relationships
between classes (called associations in UML vernacular). As an example, consider the
relationships between physicians, patients, and hospital rooms. We assume that objects
representing these entities are constructed from the classes Physician, Patient, and Room,
respectively.
Actors
•
Physician
•
Nurse
•
Administrator
•
Laboratory Technician
Use Cases
•
Retrieve Medical Records
•
Update Medical Records
•
Retrieve Laboratory Results
•
Update Laboratory Results
•
Retrieve Financial Records
•
Update Financial Records
1BESC104E / PREPARED BY SAKTHIDEVI
22
Key Points
•
One actor can interact with multiple use cases
•
One use case can be accessed by multiple actors
6. Class Diagrams
6.1 Definition
A class diagram represents:
•
Classes
•
Attributes
•
Methods
•
Relationships among classes
6.2 Associations
Associations represent relationships between classes.
Figure 7.10 shows how the relationships among these classes could be represented in a UML class
diagram. Classes are represented by rectangles and associations are represented by lines. Association
lines may or may not be labelled. If they are labelled, a bold arrowhead can be used to indicate the
direction in which the label should be read. For example, in Figure 7.10 the arrowhead following
the label cares for indicates that a physician cares for a patient rather than a patient cares for a
physician. Sometimes association lines are given two labels to provide terminology for reading the
association in either direction. This is exemplified in Figure 7.10 in the association between the classes
Patient and Room.
Example: Physician – Patient – Room (Figure 7.10)
Relationship
Meaning
Physician cares for patient
One physician → many patients
Patient occupies Room
One patient → one room
1BESC104E / PREPARED BY SAKTHIDEVI
23
Relationship
Meaning
Room hosts Patient
One room → one patient
6.3 Association Multiplicity
Type
Example
One-to-One
Patient ↔ Room
One-to-Many
Physician → Patients
Many-to-Many
Physician ↔ Patient (consultants)
(Figure 7.11 illustrates these relationships clearly)
Figure 7.11. A one-to-one relationship is exemplified by the association between patients and
occupied private rooms in that each patient is associated with only one room and each room is
associated with only one patient. A one-to-many relationship is exemplified by the association
between physicians and patients in that one physician is associated with many patients and each
patient is associated with one (primary) physician. A many-to-many relationship would occur if we
included consulting physicians in the physician–patient relationship. Then each physician could be
associated with many patients and each patient could be associated with many physicians.
7. Generalization (Inheritance) in UML
7.1 Concept
Generalization represents “is-a” relationships
•
One class is a specialized version of another
1BESC104E / PREPARED BY SAKTHIDEVI
24
7.2 Example: Medical Records System (Figure 7.12)
An example is given in Figure 7.12, which depicts the generalizations among the classes
MedicalRecord, SurgicalRecord, and OfficeVisitRecord. There the associations between the classes are
represented by arrows with hollow arrowheads, which is the UML notation for associations
that are generalizations. Note that each class is represented by a rectangle containing the name,
attributes, and methods of the class in the format introduced in Figure 7.4. This is UML’s way of
representing the internal characteristics of a class in a class diagram. The information portrayed in
Figure 7.12 is that the class MedicalRecord is a generalization of the class SurgicalRecord as well as a
generalization of OfficeVisitRecord. That is, the classes SurgicalRecord and OfficeVisitRecord
contain all the features of the class MedicalRecord plus those features explicitly listed inside their
appropriate rectangles. Thus, both the SurgicalRecord and the OfficeVisitRecord classes contain
patient, doctor, and date of record, but the SurgicalRecord class also contains surgical procedure,
hospital, discharge date, and the ability to discharge a patient, whereas the OfficeVisitRecord class
contains symptoms and diagnosis
Superclass: MedicalRecord
Attributes
•
dateOfRecord
•
patient
•
doctor
Method
•
printRecord()
1BESC104E / PREPARED BY SAKTHIDEVI
25
Subclasses:
SurgicalRecord
•
surgicalProcedure
•
hospital
•
dateOfDischarge
•
dischargePatient()
•
printRecord()
OfficeVisitRecord
•
symptoms
•
diagnosis
•
printRecord()
7.3 Key Observations
•
Subclasses inherit features of superclass
•
Subclasses override methods (polymorphism)
•
Inheritance introduces tight coupling
7.4 Design Caution
Inheritance should be used only when generalization is stable
•
Excessive inheritance reduces flexibility
•
Changes in base class affect all subclasses
8. Interaction Diagrams
8.1 Purpose
•
Show dynamic behavior
•
Describe message exchange over time
9. Sequence Diagrams
9.1 Components
•
Objects (rectangles)
•
Lifelines (vertical dashed lines)
•
Messages (horizontal arrows)
•
Return messages
9.2 Example: Generic Volley Sequence (Figure 7.13)
1BESC104E / PREPARED BY SAKTHIDEVI
26
Objects
•
PlayerClass (self)
•
PlayerClass
•
Judge
•
Score
9.3 Interaction Fragments
•
loop: Repeats while condition is true
•
alt: Alternative paths based on condition
Example:
•
If validPlay = true → continue volley
•
If fromServer = false → return volley
9.4 Advantages
•
Captures complex interactions
•
Helps in validating system logic
•
Useful for design walkthroughs
10. CRC Cards (Class–Responsibility–Collaboration)
10.1 Definition
1BESC104E / PREPARED BY SAKTHIDEVI
27
CRC cards are simple index cards describing:
•
Class name
•
Responsibilities
•
Collaborating classes
10.2 Usage
•
Role-playing system behavior
•
Design validation
•
Structured walkthroughs
11. Design Patterns
11.1 Concept
Design patterns are:
•
Proven solutions to recurring design problems
•
Reusable
•
Language-independent
11.2 Benefits
•
Reduce development time
•
Improve flexibility
•
Encourage best practices
Example:
•
Decorator Pattern
•
Factory Pattern
Key Design Principles
•
Minimize coupling
•
Maximize cohesion
•
Promote flexibility
•
Ensure maintainability
Summary
1BESC104E / PREPARED BY SAKTHIDEVI
28
Tool
Purpose
Dataflow Diagram
Data movement
Data Dictionary
Data consistency
Use Case Diagram
Functional requirements
Class Diagram
System structure
Sequence Diagram
System behavior
CRC Cards
Design validation
Design Patterns
Reusable solutions
Database Systems and Fundamentals
Database Fundamentals
•
The term database refers to a collection of data that is multidimensional. This means that
internal links between the data entries make the information accessible from several
perspectives.
•
A database contrasts with a traditional file system (or a flat file), which is a one-dimensional
storage system.
•
A flat file presents information from only a single point of view (e.g., listing compositions
only by composer), whereas a database might present the compositions by a single
composer, all works by a single artist, or works by composers who wrote variations of
another composer's piece.
The Significance of Database Systems
•
Historical Context: Historically, different computing applications (like payroll, personnel, and
inventory) were implemented as separate systems, each maintaining its own data collection.
•
This separate system approach often resulted in duplicated information being stored across
different departments within the organization.
•
Centralization: Database systems emerged as a way to integrate the information, storing and
maintaining it centrally for the entire organization.
•
Benefits of Database Systems: Centralized systems significantly reduce the redundancy of
information and allow the stored data to be used for multiple purposes. Examples of benefits
include:
o
Reducing product restocking orders.
o
Creating management reports.
o
Directing advertisements.
1BESC104E / PREPARED BY SAKTHIDEVI
29
o
Providing timely public announcements to customers.
o
Ensuring the sales force has accurate, supporting information.
•
Value for Management: Integrated pools of information are a valuable resource for
management decisions, which depend on the data being accessible and comprehensible.
•
Role in Technology: Database technology, often combined with data mining techniques, is
crucial for allowing an organization to extract pertinent information from the massive
amounts of data it covers.
•
Database systems are the underlying technology that provides the interface for many
popular sites on the World Wide Web, such as Google, eBay, and Amazon.
I. Database Foundations and Structure
A. Database vs. File-Oriented Systems (Figure 9.1)
1. File-oriented system: In this structure, various departments (e.g., Customer service, Payroll,
Personnel) access and maintain their own separate sets of records (e.g., Customer records,
Payroll records, Employee records).
2. Database-oriented system: This structure features a central Integrated database.
Management and various departments (Customer service, Payroll, Personnel, Marketing,
Purchasing) all interact with this single integrated source.
B. The Conceptual Layers of Database Implementation (Figure 9.2)
1BESC104E / PREPARED BY SAKTHIDEVI
30
1. A typical database application involves multiple software layers.
2. The implementation flows conceptually from the User through Application software to the
Database management system (DBMS), and finally to the Actual database.
3. The application software handles the communication with the user, but the actual
manipulation of the database is done by the DBMS.
4. The DBMS accepts commands in terms of the database model and converts them into
actions relative to the actual storage structure.
C. Schemas and Subschemas
1. A schema is a comprehensive description of the entire database structure, utilized by the
database software.
2. A subschema is a description of only the portion of the database that is relevant to a
particular user's needs.
3. The use of subschemas allows the DBMS to enforce restrictions, controlling who can access
certain data, even within a distributed database environment.
D. Data Independence
•
Definition: Data independence is the ability to change the organization of a database itself
without having to change the application software.
•
The Problem of Direct Manipulation: If application software dealt directly with the database,
a simple change (like adding a "health insurance" field to an employee record) would require
modifying and reprogramming every application that uses that data.
•
The Role of the DBMS: By separating the application software from the Database
Management System (DBMS), only the overall schema and specific subschemas need to be
updated. The application software remains unaltered.
III. Database Models
•
Definition: A database model is a conceptual view of the database that allows users to
imagine information is arranged in a useful format, hiding the complex internal storage
structures.
1BESC104E / PREPARED BY SAKTHIDEVI
31
•
Relational Database Model:
o
The conceptual view consists of a collection of tables made of rows and columns.
o
Example: Employee info is viewed as a table where each row is an employee and
columns are attributes like Name and ID.
•
Abstraction Tools: The DBMS provides "routines" (prewritten subroutines) that allow
programs written in general-purpose languages to manipulate the database as if it matches
the conceptual model.
•
Other Models: While the relational model is common, other types like the object-oriented
database model also exist.
2. Database Management Architecture
To maintain efficiency and security, databases use a layered architecture that separates
application logic from the physical data.
The Three-Level Architecture
1. Application Layer: The software users interact with to request information.
2. Database Management System (DBMS): The engine that handles the data,
interpreting requests from applications and performing searches or updates.
3. Physical Storage: The actual bits and bytes stored on hardware.
Schemas and Subschemas
•
Schema: A description of the entire database structure.
•
Subschema: A partial view of the database tailored to a specific user's needs,
enhancing security by hiding sensitive data from unauthorized personnel.
3. Data Independence
•
Definition: The ability to change the internal organization of a database without
requiring changes to the application software.
1BESC104E / PREPARED BY SAKTHIDEVI
32
•
Importance: If application software dealt directly with data storage, every minor
structural change (like adding a new "benefits" field) would require rewriting and
recompiling every program in the system.
•
Role of the DBMS: The DBMS acts as a buffer; it maps the application's conceptual
requests to the actual physical storage, allowing either to change independently.
4. The Relational Model
The Relational Model Basics (Figure 9.3, Figure 9.5)
1. The relational model portrays data stored in rectangular tables, known as relations.
2. A row in a relation is called a tuple.
3. A column in a relation is referred to as an attribute.
4. Relation Decomposition (Figure 9.7): Dividing a single relation into smaller relations is
common, but it must be managed carefully to avoid losing information.
o
A lossless decomposition ensures no information is lost when splitting a relation.
o
A nonlossless decomposition results in the loss of information.
5. Figure 9.5 shows an employee database decomposed into three relations: EMPLOYEE (basic
employee info), JOB (job details), and ASSIGNMENT (employee job history including start
and termination dates).
Key Issues in the Relation Design
•
Redundancy and Inefficiency: The core problem discussed is that extending the relation to
include employee attributes (name, address, Social Security number, or SSN) results in
redundancy and inefficiency. This is diagnosed as combining more than one concept into a
single relation.
•
Duplication of Employee Data: If an employee holds several jobs, all of their personal
information—name, address, and SSN—must be repeated across the several tuples that
represent each job assignment.
o
Example: Joe E. Baker's personal data (33 Nowhere St., SSN 111223333) is repeated
for both his job assignments (Emp Ids 25X15 and 25X70), which correspond to Job
Ids F5 and F7.
1BESC104E / PREPARED BY SAKTHIDEVI
33
•
Duplication of Job Data: Information describing a particular job (including the job title, skill
code, and associated department) is also duplicated if that position is held by numerous
employees.
o
Example: The description for "floor manager" is duplicated in Figure 9.4 because
multiple employees (e.g., Joe E. Baker and Cheryl H. Clark) hold that position.
Functional Problems (Anomalies)
•
Deletion Problem (Loss of Data): Deleting a tuple may cause the complete loss of a fact if
that fact is only recorded in the tuple being deleted.
o
•
Example: If Joe E. Baker is the only employee holding job identified as D7, deleting
his tuple would cause the loss of the information regarding job D7, such as the fact
that job D7 requires skill level K2.
Design Flaws Indicated: The possibility of using partial tuples or retaining information (like
the fact about job F5) in a partial tuple suggests that the current design of the database can
be improved.
The relation shown in Figure 9.4 includes combined information dealing with employees (name,
identification number, address, SSN) and information about the jobs available in the company (job
identification, job title, department, skill code).
1BESC104E / PREPARED BY SAKTHIDEVI
34
A database consisting of these three relations contains the pertinent information about employees in
the EMPLOYEE relation, about available jobs in the JOB relation, and about job history in the
ASSIGNMENT relation. Additional information is implicitly available by combining the information from
different relations.For instance, if we know an employee’s identification number, we can
1BESC104E / PREPARED BY SAKTHIDEVI
35
find the departments in which that employee has worked by first finding all the jobs that employee
has held using the ASSIGNMENT relation and then finding the departments associated with those jobs
by means of the JOB relation (Figure 9.6). Through processes such as these, any information that could
be obtained from the single large relation can be obtained from the three smaller relations without
the problems previously cited. Unfortunately, dividing information into various relations is not always
as trouble-free as in the preceding example. For instance, compare the original relation.
in Figure 9.7, with attributes EmplId, JobTitle, and Dept, to the proposed decomposition into two
relations. At first glance, the two-relation system might appear to contain the same information as the
single-relation system, but, in fact, it does not. Consider for example the problem of finding the
department in which a given employee works. This is easily done in the single-relation system
by interrogating the tuple containing the employee identification number of the target employee and
extracting the corresponding department. However, in the two-relation system, the desired
information is not necessarily available. We can find the job title of the target employee and a
department having such a job but this does not necessarily mean that the target employee works in
that particular department, because several departments might have jobs with the same title.
We see, then, that sometimes dividing a relation into smaller relations causes the loss of information,
and sometimes it does not. (The latter is called a lossless decomposition—or sometimes a nonloss
decomposition.) Such relational characteristics are important design considerations. The goal is to
identify the relational characteristics that can lead to problems in database design and find ways to
reorganize those relations to remove these problematic characteristics.
Decomposition and Operations
•
Decomposition: The process of breaking a large, redundant table into smaller,
specialized tables to improve data integrity.
•
Lossless (Nonloss) Decomposition: A division that allows the original table to be
perfectly reconstructed without losing any information.
•
Relational Operations: * SELECT: Extracts specific rows (tuples) based on a condition.
o
PROJECT: Extracts specific columns (attributes) from a table.
1BESC104E / PREPARED BY SAKTHIDEVI
36
o
JOIN: Combines two tables based on a common attribute.
Advanced Database Topics
•
•
Distributed Databases: Systems where data is stored across different physical
locations but appears as a single unit to the user.
o
Fragmentation: Distributing parts of the data to different sites.
o
Replication: Storing copies of data in multiple places for speed and backup.
Data Mining: The use of algorithms to discover hidden patterns and relationships
within massive datasets for business or research purposes.
II. Core Relational Operations
Relational operations allow data to be extracted from a database by manipulating relations. The
DBMS performs routines to execute these basic operations.
A. The SELECT Operation (Figure 9.8)
1. The SELECT operation is used to retrieve certain tuples (rows) that possess specific
characteristics.
2. It extracts rows from a relation, based on a where condition.
3. The outcome is a new relation consisting of only the selected tuples from the parent relation.
4. Example Syntax: NEW ← SELECT from EMPLOYEE where EmpIid = '34Y70'.
Figure 9.8 shows the result of this operation, creating a new relation (NEW relation) containing only
the tuple for employee '34Y70'.
1BESC104E / PREPARED BY SAKTHIDEVI
37
B. The PROJECT Operation (Figure 9.9)
1. The PROJECT operation extracts columns (attributes) from a relation.
2. It is used when we need a list of attribute values, such as job titles in a specific department.
3. Example Syntax: MAIL ← PROJECT Name, Address from EMPLOYEE. Figure 9.9 illustrates this,
resulting in the MAIL relation containing only the Name and Address columns.
C. The JOIN Operation (Figures 9.10, 9.11)
1BESC104E / PREPARED BY SAKTHIDEVI
38
1. The JOIN operation combines different relations into one new relation.
2. The attributes of the resulting relation are the combined attributes of the original relations.
To maintain uniqueness, attributes in the new relation are often prefixed by the relation of
origin (e.g., A.V, B.X).
3. The tuples of the new relation are created by concatenating tuples from the two original
relations based on a specific condition.
o
Equality Join (Figure 9.10): The condition C ← JOIN A and B where A.W = B.X
concatenates tuples from Relation A and Relation B only when the value of attribute
W in A equals the value of attribute X in B.
o
Inequality Join (Figure 9.11): The condition C ← JOIN A and B where A.W < B.X
concatenates tuples when the value of attribute W in A is less than the value of
attribute X in B.
4. Application Example (Figure 9.12): Figure 9.12 demonstrates joining the ASSIGNMENT and
JOB relations based on their shared JobId attribute (ASSIGNMENT.JobId = JOB.JobId) to
create the NEW1 relation, linking employee assignment records with specific job details.
1BESC104E / PREPARED BY SAKTHIDEVI
39
Structured Query Language (SQL)
A. Overview
1. SQL (Structured Query Language) is the language that underlies most relational database
management systems.
2. SQL queries are essentially declarative; they describe the desired information rather than
specifying the steps required to obtain it, simplifying development for application
programmers.
B. Basic SQL Query Structure
1. Most SQL statements contain three main clauses:
o
SELECT: Identifies the attributes to be listed in the result (analogous to the PROJECT
operation).
o
FROM: Specifies the relations involved, implicitly requesting a JOIN of the relations
listed.
o
WHERE: Specifies the conditions that tuples must satisfy (analogous to the SELECT
operation).
2. SQL Examples:
o
Projection: SELECT Name, Address from Employee produces a list of names and
addresses (a PROJECT operation).
1BESC104E / PREPARED BY SAKTHIDEVI
40
o
Selection: SELECT EmpId, Name, Address, SSNum From Employee WHERE Name =
'Cheryl H. Clark' produces all information for the tuple associated with Cheryl H.
Clark (a SELECT operation).
o
Complex Query (JOIN, SELECT, PROJECT): A query to retrieve employee IDs and their
corresponding departments from three relations (ASSIGNMENT, JOB, EMPLOYEE)
uses SELECT, FROM, and WHERE clauses to join the tables and filter the data.
C. SQL Data Manipulation Statements
SQL also encompasses statements for modifying the structure and content of relations:
1. INSERT: Adds a new tuple to a relation.
o
Example: INSERT INTO Employee VALUES ('42Z12', 'Sue A. Burt', ...).
2. DELETE: Removes a tuple from a relation.
o
Example: DELETE FROM Employee WHERE Name = 'G. Jerry Smith'.
3. UPDATE: Changes the attribute values within an existing tuple.
o
Example: UPDATE Employee SET Address = '1812 Napoleon Ave.' WHERE Name =
'Joe E. Baker'.
1BESC104E / PREPARED BY SAKTHIDEVI
41