Transcript PowerPoint 演示文稿

Prof.Dr. Hongwei Zhang 张洪伟
[email protected]
http://www.mhhe.com/
SOFTWARE ENGINEERING: A Practitioner's
Approach w/ E-Source on CD-ROM, Fifth Edition
Author: Roger S. Pressman,
Chapter 1 - The Product
Overview
•Software is designed and built by software engineers.
•Software is used by virtually everyone in society.
•Software engineers have a moral obligation to build
reliable software that does no harm to other people.
1
•Software users are only concerned with whether or not
software products meet their expectations and make their
tasks easier to complete.
•Software engineers view computer software, as being
made up of the programs, documents, and data required to
design and build the system.
Software
•Software is both a product and a vehicle for developing a
product.
2
•Software does not wear out, but it does deteriorate.
•Currently, most software is still custom-built.
Software Application Types
•System software
•Real-time software
•Business software
•Engineering and scientific software
•Embedded software
•Personal computer software
•Web-based software
Artificial intelligence software
•Software is engineered not manufactured.
3
•Giving software projects to outside parties to develop
solves software project management problems. The
reality is people who can抰 manage internal software
development problems will struggle to manage or
control the external development of software too.
•Adding people is a good way to catch up when a
project is behind schedule. The reality is that adding
people only helps the project schedule when is it done
in a planned, well-coordinated manner.
•A general statement of objectives from the customer
is all that is needed to begin a software project. The
reality is without constant communication between the
customer and the developers it is impossible to build a
software product that meets the customer's real needs.
4
•Project requirements change continually and change
is easy to accommodate in the software design. The
reality is that every change has far-reaching and
unexpected consequences. Changes to software
requirements must be managed very carefully to keep
a software project on time and under budget.
•Once a program is written, the software engineer's
work is finished. The reality is that maintaining a
piece of software is never done, until the software
product is retired from service.
5
•There is no way to assess the quality of a piece of
software until it is actually running on some machine.
The reality is that one of the most effective quality
assurance practices (formal technical reviews) can be
applied to any software design product and can serve as
a quality filter very early in the product life cycle.
•The only deliverable from a successful software project
is the working program. The reality is the working
program is only one of several deliverables that arise
from a well-managed software project. The
documentation is also important since it provides a basis
for software support after delivery.
6
Software engineering is all about the creation of large
and unnecessary documentation. The reality is that
software engineering is concerned with creating quality.
This means doing things right the first time and not
having to create deliverables needed to complete or
maintain a software product. This practice usually leads
to faster delivery times and shorter development cycles.
7
Chapter 2 - The Process
Overview
•The roadmap to building high quality software
products is software process.
•Software processes are adapted to meet the needs of
software engineers and managers as they undertake the
development of a software product.
•A software process provides a framework for
managing activities that can very easily get out of
control.
•Different projects require different software processes.
8
•The software engineer's work products (programs,
documentation, data) are produced as consequences of
the activities defined by the software process.
•The best indicators of how well a software process has
worked are the quality, timeliness, and long-term
viability of the resulting software product.
Software Engineering
Software engineering encompasses a process,
management techniques, technical methods, and the use
of tools.
9
Generic Software Engineering Phases
•Definition phase - focuses on what (information
engineering, software project planning,
requirements analysis).
•Development phase - focuses on how (software
design, code generation, software testing).
•Support phase - focuses on change (corrective
maintenance, adaptive maintenance, perfective
maintenance, preventative maintenance).
Software Engineering Umbrella Activities
•Software project tracking and control
•Formal technical reviews
10
Software quality assurance
•Software configuration management
•Document preparation and production
•Reusability management
•Measurement
•Risk management
Common Process Framework
•Software engineering work tasks
•Project milestones
•Work products
Quality assurance points
11
Software Engineering Institute (SEI) Capability
Maturity Model (CMM)
•Level 1: Initial (ad hoc software processes)
•Level 2: Repeatable (able to repeat earlier successes)
•Level 3: Defined (management and engineering
processes documented, standardized, and integrated
into organization-wide software process)
•Level 4; Managed (software process and products
are quantitatively understood and controlled using
detailed measures)
12
•Level 5: Optimizing (continuous process
improvement is enabled by quantitative feedback
from the process and testing innovative ideas)
Software Process Models
•Linear Sequential Model (old fashioned but
reasonable approach when requirements are well
understood)
Prototyping Model (good first step when customer
has a legitimate need, but is clueless about the details,
developer needs to resist pressure to extend a rough
prototype into a production product)
13
•Rapid Application and Development (RAD) Model
(makes heavy use of reusable software components
with an extremely short development cycle)
•Incremental Model (delivers software in small but
usable pieces, each piece builds on pieces already
delivered)
•Spiral Model (couples iterative nature of prototyping
with the controlled and systematic aspects of the linear
sequential model)
•Win-Win Spiral Model (eliciting software
requirements defined through negotiation between
customer and developer, where each party attempts to
balance technical and business constraints)
14
•Concurrent Development Model (similar to spiral
model often used in development of client/server
applications)
•Component-Based Development (spiral model
variation in which applications are built from
prepackaged software components called classes)
•Formal Methods Model (rigorous mathematical
notation used to specify, design, and verify computerbased systems)
Fourth Generation (4GT) Techniques (software tool is
used to generate the source code for a software system
from a high level specification representation)
15
Chapter 10 - System Engineering
Overview
•Before software can be engineered, the system it is part of
must be understood. The overall objective of the system
must be determined, the role of the system elements
(hardware, software, people, data, etc.) must be identified,
and the operational requirements must be created. A
representation (i.e. prototype, specification, symbolic
model) of the system is produced as the result of the
system engineering process. It is important that system
engineering work products be managed using the quality
assurance techniques discussed in Chapter 8.
16
Systems
•Don't take a "software-centric" view of the system;
consider all system elements before focusing on
software.
•Good system engineering begins with a clear
understanding of the "world view" and progressively
narrows until technical detail is understood.
•Complex systems are actually a hierarchy of macroelements that are themselves systems
17
Computer-Based System Elements
•Software
•Hardware
•People
•Database
•Documentation
•Procedures
18
System Engineering Hierarchy
•World view
•Domain view
•Element view
•Detailed view
19
System Modeling
•Define the processes that serve the needs
of the view under consideration
•Represent the process behavior and the
assumptions on which the behavior is
modeled
•Explicitly define the exogenous (links
between constituents) and endogenous
(links between constituent components)
input to the model
20
•Represent all linkages (including outputs)
required to understand the view
System Model Restraining Factors
•Assumptions
•Simplifications
•Limitations
•Constraints
•Preferences
21
System Simulation
•If simulation capability is not available for a
reactive system, project risk increases.
•Consider using an iterative process model that will
allow the delivery and testing of incrementally
more complete products.
22
Business Process Engineering Hierarchy
•Information Strategy Planning (world view)
•Business Area Analysis (domain view)
•Business System Design (element view - software
engineers)
Construction and Integration (detailed view software engineers)
23
Business Process Engineering Architectures
•Data architecture - provides framework for
information needs of a business or business function
•Applications architecture - those system elements
that transform objects within the data architecture
for some business purpose
•Technology infrastructure - provides foundation for
the data and application architectures
24
Product Engineering Hierarchy
•Requirements engineering (world view)
•Component engineering (domain view)
•Analysis and Design modeling (element view software engineers)
Construction and Integration (detailed view software engineers)
25
Requirements Engineering
•Requirements elicitation (find out from customers
what the product objectives are, what is to be done,
how the product fits into business needs, and how
the product is used on a day to day basis)
•Requirements analysis and negotiation
(requirements are categorized and organized into
subsets, relations among requirements identified,
requirements reviewed for correctness,
requirements prioritized based on customer needs)
26
•Requirements specification (work product produced
describing the function, performance, and
development constraints for a computer-based system)
•System modeling (system representation that shows
relationships among the system components)
•Requirements validation (examines the specification
to ensure requirement quality and that work products
conform to agreed upon standards)
Requirements management (set of activities that help
project team to identify, control, and track
requirements and changes as project proceeds)
27
Traceability Tables
•Features traceability table
•Source traceability table
•Dependency traceability table
•Subsystem traceability table
•Interface traceability table
28
System Model Template
•User interface
·
Input
·
Process and control functions
·
Output
·
Maintenance and self test
Systems Modeling Process
29
•System Context Diagram (SCD) - top level node
in system hierarchy used to establish the
boundary between the system being implemented
(system model template serves as its basis)
•System Flow Diagram (SFD) - refinement of the
process and control functions from SCD, derived
by identifying the major subsystems and lines of
information flow (precursor to Data Flow
Diagram discussed in Chapter 12)
30
•Initial SFD is becomes the top level node of a
hierarchy of more successively more detailed
SFD's
•System Specification - developed by writing
narrative description for each subsystem and
definitions for all data that flow between
subsystems
31
Chapter 11 - Analysis Concepts and Principles
Overview
After system engineering is completed, software
engineers need to look at the role of software in the
proposed system. Software requirements analysis is
necessary to avoid creating a software product that fails
to meet the customer's needs. Data, functional, and
behavioral requirements are elicited from the customer
and refined to create a specification that can be used to
design the system. Software requirements work
products must be reviewed for clarity, completeness,
and consistency.
32
Requirements Analysis
•Software engineering task that bridges the gap between
system level requirements engineering and software
design.
•Provides software designer with a representation of
system information, function, and behavior that can be
translated to data, architectural, and component-level
designs
33
•Expect to do a little bit of design during analysis and
a little bit of analysis during design.
Software Requirements Analysis Phases
•Problem recognition
•Evaluation and synthesis (focus is on what not how)
•Modeling
•Specification
•Review
34
Software Requirements Elicitation
•Customer meetings are the most commonly used
technique.
•Use context free questions to find out customer's
goals and benefits, identify stakeholders, gain
understanding of problem, determine customer
reactions to proposed solutions, and assess meeting
effectiveness.
If many users are involved, be certain that a
representative cross section of users is interviewed.
35
Facilitated Action Specification Techniques (FAST)
•Meeting held at neutral site, attended by both software
engineers and customers.
•Rules established for preparation and participation.
•Agenda suggested to cover important points and to allow for
brainstorming.
•Meeting controlled by facilitator (customer, developer, or
outsider).
•Definition mechanism (flip charts, stickers, electronic
device, etc.) is used.
•Goal is to identify problem, propose elements of solution,
negotiate different approaches, and specify a preliminary set
of solution requirements.
36
Quality Function Deployment (QFD)
•Translates customer needs into technical software
requirements.
•Uses customer interviews, observation, surveys, and
historical data for requirements gathering.
•Customer voice table (contains summary of
requirements)
Normal requirements (must be present in product for
customer to be satisfied)
37
•Expected requirements (things like ease of use or
reliability of operation, that customer assumes will be
present in a professionally developed product without
having to request them explicitly)
•Exciting requirements (features that go beyond the
customer's expectations and prove to be very
satisfying when they are present)
•Function deployment (used during customer
meetings to determine the value of each function
required for system)
38
•Task deployment (examines the behavior of
product within it environment)
Value analysis (used to determine the relative
priority of requirements during function,
information, and task deployment)
•Information deployment (identifies data objects
and events produced and consumed by the
system)
39
Use-Cases
•Scenarios that describe how the product will be used
in specific situations.
•Written narratives that describe the role of an actor
(user or device) as interaction with the system occurs.
•Use-cases are designed from the actor's point of view.
•Not all actors can be identified during the first
iteration of requirements elicitation, but it is important
to identify the primary actors before developing the
use-cases.
40
Analysis Principles
•The information domain of the problem must be
represented and understood.
•The functions that the software is to perform must
be defined.
Software behavior must be represented.
41
•Models depicting information, function, and behavior
must be partitioned in a hierarchical manner that
uncovers detail.
•The analysis process should move from the essential
information toward implementation detail.
Information Domain
•Encompasses all data objects that contain numbers, text,
images, audio, or video.
42
•Information content or data model (shows the
relationships among the data and control objects
that make up the system)
•Information flow (represents the manner in which
data and control objects change as each moves
through the system)
Information structure (representations of the
internal organizations of various data and control
items)
43
Modeling
•Data model (shows relationships among system
objects)
•Functional model (description of the functions that
enable the transformations of system objects)
•Behavioral model (manner in which software
responds to events from the outside world)
Partitioning
•Process that results in the elaboration of data, function,
or behavior.
44
•Horizontal partitioning is a breadth-first
decomposition of the system function, behavior, or
information, one level at a time.
•Vertical partitioning is a depth-first elaboration of
the system function, behavior, or information, one
subsytem at a time.
Software Requirements Views
Essential view - presents the functions to be
accomplished and the information to be processed
without regard to implementation
45
•Implementation view - presents the real world
manifestation of processing functions and information
structures.
•Avoid the temptation to move directly to the
implementation view, assuming that the essence of the
problem is obvious.
46
Software Prototyping
•Throwaway prototyping (prototype only used as
a demonstration of product requirements,
finished software is engineered using another
paradigm)
•Evolutionary prototyping (prototype is refined
to build the finished system)
•Customer resources must be committed to
evaluation and refinement of the prototype.
Customer must be capable of making
requirements decisions in a timely manner.
47
Prototyping Methods and Tools
•Fourth generation techniques (4GT tools allow
software engineer to generate executable code quickly)
·Reusable
software
components
(assembling
prototype from a set of existing software components)
·Formal specification and prototyping environments
(can interactively create executable programs from
software specification models)
48
Specification Principles
•Separate functionality from implementation.
•Develop a behavioral model that describes
functional responses to all system stimuli.
•Define the environment in which the system
operates and indicate how the collection of agents
will interact with it.
Create a cognitive model rather than an
implementation model.
49
•Recognize that the specification must be extensible and
tolerant of incompleteness.
•Establish the content and structure of a specification so
that it can be changed easily.
Specification Representation
•Representation format and content should be relevant to
the problem.
•Information contained within the specification should be
nested.
•Diagrams and other notational forms should be restricted
in number and consistent in use.
50
•Representations should be revisable.
Specification Review
Conducted by customer and software developer.
•Once approved, the specification becomes a
contract for software development.
•The specification is difficult to test in a meaningful
way.
Assessing the impact of specification changes is
hard to do.
51
Chapter 12 - Analysis Modeling
The analysis model is the first technical representation of a
system. Analysis modeling uses a combination of text and
diagrams to represent software requirements (data, function,
and behavior) in an understandable way. Building analysis
models helps make it easier to uncover requirement
inconsistencies and omissions. Two types of analysis
modeling are commonly used: structured
52
analysis (discussed in this chapter) and objectoriented analysis (discussed in Chapter 21). Data
modeling uses entity-relationship diagrams to
define data objects, attributes, and relationships.
Functional modeling uses data flow diagrams to
show how data are transformed inside the system.
Behavioral modeling uses state transition diagrams
to show the impact of events. Analysis work
products must be reviewed for completeness,
correctness, and consistency. The SEPA web site
contains descriptions of several classical analysis
techniques (DSSD, JSD, SADT).
53
Structured Analysis (DeMarco)
•Analysis products must be highly maintainable, especially
the software requirements specification.
•Problems of size must be dealt with using an effective
method of partitioning.
•Graphics should be used whenever possible.
•Differentiate between the logical (essential) and physical
(implementation) considerations.
•Find something to help with requirements partitioning and
document the partitioning before specification.
54
•Devise a way to track and evaluate user
interfaces.
•Devise tools that describe logic and policy
better than narrative text.
Analysis Model Objectives
•Describe what the customer requires.
•Establish a basis for the creation of a software
design.
Devise a set of requirements that can be
validated once the software is built.
55
Analysis Model Elements
•Data dictionary - contains the descriptions of all data
objects consumed or produced by the software
•Entity relationship diagram (ERD) - depicts relationships
between data objects
•Data flow diagram (DFD) - provides an indication of
how data are transformed as they move through the
system; also depicts functions that transform the data flow
(a function is represented in a DFD using a process
specification or PSPEC)
•State transition diagram (STD) - indicates how the
system behaves as a consequence of external
56
•events, states are used to represent behavior modes.
Arcs are labeled with the events triggering the
transitions from one state to another (control
information is contained in control specification or
CSPEC)
Data Modeling Elements (ERD)
•Data object - any person, organization, device, or
software product that produces or consumes
information
•Attributes - name a data object instance, describe its
characteristics, or make reference to another data
object
Relationships - indicate the manner in which data
objects are connected to one another
57
Cardinality and Modality (ERD)
•Cardinality - in data modeling, cardinality specifies
how the number of occurrences of one object are
related to the number of occurrences of another object
(1:1, 1:N, M:N)
•Modality - zero (0) for an optional object relationship
and one (1) for a mandatory relationship
Functional Modeling and Information Flow (DFD)
58
•Shows the relationships of external entities,
process or transforms, data items, and data stores
•DFD's cannot show procedural detail (e.g.
conditionals or loops) only the flow of data through
the software
•Refinement from one DFD level to the next
should follow approximately a 1:5 ratio (this ratio
will reduce as the refinement proceeds)
To model real-time systems, structured analysis
notation must be available for time continuous data
and event processing (e.g. Ward and Mellor or
Hately and Pirbhai)
59
Behavioral Modeling (STD)
•State transition diagrams represent the system states and
events that trigger state transitions
•STD's indicate actions (e.g. process activation) taken as a
consequence of a particular event
•A state is any observable mode of behavior
•Hatley and Pirbhai control flow diagrams (CFD) can also
be used for behavioral modeling
60
Creating Entity Relationship Diagrams
•Customer asked to list "things" that application
addresses, these things evolve into input objects,
output objects, and external entities
•Analyst and customer define connections between
the objects
•One or more object-relationship pairs is created for
each connection
The cardinality and modality are determined for an
object-relationship pair
61
•Attributes of each entity are defined
•The entity diagram is reviewed and refined
Creating Data Flow Diagram
•Level 0 data flow diagram should depict the system as
a single bubble
•Primary input and output should be carefully noted
•Refinement should begin by consolidating candidate
processes, data objects, and data stores to be
represented at the next level
62
•Label all arrows with meaningful names
•Information flow must be maintained from one level
to level
•Refine one bubble at a time
•Write a PSPEC (a "mini-spec" written using English
or another natural language or a program design
language) for each bubble in the final DFD
63
Creating Control Flow Diagrams
•Begin by stripping all the data flow arrows form the DFD
•Events (solid arrows) and control items (dashed arrows)
are added to the diagram
•Add a window to the CSPEC (contains an STD that is a
sequential specification of the behavior) for each bubble in
the final CFD
Data Dictionary Contents
64
•Name - primary name for each data or control
item, data store, or external entity
•Alias - alternate names for each data object
•Where-used/how-used - a listing of processes that
use the data or control item and how it is used (e.g.
input to process, output from process, as a store, as
an external entity)
•Content description - notation for representing
content
Supplementary information - other data type
information, preset values, restrictions, limitations,
etc.
65
Chapter 13 - Design Concepts and Principles
Overview
A software design is a meaningful engineering
representation of some software product that is to be built.
A design can be traced to the customer's requirements and
can be assessed for quality against predefined criteria.
During the design process the software requirements model
is transformed into design models that describe the details
of the data structures, system architecture, interface, and
components. Each design product is reviewed for quality
before moving to the next phase of software development.
66
Design Specification Models
•Data design - created by transforming the
analysis information model (data dictionary and
ERD) into data structures required to implement
the software
Architectural design - defines the relationships
among the major structural elements of the
software, it is derived from the system
specification, the analysis model, and the
subsystem interactions defined in the analysis
model (DFD)
67
•Interface design - describes how the software elements
communicate with each other, with other systems, and with
human users; the data flow and control flow diagrams
provide much the necessary information
•Component-level design - created by transforming the
structural elements defined by the software architecture into
procedural descriptions of software components using
information obtained from the PSPEC, CSPEC, and STD
Design Guidelines
A design should
•exhibit good architectural structure
•be modular
68
•contain distinct representations of data, architecture,
interfaces, and components (modules)
•lead to data structures that are appropriate for the
objects to be implemented and be drawn from
recognizable design patterns
•lead to components that exhibit independent
functional characteristics
•lead to interfaces that reduce the complexity of
connections between modules and with the external
environment
•be derived using a reputable method that is driven by
information obtained during software requirements
analysis
69
Design Principles
The design
•process should not suffer from tunnel vision
•should be traceable to the analysis model
•should not reinvent the wheel
•should minimize intellectual distance between the
software and the problem as it exists in the real world
70
•should exhibit uniformity and integration
•should be structured to accommodate change
•should be structured to degrade gently, even with bad
data, events, or operating conditions are encountered
•should be assessed for quality as it is being created
should be reviewed to minimize conceptual (semantic)
errors
71
Fundamental Software Design Concepts
•Abstraction - allows designers to focus on solving a
problem without being concerned about irrelevant lower
level details (procedural abstraction - named sequence of
events, data abstraction - named collection of data objects)
•Refinement - process of elaboration where the designer
provides successively more detail for each design
component
•Modularity - the degree to which software can be
understood by examining its components independently of
one another
72
•Software architecture - overall structure of the software
components and the ways in which that structure
provides conceptual integrity for a system
•Control hierarchy or program structure - represents the
module organization and implies a control hierarchy, but
does not represent the procedural aspects of the software
(e.g. event sequences)
Structural partitioning - horizontal partitioning defines
three partitions (input, data transformations, and output);
vertical partitioning (factoring) distributes control in a
top-down manner (control decisions in top level
modules and processing work in the lower level
modules)
73
•Data structure - representation of the logical relationship
among individual data elements (requires at least as much
attention as algorithm design)
•Software procedure - precise specification of processing
(event sequences, decision points, repetitive operations,
data organization/structure)
•Information hiding - information (data and procedure)
contained within a module is inaccessible to modules that
have no need for such information
74
Modular Design Method Evaluation Criteria
•Modular decomposability - provides systematic
means for breaking problem into subproblems
•Modular composability - supports reuse of existing
modules in new systems
•Modular understandability - module can be
understood as a stand-alone unit
•Modular continuity - side-effects due to module
changes minimized
Modular protection - side-effects due to processing
errors minimized
75
Control Terminology
•Span of control (number of levels of control within a
software product)
•Depth (distance between the top and bottom modules in
program control structure)
•Fan-out or width (number of modules directly controlled by
a particular module)
•Fan-in (number of modules that control a particular module)
•Visibility (set of program components that may be called or
used as data by a given component)
76
•Connectivity (set of components that are called
directly or are used as data by a given component)
Effective Modular Design
•Functional independence - modules have high
cohesion and low coupling
•Cohesion - qualitative indication of the degree to
which a module focuses on just one thing
Coupling - qualitative indication of the degree to
which a module is connected to other modules and to
the outside world
77
Design Heuristics for Effective Modularity
•Evaluate the first iteration of the program structure to
reduce coupling and improve cohesion.
•Attempt to minimize structures with high fan-out; strive for
fan-in as structure depth increases.
•Keep the scope of effect of a module within the scope of
control for that module.
78
•Evaluate module interfaces to reduce complexity,
reduce redundancy, and improve consistency.
•Define modules whose function is predictable and
not overly restrictive (e.g. a module that only
implements a single subfunction).
Strive for controlled entry modules, avoid
pathological connection (e.g. branches into the middle
of another module)
79
Chapter 14 – Design Method
14.1 Architectural Design
Overview
Architectural design represents the structure of the data
and program components required to build a computerbased system. A number of architectural "styles" exist.
Architectural design begins with data design and proceeds
to the derivation of one or more representations of the
architectural structure of the system. The resulting
architectural model encompasses both the data
architecture and the program structure. The architectural
model is subjected to software quality review like all
other design work products.
80
Software architecture is a representation that enables a
software engineer to
•Analyze the effectiveness of the design in meeting
stated requirements
•Consider architectural alternatives
•Reduce the risk associated with the construction of
the software
Examine the system as a whole
81
Data Design Principles
•Systematic analysis principles applied to function and
behavior should also be applied to data.
•All data structures and the operations to be performed on
each should be identified.
•Data dictionary should be established and used to define
both data and program design.
•Low level design processes should be deferred until late
in the design process.
•Representations of data structure should be known only to
those modules that must make direct use of the data
contained within in the data structure.
82
•A library of useful data structures and operations
should be developed.
•A software design and its implementation
language should support the specification and
realization of abstract data types.
Architectural Styles
Data centered - data store (e.g. file or database) lies
at the center of this architecture and is accessed
frequently by other components that modify data
83
•Data flow - input data is transformed by a series of
computational or manipulative components into output data
•Call and return - program structure decomposes function
into control hierarchy with main program invokes several
subprograms
•Object-oriented - components of system encapsulate data
and operations, communication between components is by
message passing
84
•Layered - several layers are defined, each accomplishing
operations that progressively become closer to the
machine instruction set
Architecture Design Assessment Questions
•How is control managed within the architecture?
•Does a distinct control hierarchy exist?
•How do components transfer control within the system?
How is control shared among components?
85
•What is the control topology?
•Is control synchronized or asynchronous?
•How are data communicated between components?
•Is the flow of data continuous or sporadic?
•What is the mode of data transfer?
•Do data components exist? If so what is their role?
86
•How do functional components interact with data
components?
•Are data components active or passive?
•How do data and control interact within the system?
Architecture Trade-off Analysis Method
1. Collect scenarios
Elicit requirements, constraints, and environmental
description
87
1.
Describe architectural styles/patterns chosen to
address scenarios and requirements (module view,
process view, data flow view)
2.
Evaluate quality attributes independently (e.g.
reliability, performance, security, maintainability,
flexibility,
testability,
portability,
reusability,
interoperability)
3.
Identify sensitivity points for architecture (any
attributes significantly affected by variation in the
architecture)
4.
Critique candidate architectures (from step 3) using
the sensitivity analysis (conducted in step 5)
Architectural Complexity (similar to coupling)
88
•Flow dependencies - represent dependence relationships
between producers and consumers of resources
•Constrained dependencies - represent constraints on the
relative flow among a set of components
•Sharing dependencies - represent dependence relationships
among consumers who use the same resource or producers
who produce for the same consumers
Mapping Requirements to Software Architecture in
Structured Design
Establish type of information flow (transform flow - overall
data flow is sequential and flows along a small number of
straight line paths; transaction flow - a single data item
triggers information flow along one of many paths)
89
•Flow boundaries indicated
•DFD is mapped into program structure
•Control hierarchy defined
•Resultant structure refined using design measures and
heuristics
•Architectural description refined and elaborated
Transform Mapping
90
•Review fundamental system model
•Review and refine data flow diagrams for the software
•Determine whether the DFD has transform or transaction
characteristics
•Isolate the transform center by specifying incoming and
outgoing flow boundaries
•Perform first level factoring
•Perform second level factoring
Refine the first iteration architecture using design
heuristics for improved software quality
91
Transaction Mapping
•Review fundamental system model
•Review and refine data flow diagrams for the software
•Determine whether the DFD has transform or transaction
characteristics
•Identify the transaction center and flow characteristics along
each action path
•Map the DFD to a program structure amenable to
transaction processing
•Factor and refine the transaction structure and the structure
of each action path
92
Refine the first iteration architecture using design
heuristics for improved software quality
Refining Architectural Design
•Processing narrative developed for each module
Interface description provided for each module
Local and global data structures are defined
•Design restrictions/limitations noted
•Design reviews conducted
Refinement considered if required and justified
93
Chapter 14.3 - User Interface Design
Overview
This chapter introduces the principles of user interface
design as it relates to the development of software
products. Proper interface design begins with careful
analysis of the user, the task and the environment. Once
the user's tasks are identified, user scenarios are created
and validated. Good user interfaces are designed, they
don't happen by chance. Prototyping is a common
approach to user interface design. Early involvement of
the user in the design process makes him or her more
likely to accept the final product. User interfaces must be
field tested and validated prior to general release.
94
Place User in Control
•Define interaction in such a way that the user is not
forced into performing unnecessary or undesired actions
•Provide for flexible interaction (users have varying
preferences)
Allow user interaction to be interruptible and reversible
95
•Streamline interaction as skill level increases and allow
customization of interaction
•Hide technical internals from the casual user
•Design for direct interaction with objects that appear on
the screen
Reduce User Memory Load
•Reduce demands on user's short-term memory
•Establish meaningful defaults
96
•Define intuitive short-cuts
•Visual layout of user interface should be based on a
familiar real world metaphor
•Disclose information in a progressive fashion
Make Interface Consistent
•Allow user to put the current task into a meaningful
context
•Maintain consistency across a family of applications
If past interaction models have created user expectations,
do not make changes unless there is a good reason to do so
97
User Interface Design Models
•Design model (incorporates data, architectural, interface,
and procedural representations of the software)
•User model (end user profiles - novice, knowledgeable
intermittent user, knowledgeable frequent users)
•User's model or system perception (user's mental image of
system)
•System image (look and feel of the interface and
supporting media)
User Interface Design Process (Spiral Model)
98
•User, task, and environment analysis and modeling
•Interface design
•Interface construction
•Interface validation
Task Analysis and Modeling
Software engineer studies tasks human users must
complete to accomplish their goal in the real world
without the computer and map these into a similar set
of tasks that are to be implemented in the context of
the user interface
99
•Software engineer studies existing specification for
computer-based solution and derives a set of tasks that will
accommodate the user model, design model, and system
perception
•Software engineer may devise an object-oriented approach
by observing the objects and actions the user makes use of
in the real world and model the interface objects after their
real world counterparts
Interface Design Activities
•Establish the goals and intentions of each task
•Map each goal/intention to a sequence of specific actions
(objects and methods for manipulating objects)
100
•Specify the action sequence of tasks and subtasks (user
scenario)
•Indicate the state of the system at the time the user scenario is
performed
•Define control mechanisms
•Show how control mechanisms affect the state of the system
•Indicate how the user interprets the state of the system from
information provided through the interface
Interface Design Issues
System response time (time between the point at which user
initiates some control action and the time when the system
responds)
101
•User help facilities (integrated, context sensitive help
versus add-on help)
•Error information handling (messages should be nonjudgmental, describe problem precisely, and suggest
valid solutions)
•Command labeling (based on user vocabulary, simple
grammar, and have consistent rules for abbreviation)
User Interface Evaluation Cycle
102
1. Preliminary design
2. Build first interface prototype
3. User evaluates interface
4. Evaluation studied by designer
5. Design modifications made
6. Build next prototype
7. If interface is not complete then go to step 3
103
User Interface Design Evaluation Criteria
•
Length and complexity of written interface
specification provide an indication of amount of
learning required by system users
Number of user tasks and the average number of
actions per task provide an indication of
interaction time and overall system efficiency
104
•Number of tasks, actions, and system states in the
design model provide an indication of the memory
load required of system users
Interface style, help facilities, and error handling
protocols provide a general indication of system
complexity and the degree of acceptance by the users
105
Chapter 14.4 - Component Level Design
Overview
The purpose of component level design is to translate the
design model into operational software. Component level
design occurs after the data, architectural, and interface
designs are established. Component-level design represents
the software in a way that allows the designer to review it for
correctness and consistency, before it is built. The work
product produced is the procedural design for each software
component, represented using graphical, tabular, or textbased notation.
106
Structured Programming
•Each block of code has a single entry at the top
•Each block of code has a single exit at the bottom
•Only three control structures are required: sequence,
condition (if-then-else), and repetition (looping)
Reduces program complexity by enhancing readability,
testability, and maintainability
107
Design Notation
•Flowcharts (arrows for flow of control, diamonds for
decisions, rectangles for processes)
•Box diagrams (also known as Nassi-Scheidnerman charts
- process boxes subdivided to show conditional and
repetitive steps)
•Decision table (subsets of system conditions and actions
are associated with each other to define the rules for
processing inputs and events)
•Program Design Language (PDL - structured English or
pseudocode used to describe processing details)
108
Program Design Language Characteristics
•Fixed syntax with keywords providing for
representation of all structured constructs, data
declarations, and module definitions
•Free syntax of natural language for describing
processing features
•Data declaration facilities for simple and complex
data structures
Subprogram definition and invocation facilities
109
Design Notation Assessment Criteria
•Modularity (notation supports development of modular
software)
•Overall simplicity (easy to learn, easy to use, easy to write)
•Ease of editing (easy to modify design representation when
changes are necessary)
•Machine readability (notation can be input directly into a
computer-based development system)
•Maintainability (maintenance of the configuration usually
involves maintenance of the procedural design representation)
110
•Structure enforcement (enforces the use of structured
programming constructs)
•Automatic processing (allows the designer to verify
the correctness and quality of the design)
•Data representation (ability to represent local and
global data directly)
•Logic verification (automatic logic verification
improves testing adequacy)
Easily converted to program source code (makes code
generation quicker)
111
Chapter 16 ?Software Testing Techniques
Overview
The importance of software testing to software quality can
not be overemphasized. Once source code has been
generated, software must be tested to allow errors to be
identified and removed before delivery to the customer.
While it is not possible to remove every error in a large
software package, the software engineer抯 goal is to remove
as many as possible early in the software development cycle.
It is
112
important to remember that testing can only find errors,
it cannot prove that a program is bug free. Two basic
test techniques involve testing module input/output
(black-box) and exercising internal logic of software
components (white-box). Formal technical reviews by
themselves can not find allow software defects, test
data must also be used. For large software projects,
separate test teams may be used to develop and
execute the set of test cases used in testing. Testing
must be planned and designed. The SEPA web site
contains the template for a generic test plan.
113
Software Testing Objectives
•Testing is the process of executing a program with the
intent of finding errors.
•A good test case is one with a high probability of finding
an as-yet undiscovered error.
•A successful test is one that discovers an as-yetundiscovered error.
Software Testing Principles
•All tests should be traceable to customer requirements.
•Tests should be planned long before testing begins.
114
•The Pareto principle (80% of all errors will likely be
found in 20% of the code) applies to software testing.
•Testing should begin in the small and progress to the
large.
•Exhaustive testing is not possible.
•To be most effective, testing should be conducted by an
independent third party.
Software Testability Checklist
•Operability (the better it works the more efficiently it
can be tested)
Observabilty (what you see is what you test)
115
•Controllability (the better software can be controlled the
more testing can be automated and optimized)
•Decomposability (by controlling the scope of testing, the
more quickly problems can be isolated and retested
intelligently)
•Simplicity (the less there is to test, the more quickly we
can test)
•Stability (the fewer the changes, the fewer the
disruptions to testing)
•Understandability (the more information known, the
smarter the testing)
116
Good Test Attributes
•A good test has a high probability of finding an error.
•A good test is not redundant.
•A good test should be best of breed.
A good test should not be too simple or too complex
117
Test Case Design Strategies
•Black-box or behavioral testing (knowing the specified
function a product is to perform and demonstrating
correct operation based solely on its specification
without regard for its internal logic)
•White-box or glass-box testing (knowing the internal
workings of a product, tests are performed to check the
workings of all insdependent logic paths)
118
Basis Path Testing
•White-box technique usually based on the program flow
graph
•The cyclomatic complexity of the program computed
from its flow graph using the formula V(G) = E ?N + 2
or by counting the conditional statements in the PDL
representation and adding 1
•Determine the basis set of linearly independent paths
(the cardinality of this set id the program cyclomatic
complexity)
Prepare test cases that will force the execution of each
path in the basis set.
119
Control Structure Testing
•White-box techniques focusing on control structures
present in the software
•Condition testing (e.g. branch testing) focuses on
testing each decision statement in a software module, it
is important to ensure coverage of all logical
combinations of data that may be processed by the
module (a truth table may be helpful)
•Data flow testing selects test paths based according to
the locations of variable definitions and uses in the
program (e.g. definition use chains)
•Loop testing focuses on the validity of the program
loop constructs (i.e. simple loops,
120
•concatenated loops, nested loops, unstructured loops),
involves checking to ensure loops start and stop when they
are supposed to (unstructured loops should be redesigned
whenever possible)
Graph-based Testing Methods
•Black-box methods based on the nature of the
relationships (links) among the program objects (nodes),
test cases are designed to traverse the entire graph
Transaction flow testing (nodes represent steps in some
transaction and links represent logical connections
between steps that need to be validated)
121
•Finite state modeling (nodes represent user observable
states of the software and links represent transitions
between states)
•Data flow modeling (nodes are data objects and links
are transformations from one data object to another)
•Timing modeling (nodes are program objects and links
are sequential connections between these objects, link
weights are required execution times)
Equivalence Partitioning
•Black-box technique that divides the input domain into
classes of data from which test cases can be derived
122
•An ideal test case uncovers a class of errors that might
require many arbitrary test cases to be executed before a
general error is observed
•Equivalence class guidelines:
1. If input condition specifies a range, one valid and two
invalid equivalence classes are defined
2. If an input condition requires a specific value, one valid
and two invalid equivalence classes are defined
3. If an input condition specifies a member of a set, one
valid and one invalid equivalence class is defined
If an input condition is Boolean, one valid and one invalid
equivalence class is defined
123
Boundary Value Analysis
•Black-box technique that focuses on the boundaries of the input
domain rather than its center
•BVA guidelines:
1. If input condition specifies a range bounded by values a and b,
test cases should include a and b, values just above and just
below a and b
2. If an input condition specifies and number of values, test
cases should be exercise the minimum and maximum numbers,
as well as values just above and just below the minimum and
maximum values
3. Apply guidelines 1 and 2 to output conditions, test cases
should be designed to produce the minimum and maxim output
reports
124
4. If internal program data structures have boundaries
(e.g. size limitations), be certain to test the boundaries
Comparison Testing
•Black-box testing for safety critical systems in which
independently developed implementations of redundant
systems are tested for conformance to specifications
Often equivalence class partitioning is used to develop a
common set of test cases for each implementation
125
Orthogonal Array Testing
•Black-box technique that enables the design of a
reasonably small set of test cases that provide maximum
test coverage
•Focus is on categories of faulty logic likely to be present in
the software component (without examining the code)
•Priorities for assessing tests using an orthogonal array
1.
Detect and isolate all single mode faults
2.
Detect all double mode faults
3.
Mutimode faults
Specialized Testing
126
•Graphical user interfaces (see Chapter 31 and the SEPA web
checklist)
•Client/server architectures (see Chapter 28)
•Documentation and help facilities (see Chapter 8 and Chapter
15)
•Real-time systems
1. Task testing (test each time dependent task independently)
2. Behavioral testing (simulate system response to external
events)
3. Intertask testing (check communications errors among tasks)
System testing (check interaction of integrated system software
and hardware)
127
Chapter 17 - Software Testing Strategies
Overview
This chapter describes several approaches to testing
software. Software testing must be planned carefully to
avoid wasting development time and resources. Testing
begins "in the small" and progresses "to the large".
Initially individual components are tested using white
box and black box techniques. After the individual
components have been tested and added to the system,
integration testing takes place. Once the full software
product is completed, system testing is performed. The
Test Specification document should be reviewed like all
other software engineering work products. A sample Test
Specification document appears on the SEPA web site.
128
Strategic Approach to Software Testing
•Testing begins at the component level and works outward
toward the integration of the entire computer-based system.
•Different testing techniques are appropriate at different
points in time.
•The developer of the software conducts testing and may
be assisted by independent test groups for large projects.
•The role of the independent tester is to remove the
conflict of interest inherent when the builder is testing his
or her own product.
129
•Testing and debugging are different activities.
•Debugging must be accommodated in any testing
strategy.
•Make a distinction between verification (are we
building the product right?) and validation (are we
building the right product?)
Strategic Testing Issues
•Specify product requirements in a quantifiable
manner before testing starts.
Specify testing objectives explicitly.
130
•Identify the user classes of the software and develop a
profile for each.
•Develop a test plan that emphasizes rapid cycle testing.
•Build robust software that is designed to test itself (e.g.
uses anitbugging).
•Use effective formal reviews as a filter prior to testing.
•Conduct formal technical reviews to assess the test
strategy and test cases.
Unit Testing
131
•Black box and white box testing.
•Module interfaces are tested for proper information
flow.
•Local data are examined to ensure that integrity is
maintained.
•Boundary conditions are tested.
•Basis path testing should be used.
•All error handling paths should be tested.
Drivers and/or stubs need to be developed to test
incomplete software.
132
Integration Testing
•Top-down integration testing
1.
Main control module used as a test driver and stubs are
substitutes for components directly subordinate to it.
2.
Subordinate stubs are replaced one at a time with real
components (following the depth-first or breadth-first
approach).
3.
Tests are conducted as each component is integrated.
4.
On completion of each set of tests and other stub is
replaced with a real component.
133
5.
Regression testing may be used to ensure that new
errors not introduced.
•Bottom-up integration testing
1.
Low level components are combined in clusters
that perform a specific software function.
2.
A driver (control program) is written to coordinate
test case input and output.
3.
The cluster is tested.
Drivers are removed and clusters are combined moving
upward in the program structure.
134
•Regression testing (check for defects propagated to other
modules by changes made to existing program)
1.
Representative sample of existing test cases is used to
exercise all software functions.
2.
Additional test cases focusing software functions
likely to be affected by the change.
3.
Tests cases that focus on the changed software
components.
•Smoke testing
1.
Software components already translated into code are
integrated into a build.
135
2.
A series of tests designed to expose errors that will
keep the build from performing its functions are created.
3.
The build is integrated with the other builds and the
entire product is smoke tested daily (either top-down or
bottom integration may be used).
General Software Test Criteria
•Interface integrity (internal and external module
interfaces are tested as each module or cluster is added to
the software)
Functional validity (test to uncover functional defects in
the software)
136
•Information content (test for errors in local or global data
structures)
•Performance (verify specified performance bounds are tested)
Validation Testing
•Ensure that each function or performance characteristic
conforms to its specification.
· Deviations (deficiencies) must be negotiated with the
customer to establish a means for resolving the errors.
137
· Configuration review or audit is used to ensure that all
elements of the software configuration have been
properly developed, cataloged, and documented to allow
its support during its maintenance phase.
Acceptance Testing
•Making sure the software works correctly for intended
user in his or her normal work environment.
•Alpha test (version of the complete software is tested by
customer under the supervision of the developer at the
developer抯 site)
Beta test (version of the complete software is tested by
customer at his or her own site without the developer
being present)
138
System Testing
•Recovery testing (checks the system抯 ability to recover from
failures)
•Security testing (verifies that system protection mechanism
prevent improper penetration or data alteration)
•Stress testing (program is checked to see how well it deals with
abnormal resource demands ?quantity, frequency, or volume)
•Performance testing (designed to test the run-time performance
of software, especially real-time software)
Debugging
139
•Some people are better at debugging than others.
•Common approaches:
1.
Brute force (memory dumps and run-time traces are
examined for clues to error causes)
2.
Backtracking (source code is examined by looking
backwards from symptom to potential causes of errors)
3.
Cause elimination (uses binary partitioning to
reduce the number of locations potential where errors can
exist)
140
•Debugging (removal of a defect) occurs as a consequence
of successful testing.
Bug Removal Considerations
•Is the cause of the bug reproduced in another part of the
program?
•What "next bug" might be introduced by the fix that is
being proposed?
What could have been done to prevent this bug in the first
place?
141
Chapter 19 Object-Oriented Concepts and Pricinples
Overview
This chapter provides an introduction to object-oriented
programming and management principles for objectoriented projects. Object-oriented software engineering
process is similar to that found in the rapid prototyping or
spiral paradigms. Even though, object-oriented software
engineering follows the same steps as the conventional
approach (analysis, design, implementation, and testing) it
is
142
harder to separate them into discrete activities.
The next 3 chapters deal with the topics of objectoriented analysis, object-oriented design, and
object-oriented testing.
Evolutionary Object-Oriented Process Model
•Customer communication
•Planning
Risk analysis
143
•Engineering construction and analysis
•Identify candidate classes
•Look-up classes in library
Extract classes if available
•Engineer classes if not available
144
oObject-oriented design (OOD)
oObject-oriented programming (OOP)
oObject-oriented analysis (OOA)
oObject-oriented testing (OOT)
•Put new classes in library
•Construct Nth iteration of the system
Customer evaluation
145
Object-Oriented Concepts
•Objects - encapsulates both data (attributes) and data
manipulation functions (called methods, operations, and
services)
•Class - generalized description (template or pattern) that
describes a collection of similar objects
•Superclass - a collection of objects
•Subclass - an instance of a class
•Class hierarchy - attributes and methods of a superclass are
inherited by its subclasses
146
•Messages - the means by which objects exchange
information with one another
•Inheritance - provides a means for allowing subclasses
to reuse existing superclass data and procedures; also
provides mechanism for propagating changes
•Polymorphism - a mechanism that allows several objects
in an class hierarchy to have different methods with the
same name (instances of each subclass will be free to
respond to messages by calling their own version of the
method)
Advantages of Object-Oriented Architectures
Implementation details of data and procedures and
hidden from the outside world (reduces the propagation
of side effects when changes are made).
147
•Data structures and operators are merged in single entity
or class (this facilitates reuse)
•Interfaces among encapsulated objects are simplified
(system coupling is reduced since object needs not be
concerned about the details of internal data structures)
Class Construction Options
•Build new class from scratch without using inheritance
148
•Use inheritance to create new class from existing class
contains most of the desired attributes and operations
•Restructure the class hierarchy so that the required
attributes and operations can be inherited by the newly
created class
Override some attributes or operations in an existing
class and use inheritance to create a new class with
(specialized) private versions of these attributes and
operations.
149
Chapter 20 Object-Oriented Analysis
Overview
This chapter describes the process of creating an objectoriented analysis (OOA) model for software
development projects. The OOA model is composed of
graphical or text-based representations that define class
attributes, relationships, behaviors, and inter-class
communication. OOA begins with scenario-based
descriptions (use cases) of how actors (people,
150
machines, systems) in the problem space interact with
the product to be built. Class-ResponsibilityCollaborator modeling translates use-case information
into representations of classes and their collaborations.
An object-relationship model can be built from the
collaborator network. The object-behavior model is
represented using a state transition diagram. The OOA
model needs to be reviewed for quality like any other
software engineering product.
151
OOA Tasks
1.
Basic user requirements must be communicated
between the customer and the software engineer.
2.
Classes must be identified (e.g. define attributes and
methods)
3.
Specify class hierarchy
4.
Represent object-to-object relationships
5.
Model object behavior
6.
Reapply 1 through 5 iteratively until model is
complete
152
OOA Generic Steps
•Elicit customer requirements for system
•Identify scenarios or use cases
•Select classes and objects using basic requirements
as a guide
Identify attributes and operations for each system
object
153
•Define structures and hierarchies that organize classes
•Build object-relationship model
•Build object-behavior model
•Review OOA model against use-cases (scenarios)
Unified Modeling Language Perspectives
154
•User model view (describes usage scenarios from the
end-user's perspective)
•Structural model view (static structure of data and
functionality is modeled - classes, object, relationships)
•Behavioral model view (represents dynamic system
aspects - interactions or collaborations between structural
elements in the user and structural models)
•Implementation model view (representing the structural
and behavioral aspects of the system as they are to be
built)
Environment model view (representation of the structural
and behavioral aspects of the environment in which the
system will be implemented)
155
Domain Analysis Activities
•Define the domain to be investigated
•Categorize the items extracted from the domain
•Collect a representative sample of applications in the domain
•Analyze each application in the sample
•Identify candidate reusable objects
•Indicate reasons the objects may be reused
156
•Define adaptations of the objects that may be reused
•Estimate percentage of applications in the domain
that might make reuse of the objects
•Identify objects by name and use configuration
management techniques to control them
•Develop an analysis model for the objects
OOA Model Generic Components
Static view of semantic classes (classes based on
semantics of customer requirements)
157
•Static view of attributes (attributes describe classes and
suggest operations relevant to classes)
•Static view of relationships (represent relationships in a
way that allows identification of operations and the
design of a messaging approach)
•Static view of behaviors (behaviors accommodating
system usage scenarios implemented by sequences of
operations)
•Dynamic view of communication (among objects based
on events that cause state transitions)
158
•Dynamic view of control and time (describe the nature
and timing of events causing state transitions)
Use Case Objectives
•Define the functional and operational requirements of
system by defining a scenario of usage agreed upon by the
end-user and software engineer
•Provide an unambiguous description of how the end-user
and system interact with one another
Provide a basis for validation testing
159
Class-Responsibility-Collaborator (CRC) Modeling
•Develop a set of index cards that represent the system
classes
•One class per card
•Cards are divide into three sections (class name, class
responsibilities, class collaborators)
•Once a complete CRC card set is developed it is
reviewed examining the usage scenarios
160
Criteria for Inclusion of a Class on a CRC Card
•Class information should be retained
•Provides needed services
•Contains multiple attributes
•Common set of attributes apply to all object
occurrences
•Common set of operations apply to all object
occurrences
External entities that produce or consume
information
161
Allocating Responsibilities to Classes
•Distribute system intelligence evenly
•State each responsibility as generally as possible
•Information and its related behaviors should reside within
the same class
•Localize all information about one thing in a single class
•Share responsibilities among related classes when
appropriate
162
Collaborators
•Any time a class cannot fulfill a responsibility
on its own it needs to interact with another class
•A server object interacts with a client object to
fulfill some responsibility
Reviewing CRC Models
•Each review participant is given a subset of the
CRC cards (collaborating cards must be
separated)
All use-case scenarios and use-case diagrams
should be organized into categories
163
Review leader chooses a use-case scenario and begins
reading it out loud
·
· Each time a named object is read a token is passed to
the reviewer holding the object's card
· When the reviewer receives the token, he or she is
asked to describe the responsibilities listed on the card
· The group determines whether one of the
responsibilities on the card satisfy the use-case
requirement or not
164
·If the responsibilities and collaborations on the
index card cannot accommodate the use-case
requirements then modifications need to be made
to the card set
Deriving the Object-Relationship Model
•Using the CRC model a network of collaborators
can be drawn
Reviewing the CRC model index card,
responsibilities and collaborators are evaluated,
each unlabeled connected line is named
165
•Once the named relationships are established each end is
evaluated to determine cardinality (0 to 1, 1 to 1, 0 to many,
1 to many)
•Continue the process until a complete object-relationship
model has been produced
Object-Behavior Model Construction
166
•Evaluate all use-cases to understand the sequence of
interaction within the system
•Identify events that drive the interaction sequence
and how events relate to specific objects
•Create an event-trace for each use-case
•Build a state transition diagram for the system
Review the object behavior model to verify accuracy
and consistency
167
Chapter 21 Object-Oriented Design
Overview
This chapter discusses the steps required to develop an
object-oriented software design from an object-oriented
analysis model. Object-oriented design (OOD) is divided
into two major activities: system design and object design.
System design defines the product architecture (the
system functions and classes encapsulated in the
subsystems). System design focuses on the specification
of three components: the user interface, data management
functions, and task management facilities. Object design
focuses on the internal details of the individual classes
and the messaging scheme.
168
The design specification document form the SEPA
web site is applicable to OOD. The OOD projects
must be reviewed to ensure quality.
Object-Oriented Design Layers
Responsibilities layer (highest layer - contains data
structure detail and algorithmic detail for each
object's attributes and operations)
169
•Message layer (establishes the internal and external
interfaces for the system, including the details of
communication among object collaborators)
•Class and object layer (contains class hierarchy including
representations of each object)
•Subsystem layer (lowest level - contains representations of
each of the subsystems and the necessary infrastructure that
enable the software to achieve the customer's requirements)
Object-oriented Design Issues
•Decomposability - facility of design method that allows the
designer to decompose the problem into easily solved
subproblems
170
•Composability - degree to which design method ensures
that modules constructed for one project can be reused in
another
•Understandablity - ease with which a component can be
understood without examining other components
•Continuity - ability to isolate changes made in one
module and restrict the propagation of changes to other
modules
•Protection - architectural characteristic that reduces the
propagation of side effects when errors occur
Generic Object-Oriented Design Steps
Describe each subsystem and allocate it to processors and
tasks
171
•Choose a design strategy for implementing data
management, interface support, and task management
•Design an appropriate system control mechanism
•Perform object design by creating a procedural
representation for each operation and data structures for
each attribute
•Perform message design using collaborations between
objects and object-relationships
•Create a messaging model
172
•Review the design model and iterate as required
Unified Approach to Object-Oriented Design
System design - UML (unified modeling language)
design activity that focuses on software
architecture and definition of subsystems
•Object design - UML design activity that focuses
on describing object and their interactions at a
level of detail that will allow them to be
implemented in some programming language
173
Object-Oriented System Design Process
•Partition the analysis model into subsystems
•subsystems should have well defined communication
interfaces
•with few exceptions classes should collaborate within their
subsystem
•keep number of subsystems small
•partition subsystem internally to reduce complexity
•Identify concurrency dictated by the problem
174
•Allocate subsystems to processors and tasks
•allocate each subsystem to an independent processor (or)
•allocate subsystems to same processor and provide
concurrency support through operating system features
•Develop user interface design
•Choose basic strategy for implementing data management
•management of data critical to the application itself
•creation of infrastructure for storage and retrieval of objects
Identify global resources and control mechanisms to access
them
175
•Design control mechanism for system (including task
management)
•Consider how subsystem boundary conditions should be
handled
•list each request (contract) that can be made by subsystem
collaborators
•for each contract note the operations required to
implement the responsibilities implied by the contract
•for each contract create a table with these entries: type,
collaborators, class, operation, message format
176
•if subsystem interaction modes are complex create a
subsystem-collaboration diagram
•Review and consider trade-offs
Object Design Process
•Object descriptions
•protocol description - object interface specified by
defining each message an object can receive and the
operation triggered by message (or)
implementation description - shows implementation
details for each operation implied a message passed to
the object
177
•Designing algorithms and data structures
•algorithm categories: data manipulation, computation,
monitors
•refinement of operation programs defined during OOA
•Design optimization
•review object-relationship model to ensure implemented
design leads to efficient resource utilization, add redundancy
where necessary
•revise attribute data structures and related operation
algorithms to improve processing efficiency
178
•Modularity is important aspect of object-oriented
design quality (the program design language should
support object definition)
•create attributes to save derived information and
avoid recomputation
Design Pattern Specification Components
•Name
•Intent
Design forces motivating the pattern
179
•Solution that mitigates these design forces
•Classes required to implement the solution
•Responsibilities and collaborations among the solution
classes
•Implementation suggestions
•Source code examples or templates
180
•Cross-references to related design patterns
Using Design Patterns in Object-Oriented Design
•Inheritance - makes use of an existing design pattern to
create a template for a new subclass
Composition - assembling complex objects or subsystems
out of selected design patterns using only interface
information
181
Chapter 22 Object-Oriented Testing
Overview
This chapter discusses the testing of object-oriented systems.
The process of testing object-oriented systems begins with a
review of the object-oriented analysis and design models.
Once the code is written object-oriented testing (OOT)
begins by testing "in the small" with class testing (class
operations and collaborations). As classes are integrated to
become subsystems class collaboration problems are
investigated. Finally, use-cases from the OOA model are
used to uncover software validation errors. OOT similar to
testing conventional software in that test cases are developed
to exercise the classes, their collaborations, and behavior.
OOT differs from conventional software
182
testing in that more emphasis is placed assessing the
completeness and consistency of the OOA and OOD
models as they are built. OOT tends to focus more on
integration problems than on unit testing. The test
plan specification template from the SEPA web site
is applicable to object-oriented testing as well.
Object-Oriented Testing Activities
•Review OOA and OOD models
Class testing after code is written
183
•Integration testing within subsystems
•Integration testing as subsystems are added to the system
•Validation testing based on OOA use-cases
Testing OOA and OOD Models
•Correctness of OOA and OOD models
•syntactic correctness judged by ensuring that proper modeling conventions and symbolism have been
used
•semantic correctness based on the model's conformance to the real world problem domain
184
•Consistency of OOA and OOD models
•assess the class-responsibility-collaborator (CRC) model
and object-relationship diagram
•review system design (examine the object-behavior model
to check mapping of system behavior to subsystems, review
concurrency and task allocation, use use-case scenarios to
exercise user interface design)
•test object model against the object relationship network to
ensure that all design object contain necessary attributes and
operations needed to implement the collaborations defined
for each CRC card
review detailed specifications of algorithms used to
implement operations using conventional inspection
techniques
185
Assessing the Class Model
1.
Revisit the CRC model and the object-relationship
model
2.
Inspect the description of each CRC card to
determine if a delegated responsibility is part of the
collaborator's definition
3.
Invert the connection to ensure that each
collaborator that is asked for service is receiving requests
from a responsible source
4.
Using the inverted connections from step 3,
determine whether other classes might be required or
whether responsibilities are properly grouped among
classes
186
5.
Determine whether widely requested
responsibilities might be combined into a single
responsibility
6.
Steps 1 to 5 are applied iteratively to each class
and through the evaluation of the OOA model
Object-Oriented Testing Strategies
•Unit testing in the OO context
smallest testable unit is the encapsulated class or
object
187
•similar to system testing of conventional software
•do not test operations in isolation from one another
•driven by class operations and state behavior, not
algorithmic detail and data flow across module interface
•Integration testing in the OO context
•focuses on groups of classes that collaborate or
communicate in some manner
•integration of operations one at a time into classes is
often meaningless
•thread-based testing (testing all classes required to
respond to one system input or event)
188
•use-based testing (begins by testing independent classes first
and the dependent classes that make use of them)
•cluster testing (groups of collaborating classes are tested for
interaction errors)
•regression testing is important as each thread, cluster, or
subsystem is added to the system
•Validation testing in the OO context
•focuses on visible user actions and user recognizable outputs
from the system
•validation tests are based on the use-case scenarios, the
object-behavior model, and the event flow diagram created in
the OOA model
conventional black-box testing methods can be used to drive
the validation tests
189
Test Case Design for OO Software
•Each test case should be uniquely identified and be explicitly associated with a class to be
tested
·
State the purpose of each test
·
List the testing steps for each test including:
·
list of states to test for each object involved in the test
•list of messages and operations to exercised as a consequence of the test
190
•list of exceptions that may occur as the object is tested
•list of external conditions needed to be changed for the
test
•supplementary information required to understand or
implement the test
OO Test Design Issues
•White-box testing methods can be applied to testing the
code used to implement class operations, but not much
else
Black-box testing methods are appropriate for testing OO
systems
191
•Fault-based testing
•best reserved for operations and the class level
•uses the inheritance structure
•tester examines the OOA model and hypothesizes a set of
plausible defects that may be encountered in operation
calls and message connections and builds appropriate test
cases
•misses incorrect specification and errors in subsystem
interactions
192
•Object-oriented programming brings additional testing
concerns
•classes may contain operations that are inherited from
super classes
•subclasses may contain operations that were redefined
rather than inherited
•all classes derived from an previously tested base class
need to be thoroughly tested
•Scenario-based testing
•using the user tasks described in the use-cases and
building the test cases from the tasks and their variants
193
•uncovers errors that occur when any actor interacts with the
OO software
•concentrates on what the use does, not what the product
does
you can get a higher return on your effort by spending more
time on reviewing the use-cases as they are created, than
spending more time on use-case testing
•Testing surface structure (exercising the structure
observable by end-user, this often involves observing and
interviewing users as they manipulate system objects)
•Testing deep structure (exercising internal program
structure - the dependencies, behaviors, and communications
mechanisms established as part of the system and object
design)
194
Class Level Testing Methods
•Random testing (requires large numbers data permutations and
combinations and can be inefficient)
•Partition testing (reduces the number of test cases required to
test a class)
•state-based partitioning (tests designed in way so that operations
that cause state changes are tested separately from those that do
not)
•attribute-based partitioning (for each class attribute, operations
are classified according to those that use the attribute, those that
modify the attribute, and those that do not use or modify the
attribute)
category-based partitioning (operations are categorized according
to the function they perform: initialization, computation, query,
termination)
195
Inter-Class Test Case Design
•Multiple class testing
•for each client class use the list of class operators to
generate random test sequences that send messages to other
server classes
•for each message generated determine the collaborator
class and the corresponding server object operator
•for each server class operator (invoked by a client object
message) determine the message it transmits
196
•for each message, determine the next level of operators that
are invoked and incorporate them into the test sequence
•Tests derived from behavior models
•test cases must cover all states in the state transition
diagram
breadth first traversal of the state model can be used (test
one transition at a time and only make use of previously
tested transitions when testing a new transition)
test cases can also be derived to ensure that all behaviors for
the class have been adequately exercised.
197