Title: Chapter 7 Software Engineering
1Chapter 7 Software Engineering
2Objectives
- 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.
3System life cycle
- Software, like many other products, goes through
a cycle of repeating phases.
4System development phases
- The development process in the software life
cycle involves 4 phases.
5Analysis
- Define the user (generic or specific?)
- Define the needs (expectations)
- Define the requirements
- Define the methods (to meet requirements)
6Design phase
- The design phase defines how the system will
accomplish what was defined in the analysis
phase. - Modularity
- Tools
- Structure chart
- UML
7Implementation phase
- Tools
- Flow chart
- Pseudocode
- Coding
8Testing 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.
9Development 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.
10Development 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.
11Modularity
- 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)
12Modularity - 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
13Modularity - 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.
14Modularity - 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
15Modularity - 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
16Modularity - 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.
17Modularity - 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.
18Quality 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.
19Quality factors
20Operability
- 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.
21Operability
- Security How secure a system is refers to how
easy it is for unauthorized persons to get at the
systems 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.
22Maintainability
- 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?
23Transferability
- 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.
24The quality circle
25The 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.
26The 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.
27Documentation
- 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.
28System 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.
29System 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.
30System 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.
31System 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.
32Objectives
- 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.
33Data Structures
34Objectives
- 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.
35Arrays - definition
- An array is a fixed-sized, sequenced collection
of elements of the same data type.
36Arrays memory layout
37Records - 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?
38Records - examples
39Linked 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.
40Inserting a node
41Deleting a node
42Traversing a list
43Other data structure topics
- Stacks (page 233)
- Queues (page 235)
- Trees (page 237)
- Binary trees (page 239)
- Graphs (page 244)
44Objectives
- 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.
45Databases
46Objectives
- 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.
47Databases 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.
48DBMS components
49Database architecture
50DB models - hierarchical
51DB models network
52DB model - relational
53Relation
- A relation, in appearance, is a two-dementional
table.
54SQL
- 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-by-step procedure.
55Operations on relations - insert
insert into COURSES values (CIS52, TCP/IP
Protocols, 6)
56Operations on relations - delete
delete from COURSESwhere NoCIS19
57Operations on relations - update
update COURSESset Unit 6where No CIS51
58Operations on relations - select
select from COURSESwhere Unit 5
59Operations on relations - project
select No, Unitfrom COURSES
60Operations on relations - join
select No, Course-Name, Unit, Professorfrom
COURSES, TAUGHT-BYwhere COURSES.No TAUGHT-BY.No
61Operations on relations - union
select from CIS15-Rosterunion select from
CIS52-Roster
62Operations on relations - intersection
select from CIS15-Rosterintersectionselect
from CIS52-Roster
63Operations on relations - difference
select from CIS15-Rosterminus select from
CIS52-Roster
64Objectives
- 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.