computer science: an overview tenth edition
TRANSCRIPT
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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-3
Software Engineering
Principles to guide the development of
• large,
• complex
software systems
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
Socio-technical systems
• technical components & operational
process
• people
• organization policies and rules
7-4
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-5
Software Engineering
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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 6
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-9
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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-10
Computer Aided Software
Engineering (CASE) tools
• Project planning
• Project management
• Documentation
• Prototyping and simulation
• Interface design
• Programming
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-11
The software life cycle
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-12
The development phase of the
software life cycle
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-13
Requirement & Specification Stage
• Requirements
– Application oriented
– Elicitation
• Specifications
– Technically oriented
• Software requirements document
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-14
Design Stage
• Methodologies and tools (discussed later)
• Human interface
– psychology and
– ergonomics (功效學、人類工程學)
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-15
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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-16
Testing Stage
• Validation testing
– Confirm that system meets specifications
• Defect testing
– Find bugs
• Component testing
• Integration testing
• Stress testing
• Performance testing
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-17
Software Engineering
- 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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
Waterfall model
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
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.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
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.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
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.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
Evolutionary development
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
Evolutionary development
• 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.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
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.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
Reuse-oriented development
Check if the
requirement is
OK with used
components
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
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.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
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.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
Incremental development
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
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.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
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 ?)
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
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.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
Spiral model of the software process
Determine objectives,
alternatives, and
constraints
Evaluate alternatives
Identify, resolve risks
Plan next phase Develop, verify
next-level product
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-34
Modularity
• Procedures -- Imperative paradigm
– Structure charts
• Objects -- Object-oriented (OO) paradigm
– Collaboration diagrams
• Components -- Component architecture
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-35
A simple structure chart
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-36
The structure of PlayerClass and its
instances
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-37
The interaction between objects
resulting from PlayerA’s serve
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-38
A structure chart including data
coupling
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-39
Coupling versus Cohesion
Modularity for information hiding
• Coupling
– linkage between modules
to minimize it
• Cohesion
– internal binding
to maximize it
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-40
Coupling versus Cohesion
• 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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-41
Coupling versus 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.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-42
Logical and functional cohesion within
an object
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-43
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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-44
A simple dataflow diagram
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-45
A simple use case diagram
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-46
A simple class diagram
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-47
Unified Modeling Language
• use case diagram
– Use cases
– Actors
• class diagram
• sequence diagram
• statechart
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-48
One-to-one, one-to-many, and many-to-
many relationships between entities of
types X and Y
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-49
A class diagram depicting
generalizations
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-50
A sequence diagram depicting a
generic volley
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-51
Techniques for identifying and
validating class diagrams
Structured Walkthoughs
• “Theatrical” experiment
• Class-responsibility-collaboration (CRC)
cards
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-52
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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
觀察站╱智慧型手機 三強變雙雄 【聯合晚報╱馬瑞璿】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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
觀察站╱智慧型手機 三強變雙雄 【聯合晚報╱馬瑞璿】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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-55
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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-56
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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-57
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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-60
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.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-61
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
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7-62
Software Ownership (continued)
• Patents
– “Natural laws” are traditionally not patentable
• Trade secrets
– Non-disclosure agreements are legally
enforceable
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
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