Chapter 7 Software Engineering - PowerPoint PPT Presentation

1 / 64
About This Presentation
Title:

Chapter 7 Software Engineering

Description:

Chapter 7 Software Engineering Objectives Understand arrays and their usefulness. Understand records and the difference between an array and a record. – PowerPoint PPT presentation

Number of Views:297
Avg rating:3.0/5.0
Slides: 65
Provided by: zhao90
Category:

less

Transcript and Presenter's Notes

Title: 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.
Write a Comment
User Comments (0)
About PowerShow.com