computer science: an overview tenth edition

Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Computer Science: An Overview

Tenth Edition

by

J. Glenn Brookshear

Chapter 7:

Software Engineering

Presentation files modified by Farn Wang

Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-2

Chapter 7: Software Engineering

• 7.1 The Software Engineering Discipline

• 7.2 The Software Life Cycle

• 7.3 Software Engineering Methodologies

• 7.4 Modularity

• 7.5 Tools of the Trade

• 7.6 Testing

• 7.7 Documentation

• 7.8 Software Ownership and Liability



Principles to guide the development of

• large,

• complex

software systems


Socio-technical systems

• technical components & operational

process

• people

• organization policies and rules

7-4



Challenges in large-scale software projects:

• requirement may be incomplete and may change.

• personnel may change.

• budget constraints may be tight.

• cost estimation in project execution – time, money, resources, …

• project partitioning

• module compatibility

• module interface

• wide-range of details


Ariane 501 explosion (1/2)

Report of the Inquiry Board.

• On 4 June 1996, only about 40 seconds

after initiation of the flight sequence, ……

• Caused by the complete loss of guidance

and attitude information 37 seconds after

start of the main engine ignition sequence

(30 seconds after lift-off).

7-7

http://www.ima.umn.edu/~arnold/disasters/ariane5rep.html


Ariane 501 explosion (2/2)

Report of the Inquiry Board.

• Due to specification and design errors in

the software of the inertial reference

system.

• A data conversion from 64-bit floating point

to 16-bit signed integer value.

– The floating point number which was

converted had a value greater than what could

be represented by a 16-bit signed integer.

7-8

http://www.ima.umn.edu/~arnold/disasters/ariane5rep.html


The Software Engineering

Discipline

• Distinct from other engineering fields

– Prefabricated components

– Metrics

• Progress on 2 levels

– by practitioners

– by theoreticians

• Professional Organizations: ACM, IEEE, etc.

– Codes of professional ethics

– Standards


Computer Aided Software

Engineering (CASE) tools

• Project planning

• Project management

• Documentation

• Prototyping and simulation

• Interface design

• Programming


The software life cycle


The development phase of the

software life cycle


Requirement & Specification Stage

• Requirements

– Application oriented

– Elicitation

• Specifications

– Technically oriented

• Software requirements document


Design Stage

• Methodologies and tools (discussed later)

• Human interface

– psychology and

– ergonomics （功效學、人類工程學）


Implementation Stage

• Create system from design

– Write programs

– Create data files

– Develop databases

• “software analyst” vs “programmer”

– software analyst: design steps, requirement

spec.

• senior programmer ?

– programmer: writing code


Testing Stage

• Validation testing

– Confirm that system meets specifications

• Defect testing

– Find bugs

• Component testing

• Integration testing

• Stress testing

• Performance testing



- Methodologies

• Waterfall Model

– Separate and distinct phases of specification

and development.

• Incremental Model

– Specification, development and validation are

interleaved.

– Prototyping (Evolutionary vs. Throwaway)

• Open-source Development

• Extreme Programming


Waterfall model


Waterfall model phases

The main drawback

• the difficulty of accommodating change

after the process is underway.

• One phase has to be complete before

moving onto the next phase.


Waterfall model problems

• Inflexible partitioning of the project into distinct stages

makes it difficult to respond to changing customer

requirements.

• Therefore, this model is only appropriate when the

requirements are well-understood and changes will be fairly

limited during the design process.

• Few business systems have stable requirements.

• The waterfall model is mostly used for large systems

engineering projects where a system is developed at

several sites.


Evolutionary development

• Exploratory development

– To work with customers and to evolve a final

system from an initial outline specification.

– Should start with well-understood

requirements and add new features as

proposed by the customer.

• Throw-away prototyping (what this is ?)

– To understand the system requirements.

– Should start with poorly understood

requirements to clarify what is really needed.



• Problems

– Lack of process visibility;

– Systems are often poorly structured;

– Special skills (e.g. in languages for rapid

prototyping) may be required.

• Applicability

– For small or medium-size interactive systems;

– For parts of large systems (e.g. the user

interface);

– For short-lifetime systems.


Component-based software engineering

• Based on systematic reuse where

systems are integrated from

– existing components or

– COTS (Commercial-off-the-shelf) systems.

• Process stages

– Component analysis;

– Requirements modification;

– System design with reuse;

– Development and integration.

• Becoming increasingly used as

component standards have emerged.


Reuse-oriented development

Check if the

requirement is

OK with used

components


Process iteration

• System requirements ALWAYS evolve in the

course of a project so process iteration where

earlier stages are reworked

always part of the process for large systems.

• Iteration can be applied to any of the generic

process models.

• Two (related) approaches

– Incremental delivery;

– Spiral development.


Incremental delivery

• Rather than deliver the system as a single delivery,

the development and delivery is broken down into

increments with

– each increment delivering part of the required

functionality.

• User requirements are prioritised and the highest

priority requirements are included in early increments.

• Once the development of an increment is started, the

requirements are frozen though requirements for later

increments can continue to evolve.


Incremental development


Incremental development advantages

• Customer value can be delivered with each

increment so system functionality is

available earlier.

• Early increments act as a prototype to help

elicit requirements for later increments.

• Lower risk of overall project failure.

• The highest priority system services tend

to receive the most testing.


Extreme programming

• An approach to development based on the

development and delivery of

very small increments of functionality.

• Relies on constant code improvement,

user involvement in the development team

and pairwise programming. (what ?)


Spiral development

• Process is represented as a spiral rather than

as a sequence of activities with backtracking.

• Each loop in the spiral represents a phase in

the process.

• No fixed phases such as specification or

design

– loops in the spiral are chosen depending on what

is required.

• Risks are explicitly assessed and resolved

throughout the process.


Spiral model of the software process

Determine objectives,

alternatives, and

constraints

Evaluate alternatives

Identify, resolve risks

Plan next phase Develop, verify

next-level product


Spiral model sectors

• Objective setting

– Specific objectives for the phase (loop) are identified.

• Risk assessment and reduction

– Risks are assessed and activities put in place to reduce the key risks.

• Development and validation

– A development model for the system is chosen which can be any of the generic models.

• Planning

– The project is reviewed and the next phase of the spiral is planned.

7-33


Modularity

• Procedures -- Imperative paradigm

– Structure charts

• Objects -- Object-oriented (OO) paradigm

– Collaboration diagrams

• Components -- Component architecture


A simple structure chart


The structure of PlayerClass and its

instances


The interaction between objects

resulting from PlayerA’s serve


A structure chart including data

coupling


Coupling versus Cohesion

Modularity for information hiding

• Coupling

– linkage between modules

to minimize it

• Cohesion

– internal binding

to maximize it



• Coupling

– Intermodule coupling is an important measure

of software complexity.

– Control coupling

• control passing among modules

– Data coupling

• data sharing among modules

• explicit parameter passing

• implicit global variable sharing

• Cohesion



• Coupling

• Cohesion

– Logical cohesion

• actions in a module similar to each other

– Functional cohesion

• all parts of a module are focused on the

performance of a single activity.


Logical and functional cohesion within

an object


Tools of the Trade

• Data Flow Diagram

• Entity-Relationship Diagram

– One-to-one relation

– One-to-many relation

– Many-to-many relation

• Data Dictionary for each items

– identifiers, valid entries,

– where to store, where referenced


A simple dataflow diagram


A simple use case diagram


A simple class diagram


Unified Modeling Language

• use case diagram

– Use cases

– Actors

• class diagram

• sequence diagram

• statechart


One-to-one, one-to-many, and many-to-

many relationships between entities of

types X and Y


A class diagram depicting

generalizations


A sequence diagram depicting a

generic volley


Techniques for identifying and

validating class diagrams

Structured Walkthoughs

• “Theatrical” experiment

• Class-responsibility-collaboration (CRC)

cards


Design Patterns

• Well designed “templates” for solving recurring problems

• Examples: – Adapter pattern: Used to adapt a module’s interface to

current needs

– Decorator pattern: Used to control the complexity involved when many different combinations of the same activities are required

• Inspired by the work of Christopher Alexander in architecture


觀察站╱智慧型手機三強變雙雄【聯合晚報╱馬瑞璿】2012.05.10 02:40 pm

若說2011年智慧型手機市場是三強鼎立的一年，那麼，2012年智慧型手機市場的發展，絕對跟前一年度完全不同，不管從產品設計、銷量、甚至是客戶服務、產品耐用問題來作觀察，三星都已穩坐Android龍頭寶座，僅有蘋果能與之相抗衡，一般預料，2012年智慧型手機市場將是雙雄爭霸的一年。

從三強轉變為雙雄，不用懷疑，hTC已經被超前，落於三星之後。

會這麼說，並不偏頗，特別是這兩家業者同樣都打機海戰術，孰高孰下，立見分明。

先比較兩家業者今年的旗艦機種規格，hTC One X搭載Nvidia Tegra 3

1.5GHz四核心處理器，擁有前後兩個鏡頭，前鏡頭130萬畫素、後鏡頭則是800萬畫素，採4.7吋LCD螢幕，通訊規格橫跨2G、3G系統，並且支援中國特殊的3G規格TD-SCDMA ；而三星Galaxy S3則是搭載Exynos 4

1.4GHz四核心處理器，同樣擁有前後兩個鏡頭，前鏡頭190萬畫素，後鏡頭800萬畫素，採4.8吋HD Super AMOLED螢幕，通訊規格不僅支援2

G、3G，甚至支援到最新的4G LTE技術。

7-53


觀察站╱智慧型手機三強變雙雄【聯合晚報╱馬瑞璿】2012.05.10 02:40 pm

(continued)

以規格來論，三星顯示技術確實獨步全球，不過，其他部分，兩家業者旗艦機種不相上下，只是因為所支援的通訊技術不同，主打的市場也將略有差異，HTC One X因為支援TD-SCDMA，勢必可在中國大陸市場獨領風騷，而Galaxy S3則是通吃全球市場，並搶先一步進入4G市場。

可是，在這個業界中，要贏，靠得不只是規格，能否打耐久戰，是一個重要關鍵。

產業分析師就直言，兩家旗艦機種規格一樣，但因為產品瑕疵問題，讓今年初率先發表的One X聲勢大不如前，更遑論身邊採用hTC者，多因為產品系統以及耐用問題，對於是否要二度購買hTC望之卻步，hTC未來能否重回市場主流，靠的不是先進設計，關鍵在於耐用。

2012年已經走完一個季度，市場高下已見分明，hTC One系列雖陸續出貨，但產品瑕疵令消費者相當猶豫；三星Galaxy S3正式問世，雖然規格並不令人驚艷，但市場普遍看好後續銷售表現。諾基亞Lumia系列則是雷聲大、雨點小，雖然去年在歐洲市場推出後獲得好評，但銷量慘兮兮，產業分析師預估，至今為止，該系列全球銷售量僅在200萬支左右。

7-54


Software Testing Strategies(1/2)

According to assumptions on SUT

• Glass-box (white-box) testing

– Pareto principle (80-20 rule)

• a small set of modules responsible for most errors.

– Basis path testing

– for component testing

• Black-box testing

– According to specification, interface

– Boundary value analysis

– Domain analysis

System

under test


Software Testing Strategies (2/2)

According to the purpose

• Unit (component, module) testing

• Integration testing, system testing,

• Alpha testing, beta testing, validation testing

• Regression testing

• Stress testing

• Performance testing

• Redundancy testing


Software Testing Criteria

To know how much we have tested.

• For white-box testing:

– Line coverage

– Branch coverage

• For black-box testing

– domain analysis

– fault-based testing

– curve of bug-detection rates


Pareto principle (80-20 rule)

• Law of the vital few

– A few modules more buggy than the rest

• Principle of factor sparsity

– For many events, roughly 80% of the effects

come from 20% of the causes.

• Named by business management thinker

Joseph M. Juran

– Vilfredo Pareto, an Italian economist,

observed that 80% of the land in Italy was

owned by 20% of the population.

7-58

http://en.wikipedia.org/wiki/Joseph_M._Juran

http://en.wikipedia.org/wiki/Vilfredo_Pareto


Pareto principle (80-20 rule)

• A rule of thumb in business; e.g., "80% of

your sales come from 20% of your clients."

• Mathematically, where something is

shared among a sufficiently large set of

participants, there will always be a number

k between 50 and 100 such that k% is

taken by (100 − k)% of the participants.

7-59

http://en.wikipedia.org/wiki/Rule_of_thumb


Documentation

• User Documentation

– Printed book for all customers

– On-line help modules

• System Documentation

– Source code

– Design documents

• Technical Documentation

– For installing, customizing, updating, etc.


Software Ownership

Copyright

• The “substantial similarity” test

• Filtration criteria: what is not copyrightable

– Features covered by standards

– Characteristics dictated by software purpose

– Components in the public domain

• The “look and feel” argument


Software Ownership (continued)

• Patents

– “Natural laws” are traditionally not patentable

• Trade secrets

– Non-disclosure agreements are legally

enforceable


Liability

• Disclaimers are rarely recognized in court

if the plaintiff can show the negligence of

the defendant.

• Defendants need to prove that a level of

care compatible with the products has

been used.

7-63

computer science: an overview tenth edition

Documents