Chapter 7 Software Engineering

1
Chapter 7 Software Engineering
2
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.

3
System life cycle

• Software, like many other products, goes through
  a cycle of repeating phases.

4
System development phases

• The development process in the software life
  cycle involves 4 phases.

5
Analysis

• Define the user (generic or specific?)
• Define the needs (expectations)
• Define the requirements
• Define the methods (to meet requirements)

6
Design phase

• The design phase defines how the system will
  accomplish what was defined in the analysis
  phase.
• Modularity
• Tools
• Structure chart
• UML

7
Implementation phase

• Tools
• Flow chart
• Pseudocode
• Coding

8
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.

9
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.

10
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.

11
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)

12
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

13
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.

14
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

15
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

16
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.

17
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.

18
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.

19
Quality factors
20
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.

21
Operability

• 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.

22
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?

23
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.

24
The quality circle
25
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.

26
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.

27
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.

28
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.

29
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.

30
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.

31
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.

32
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.

33
Data Structures
34
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.

35
Arrays - definition

• An array is a fixed-sized, sequenced collection
  of elements of the same data type.

36
Arrays memory layout
37
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?

38
Records - examples
39
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.

40
Inserting a node
41
Deleting a node
42
Traversing a list
43
Other data structure topics

• Stacks (page 233)
• Queues (page 235)
• Trees (page 237)
• Binary trees (page 239)
• Graphs (page 244)

44
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.

45
Databases
46
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.

47
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.

48
DBMS components
49
Database architecture
50
DB models - hierarchical
51
DB models network
52
DB model - relational
53
Relation

• A relation, in appearance, is a two-dementional
  table.

54
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-by-step procedure.

55
Operations on relations - insert
insert into COURSES values (CIS52, TCP/IP
Protocols, 6)
56
Operations on relations - delete
delete from COURSESwhere NoCIS19
57
Operations on relations - update
update COURSESset Unit 6where No CIS51
58
Operations on relations - select
select from COURSESwhere Unit 5
59
Operations on relations - project
select No, Unitfrom COURSES
60
Operations on relations - join
select No, Course-Name, Unit, Professorfrom
COURSES, TAUGHT-BYwhere COURSES.No TAUGHT-BY.No
61
Operations on relations - union
select from CIS15-Rosterunion select from
CIS52-Roster
62
Operations on relations - intersection
select from CIS15-Rosterintersectionselect
from CIS52-Roster
63
Operations on relations - difference
select from CIS15-Rosterminus select from
CIS52-Roster
64
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.