Transcript Operations on relations

Chapter 7
Software Engineering
Objectives
• Understand the software life cycle.
• Describe the development process models.
• Understand the concept of modularity in
software engineering.
• Understand the importance of quality in
software engineering.
• Understand the role of documentation in
software engineering.
System life cycle
• Software, like many
other products, goes
through a cycle of
repeating phases.
System development phases
• The development process in the software
life cycle involves 4 phases.
Analysis
•
•
•
•
Define the user (generic or specific?)
Define the needs (expectations)
Define the requirements
Define the methods (to meet requirements)
Design phase
• The design phase defines how the system
will accomplish what was defined in the
analysis phase.
• Modularity
• Tools
– Structure chart
– UML
Implementation phase
• Tools
– Flow chart
– Pseudocode
• Coding
Testing phase
• Black box tesing
– Black box test plans are developed by looking
only at the requirements statement.
• White box testing
– White box testing is the responsibility of the
programmer, who knows exactly what is going
on inside the program.
Development process models
• Waterfall model: a sequential software
development process, in which progress is seen
as flowing steadily downwards (like a waterfall)
through the phases of Conception, Initiation,
Analysis, Design, Construction, Testing and
Maintenance.
Development process models
• In the incremental model, the process is developed
in a series of steps.
• First complete a simplified version of the whole
package.
• Gradually add more details.
Modularity
• Modularity means breaking a large project
into smaller parts that can be understood
and handled easily.
• Tools
– Structure chart
– Class diagram
– Unified Modeling Language (UML)
Modularity - coupling
• Coupling is a measure of how tightly two
modules are bound to each other.
• Loose coupling is more desirable, because:
– Independent functions are more resuable
– Less likely to cause problems
– Maintenance modifications are easier
Modularity - coupling
• Data coupling: passes only the minimum required data
from the calling function to the called function. Most
desirable.
• Stamp coupling: when the parameters are composite
objects such as arrays.
• Control coupling: passes flags to direct the control flow of
a function.
• Global coupling: uses global variables. Should never be
used.
• Content coupling: when one function refers directly to the
data or statements in another function.
Modularity - cohesion
• Cohesion is a measure of how closely the
processes in a program are related.
• Function cohesion: A module with function
cohesion contain only one process. For example,
in printing a report, the report function should call
3 lower level functions: one to get the data, one to
format and print the report header, and one to
format and print the data.
– Only one thing
– In one place
Modularity - cohesion
• Sequential cohesion: A module with sequential
cohesion contains two or more related tasks that
are closely tied together, usually with the output of
one flowing as input to the other.
• Example: the calculations for a sale:
–
–
–
–
Extend item prices
Sum items
Calculate sales tax
Calculate total
Modularity - cohesion
• Communicational cohesion: It combines processes
that work on the same data.
• Example: a function that reads an inventory file,
prints the current status of the parts, and then
checks to see if any parts need to be ordered.
• The first 3 levels of cohesion are all considered
good structured programming principles.
• Beyond this point, ease of understanding and
implementation, maintanability, and accuracy
begin to drop rapidly.
Modularity - cohesion
• The 4th level, procedural cohesion, combines
unrelated processes that are linked by a control
flow.
• The 5th level, temporal cohesion, combines
unrelated processes that always occur together.
• The last 2 levels are seldom found in programs
today. Logical cohesion combines processes that
are related only by the entity that controls them.
Coincidental cohesion combines processes that are
unrelated.
Quality defined
• Quality software is defined as:
– Software that satisfies the users’ explicit and implicit
requirements, is well documented, meets the operating
standards of the organization, and runs efficiently on
the hardware for which it was developed.
• If you want to attain it, you have to be able to
measure it.
• Whenever possible, these measurements hould be
quantitative. For example: # of errors per thousand
lines of code, the mean time between failures for
software systems.
Quality factors
Operability
• Accuracy can be measured by such metrics as
mean time between failures, number of bugs per
thousand lines of code, and number of user request
for change.
• Efficiency is, by and large, a subjective term. In
some cases, the user will specify a performance
standard, such as a real-time response that must be
received within 1 second 95 percent of the time.
• Reliability is really the sum of the other factors.
Operability
• Security: How secure a system is refers to how
easy it is for unauthorized persons to get at the
system’s data.
• Timelyness: Can mean different things, such as
“Does the system deliver its output in a timely
fashion?” or “Does the response time satisfy the
users’ requirements?”.
• Usability: Highly subjective. The best measure is
to watch the users and see how they are using the
system.
Maintainability
• Maintainability refers to keeping a system running
correctly and up to date.
• Changeability: how easy is it to change a system?
• Correctability: one measure of correctability is
mean time to recovery, which is the time it takes
to get a program back in operation after it fails.
• Flexibility: is a qualitative attribute that attempts
to measure how easy it is to make these changes.
• Testability: how easy is it to test the system? Are
complex structures employed in the code? Does
the detailed design contain clear pseudo-code?
Transferability
• Transferability refers to the ability to move data
and/or a system from one platform to another and
to reuse code.
• Code reusability: is the likelihood a segment of
structured code can be used again to add new
functionalities with slight or no modification.
• Interoperability: is the ability of sending data to
other systems.
• Portability: is the ability to move software from
one hardware platform to another.
The quality circle
The quality circle
• There are 6 steps to quality software: quality tools,
techincal reviews, formal testing, change controls,
standards, and measurement and reporting.
• Software engineers need quality tools to develop a
quality product.
• Technical review should be conducted at every
step in the development process, including
requirements, design, programming, and testing.
The quality circle
• Formal testing ensures that the programs work
together as a system and meet the defined
requirements.
• To ensure quality, each change should be
reviewed and approved by a change control board.
• A good quality environment measures all aspects
of quality and regularly reports the results.
• At the same time, published standards provide the
yardstick for many quality measurements.
Documentation
• User documentation: traditionally called a
manual, user documentation shows how to
use the package step by step.
– A good user manual can be a very powerful
marketing tool.
• System documentaion defines the package
itself.
System documentation
• Documentation in the analysis phase.
– Info collected should be carefully documented.
– Analyst should define the source of info.
– Requirements and methods chosen must be
clearly stated with the rationale behind them.
System documentation
• Documentation in the design phase.
– Tools used in the final copy must be
documented.
– For example, if a structural chart undergoes
several changes, the final copy should be
documented with complete explanations.
System documentation
• Documentation in the implementation phase.
– Every tool and every program should be
documented.
– The program should be self-documented.
– Two levels of program documentation:
• General documentation: each program should start
with a general description of the program, then the
name of the author and the date, then change history.
• Function documentation: whenever necessary, brief
comment for blocks of code should be added.
System documentation
• Documentation in the testing phase.
– Each type of test applied to the final product
should be mentioned along with the result.
– Even unfavorable results and the data that
produced them must be documented.
• Documentation as an ongoing process.
– If the package has problems after release,…
– If the package is modified, …
– Documentation stops when the package
becomes obsolete.
Objectives
• Understand the software life cycle.
• Describe the development process models..
• Understand the concept of modularity in
software engineering.
• Understand the importance of quality in
software engineering.
• Understand the role of documentation in
software engineering.
Data Structures
Objectives
• Understand arrays and their usefulness.
• Understand records and the difference
between an array and a record.
• Understand the concept of a linked list and
the difference between an array and a linked
list.
• Understand when to use an array and when
to use a linked-list.
Arrays - definition
• An array is a fixed-sized, sequenced
collection of elements of the same data
type.
Arrays – memory layout
Records - definition
• A record is a collection of related elements,
possibly of different types, having a single
name.
• Each element in a record is called a field.
• A field is the smallest element of named
data that has meaning.
• The difference between an array and a
record?
Records - examples
Linked list
• A linked list is an ordered collection of data
in which each element contains the location
of the next element; that is, each element
contains two parts: data and link.
Inserting a node
Deleting a node
Traversing a list
Other data structure topics
•
•
•
•
•
Stacks (page 233)
Queues (page 235)
Trees (page 237)
Binary trees (page 239)
Graphs (page 244)
Objectives
• Understand arrays and their usefulness.
• Understand records and the difference
between an array and a record.
• Understand the concept of a linked list and
the difference between an array and a linked
list.
• Understand when to use an array and when
to use a linked-list.
Databases
Objectives
• Understand a DBMS and define its components.
• Understand the architecture of a DBMS and its
levels.
• Distinguish between different database models.
• Understand the concept of relational database
operations on a relation.
• Use Structured Query Language (SQL) to define
simple relations.
Databases and DBMS
• A database is a collection of data that is
logically, but not necessarily physically,
coherent.
• A database management system defines,
creates, and maintains a database.
• It also allows users controlled access to data
in the database.
DBMS components
Database architecture
DB models - hierarchical
DB models – network
DB model - relational
Relation
• A relation, in appearance, is a twodementional table.
SQL
• The structured query language is the
standardized language we use to operate on
relational databases.
• It is a declarative (not procedural) language,
which means that the users declare what
they want without having to write a step-bystep procedure.
Operations on relations - insert
insert into COURSES
values (“CIS52”, “TCP/IP Protocols”, 6)
Operations on relations - delete
delete from COURSES
where No=“CIS19”
Operations on relations - update
update COURSES
set Unit = 6
where No = “CIS51”
Operations on relations - select
select *
from COURSES
where Unit = 5
Operations on relations - project
select No, Unit
from COURSES
Operations on relations - join
select No, Course-Name, Unit, Professor
from COURSES, TAUGHT-BY
where COURSES.No = TAUGHT-BY.No
Operations on relations - union
select *
from CIS15-Roster
union
select *
from CIS52-Roster
Operations on relations intersection
select * from CIS15-Roster
intersection
select * from CIS52-Roster
Operations on relations difference
select * from CIS15-Roster
minus
select * from CIS52-Roster
Objectives
• Understand a DBMS and define its components.
• Understand the architecture of a DBMS and its
levels.
• Distinguish between different database models.
• Understand the concept of relational database
operations on a relation.
• Use Structured Query Language (SQL) to define
simple relations.