View
224
Download
4
Tags:
Embed Size (px)
Citation preview
1SWE311_Ch08 (071) Software & Software Engineering
Chapter 8Chapter 8Analysis ModelingAnalysis Modeling
2SWE311_Ch08 (071) Software & Software Engineering
Analysis Model ObjectivesAnalysis Model Objectives
Describe what the customer requires. Describe what the customer requires.
Establish a basis for the creation of a software design. Establish a basis for the creation of a software design.
Devise a set of requirements that can be validated once the Devise a set of requirements that can be validated once the software is built.software is built.
3SWE311_Ch08 (071) Software & Software Engineering
Analysis Model GuidelinesAnalysis Model Guidelines Analysis products must be highly maintainable, especially the software Analysis products must be highly maintainable, especially the software
requirements specification. requirements specification.
Problems of size must be dealt with using an effective method of Problems of size must be dealt with using an effective method of partitioning. partitioning.
Graphics should be used whenever possible. Graphics should be used whenever possible.
Differentiate between the logical (essential) and physical (implementation) Differentiate between the logical (essential) and physical (implementation) considerations. considerations.
Find something to help with requirements partitioning and document the Find something to help with requirements partitioning and document the partitioning before specification. partitioning before specification.
Devise a way to track and evaluate user interfaces. Devise a way to track and evaluate user interfaces.
Devise tools that describe logic and policy better than narrative text. Devise tools that describe logic and policy better than narrative text.
4SWE311_Ch08 (071) Software & Software Engineering
Requirements AnalysisRequirements Analysis Requirements analysis Requirements analysis
specifies software’s operational characteristicsspecifies software’s operational characteristics
indicates software's interface with other system elements indicates software's interface with other system elements
establishes constraints that software must meetestablishes constraints that software must meet
Requirements analysis allows the software engineer (called an Requirements analysis allows the software engineer (called an analystanalyst or or modelermodeler in this role) to: in this role) to: elaborate on basic requirements established during earlier requirement elaborate on basic requirements established during earlier requirement
engineering tasksengineering tasks
build models that depict user scenarios, functional activities, problem build models that depict user scenarios, functional activities, problem classes and their relationships, system and class behavior, and the flow classes and their relationships, system and class behavior, and the flow of data as it is transformed. of data as it is transformed.
5SWE311_Ch08 (071) Software & Software Engineering
A BridgeA Bridge
system description
analysis model
design model
6SWE311_Ch08 (071) Software & Software Engineering
Analysis Model Rules of ThumbAnalysis Model Rules of Thumb The model should focus on requirements that are visible The model should focus on requirements that are visible
within the problem or business domain. The level of within the problem or business domain. The level of abstraction should be relatively high. abstraction should be relatively high.
Each element of the analysis model should add to an overall Each element of the analysis model should add to an overall understanding of software requirements and provide insight understanding of software requirements and provide insight into the information domain, function and behavior of the into the information domain, function and behavior of the system.system.
Delay consideration of infrastructure and other non-Delay consideration of infrastructure and other non-functional models until design. functional models until design.
Minimize coupling throughout the system. Minimize coupling throughout the system. Be certain that the analysis model provides value to all Be certain that the analysis model provides value to all
stakeholders. stakeholders. Keep the model as simple as it can be. Keep the model as simple as it can be.
7SWE311_Ch08 (071) Software & Software Engineering
Object-Oriented ConceptsObject-Oriented Concepts
Must be understood to apply class-based elements of Must be understood to apply class-based elements of the analysis modelthe analysis model
Key concepts:Key concepts: Classes and objectsClasses and objects
Attributes and operationsAttributes and operations
Encapsulation and instantiationEncapsulation and instantiation
InheritanceInheritance
8SWE311_Ch08 (071) Software & Software Engineering
What is a Class?What is a Class?
external entities
things
occurrences roles
organizational units
places
structures
class name
attributes:
operations:
9SWE311_Ch08 (071) Software & Software Engineering
ClassesClasses• object-oriented thinking begins with the definition object-oriented thinking begins with the definition
of a of a class,class, often defined as: often defined as:– templatetemplate
– generalized descriptiongeneralized description
– “ “blueprint” ... describing a collection of similar itemsblueprint” ... describing a collection of similar items
• a a metaclassmetaclass (also called a (also called a superclasssuperclass) establishes a ) establishes a hierarchy of classeshierarchy of classes
• once a class of items is defined, a specific once a class of items is defined, a specific instance of the class can be identified instance of the class can be identified
10SWE311_Ch08 (071) Software & Software Engineering
Class DiagramsClass Diagrams
A class diagram defines the classes of objects in the system, A class diagram defines the classes of objects in the system, the attributes and operations of the classes, and the the attributes and operations of the classes, and the relationships between classes.relationships between classes.
11SWE311_Ch08 (071) Software & Software Engineering
ObjectsObjects
An object is a concept, abstraction, or thing with well-defined An object is a concept, abstraction, or thing with well-defined boundaries and meaning for an application. boundaries and meaning for an application.
An object represents an entity, either real-world or conceptual.An object represents an entity, either real-world or conceptual.
In the UML, an object is represented as a rectangle, and the In the UML, an object is represented as a rectangle, and the name of the object is underlined.name of the object is underlined.
Object Name
12SWE311_Ch08 (071) Software & Software Engineering
Building a ClassBuilding a Class
class name
attributes:
operations:
attributes:
operations
13SWE311_Ch08 (071) Software & Software Engineering
ClassesClasses
A class is a description of a group of objects with common A class is a description of a group of objects with common properties (attributes), and common behavior (operations).properties (attributes), and common behavior (operations).
In the UML, a class is represented as a compartmentalized In the UML, a class is represented as a compartmentalized rectangle.rectangle.
Class Name
Attributes
Operations
14SWE311_Ch08 (071) Software & Software Engineering
Encapsulation/HidingEncapsulation/HidingThe object encapsulatesboth data and the logicalprocedures required tomanipulate the data
Achieves “information hiding”
method # 1
data
method # 2
method # 4
method # 5
method # 6
method # 3
15SWE311_Ch08 (071) Software & Software Engineering
MethodsMethods(Operations, Services)(Operations, Services)
An executable procedure that is encapsulated in a class and is designed to operate on one or more data attributes that are defined as part of the class.A method is invoked via message passing.
16SWE311_Ch08 (071) Software & Software Engineering
Relationships between ClassesRelationships between Classes
AssociationAssociation
Aggregation and compositionAggregation and composition
Generalization/specializationGeneralization/specialization
17SWE311_Ch08 (071) Software & Software Engineering
Association between ClassesAssociation between Classes
An An associationassociation defines a relationship between two or more defines a relationship between two or more classes.classes. Example: Student Example: Student Works onWorks on CourseProject CourseProject
18SWE311_Ch08 (071) Software & Software Engineering
Multiplicity of AssociationsMultiplicity of Associations The The multiplicitymultiplicity of an association specifies how many of an association specifies how many
instances of one class may relate to a single instance of instances of one class may relate to a single instance of another class.another class.
Examples: one-to-one, one-to-many, many-to-many, Examples: one-to-one, one-to-many, many-to-many, numerically specified association, etc.numerically specified association, etc.
19SWE311_Ch08 (071) Software & Software Engineering
Association ClassesAssociation Classes An An association classassociation class is a class that models an association is a class that models an association
between two or more classes.between two or more classes.
It is most useful in many-to-many associations.It is most useful in many-to-many associations.
The attributes of the association class are the attributes of the The attributes of the association class are the attributes of the association.association.
20SWE311_Ch08 (071) Software & Software Engineering
Aggregation RelationshipsAggregation Relationships IS-PART-OF relationshipsIS-PART-OF relationships
21SWE311_Ch08 (071) Software & Software Engineering
Composition RelationshipsComposition Relationships Composition is a stronger type of aggregationComposition is a stronger type of aggregation
The The partpart objects are created, live, and die together with the objects are created, live, and die together with the whole.whole.
22SWE311_Ch08 (071) Software & Software Engineering
Generalization/Specialization RelationshipsGeneralization/Specialization Relationships
IS-A relationshipsIS-A relationships
23SWE311_Ch08 (071) Software & Software Engineering
Class HierarchyClass Hierarchy
ChairTable Desk ”Chable"
instances of Chair
PieceOfFurniture (superclass)
subclasses of the
24SWE311_Ch08 (071) Software & Software Engineering
Class-Based ModelingClass-Based Modeling
Identify analysis classes by examining the problem Identify analysis classes by examining the problem statementstatement
Use a “grammatical parse” to isolate potential classesUse a “grammatical parse” to isolate potential classes Identify the attributes of each classIdentify the attributes of each class Identify operations that manipulate the attributesIdentify operations that manipulate the attributes
25SWE311_Ch08 (071) Software & Software Engineering
Analysis ClassesAnalysis Classes External entitiesExternal entities (e.g., other systems, devices, people) that produce or consume (e.g., other systems, devices, people) that produce or consume
information to be used by a computer-based system.information to be used by a computer-based system. ThingsThings (e.g, reports, displays, letters, signals) that are part of the information (e.g, reports, displays, letters, signals) that are part of the information
domain for the problem.domain for the problem. Occurrences or eventsOccurrences or events (e.g., a property transfer or the completion of a series of (e.g., a property transfer or the completion of a series of
robot movements) that occur within the context of system operation.robot movements) that occur within the context of system operation. RolesRoles (e.g., manager, engineer, salesperson) played by people who interact with (e.g., manager, engineer, salesperson) played by people who interact with
the system.the system. Organizational unitsOrganizational units (e.g., division, group, team) that are relevant to an (e.g., division, group, team) that are relevant to an
application.application. PlacesPlaces (e.g., manufacturing floor or loading dock) that establish the context of the (e.g., manufacturing floor or loading dock) that establish the context of the
problem and the overall function of the system.problem and the overall function of the system. StructuresStructures (e.g., sensors, four-wheeled vehicles, or computers) that define a class (e.g., sensors, four-wheeled vehicles, or computers) that define a class
of objects or related classes of objects.of objects or related classes of objects.
26SWE311_Ch08 (071) Software & Software Engineering
Selecting Classes—CriteriaSelecting Classes—Criteria
needed servicesneeded services
multiple attributesmultiple attributes
common attributescommon attributes
common operationscommon operations
essential requirementsessential requirements
retained informationretained information
27SWE311_Ch08 (071) Software & Software Engineering
Class DiagramClass DiagramSystem
program() display() reset() query() modify() call()
systemID verificationPhoneNumber systemStatus delayTime telephoneNumber masterPassword temporaryPassword numberTries
Class name
attributes
operations
28SWE311_Ch08 (071) Software & Software Engineering
Class DiagramClass DiagramFloorPlan
determineType () positionFloorplan scale() change color()
type name outsideDimensions
Camera
determineType () translateLocation () displayID() displayView() displayZoom()
type ID location fieldView panAngle ZoomSetting
WallSegment
type startCoordinates stopCoordinates nextWallSement
determineType () draw()
Window
type startCoordinates stopCoordinates nextWindow
determineType () draw()
is placed within
Wall
type wallDimensions
determineType () computeDimensions ()
Door
type startCoordinates stopCoordinates nextDoor
determineType () draw()
is part of
is used to buildis used to build
is used to build
29SWE311_Ch08 (071) Software & Software Engineering
Class TypesClass Types Entity classesEntity classes, also called, also called model model or or businessbusiness classes, are extracted classes, are extracted
directly from the statement of the problem (e.g., FloorPlan and Sensor). directly from the statement of the problem (e.g., FloorPlan and Sensor).
Boundary classesBoundary classes are used to create the interface (e.g., interactive are used to create the interface (e.g., interactive screen or printed reports) that the user sees and interacts with as the screen or printed reports) that the user sees and interacts with as the software is used. software is used.
Controller classesController classes manage a “unit of work” [UML03] from start to manage a “unit of work” [UML03] from start to finish. That is, controller classes can be designed to manage finish. That is, controller classes can be designed to manage
the creation or update of entity objects; the creation or update of entity objects;
the instantiation of boundary objects as they obtain information from entity the instantiation of boundary objects as they obtain information from entity objects; objects;
complex communication between sets of objects; complex communication between sets of objects;
validation of data communicated between objects or between the user and validation of data communicated between objects or between the user and the application. the application.
30SWE311_Ch08 (071) Software & Software Engineering
ResponsibilitiesResponsibilities
System intelligence should be distributed across classes to best System intelligence should be distributed across classes to best address the needs of the problemaddress the needs of the problem
Each responsibility should be stated as generally as possibleEach responsibility should be stated as generally as possible
Information and the behavior related to it should reside within Information and the behavior related to it should reside within the same classthe same class
Information about one thing should be localized with a single Information about one thing should be localized with a single class, not distributed across multiple classes.class, not distributed across multiple classes.
Responsibilities should be shared among related classes, when Responsibilities should be shared among related classes, when appropriate. appropriate.
31SWE311_Ch08 (071) Software & Software Engineering
Example: Class DiagramExample: Class Diagram
32SWE311_Ch08 (071) Software & Software Engineering
Scenario-Based ModelingScenario-Based Modeling
““[Use-cases] are simply an aid to defining what [Use-cases] are simply an aid to defining what exists outside the system (actors) and what exists outside the system (actors) and what should be performed by the system (use-cases).” should be performed by the system (use-cases).” Ivar JacobsonIvar Jacobson
(1) What should we write about?(1) What should we write about?
(2) How much should we write about it?(2) How much should we write about it?
(3) How detailed should we make our description? (3) How detailed should we make our description?
(4) How should we organize the description?(4) How should we organize the description?
33SWE311_Ch08 (071) Software & Software Engineering
Use-Use-CasesCases
a scenario that describes a “thread of a scenario that describes a “thread of usage” for a systemusage” for a system
actorsactors represent roles people or devices represent roles people or devices play as the system functionsplay as the system functions
usersusers can play a number of different roles can play a number of different roles for a given scenariofor a given scenario
34SWE311_Ch08 (071) Software & Software Engineering
Developing a Use-CaseDeveloping a Use-Case
What are the main tasks or functions that are What are the main tasks or functions that are performed by the actor?performed by the actor?
What system information will the the actor acquire, What system information will the the actor acquire, produce or change?produce or change?
Will the actor have to inform the system about Will the actor have to inform the system about changes in the external environment?changes in the external environment?
What information does the actor desire from the What information does the actor desire from the system?system?
Does the actor wish to be informed about unexpected Does the actor wish to be informed about unexpected changes?changes?
35SWE311_Ch08 (071) Software & Software Engineering
Use-Case DiagramUse-Case Diagram
homeowner
Access camera surveillance via the
Internet
Configure SafeHome system parameters
Set alarm
cameras
SafeHome
36SWE311_Ch08 (071) Software & Software Engineering
Activity DiagramActivity DiagramSupplements the use-case by providing a diagrammatic representation Supplements the use-case by providing a diagrammatic representation of procedural flowof procedural flow
enter password and user ID
select major function
valid passwords/ ID
prompt for reentry
invalid passwords/ ID
input tries remain
no inputtries remain
select surveillance
other functions may also be
selected
thumbnail views select a specif ic camera
select camera icon
prompt for another view
select specific camera - thumbnails
exit this function see another camera
view camera output in labelled window
37SWE311_Ch08 (071) Software & Software Engineering
Swimlane DiagramsSwimlane Diagrams
Allows the modeler to Allows the modeler to represent the flow of represent the flow of activities described by the activities described by the use-case and at the same time use-case and at the same time indicate which actor (if there indicate which actor (if there are multiple actors involved are multiple actors involved in a specific use-case) or in a specific use-case) or analysis class has analysis class has responsibility for the action responsibility for the action described by an activity described by an activity rectanglerectangle
enter password and user ID
select major function
valid passwords/ ID
prompt for reentry
invalidpasswords/ ID
input tries
remain
no input
tries remain
select surveillance
other functions may also be
selected
thumbnail views select a specif ic camera
select camera icon
generate video output
select specific camera - thumbnails
exit thisfunction
see
anothercamera
homeowner c amera int erf ac e
prompt foranother view
view camera output in labelled window
38SWE311_Ch08 (071) Software & Software Engineering
Class-Responsibility-Collaborator Class-Responsibility-Collaborator (CRC) Modeling(CRC) Modeling
Analysis classes have “responsibilities”Analysis classes have “responsibilities” ResponsibilitiesResponsibilities are the attributes and operations encapsulated by the are the attributes and operations encapsulated by the
classclass
Analysis classes collaborate with one anotherAnalysis classes collaborate with one another CollaboratorsCollaborators are those classes that are required to provide a class are those classes that are required to provide a class
with the information needed to complete a responsibility. with the information needed to complete a responsibility. In general, a collaboration implies either a request for information or a In general, a collaboration implies either a request for information or a
request for some action.request for some action.
39SWE311_Ch08 (071) Software & Software Engineering
CRC ModelingCRC Modeling
Class:
Description:
Responsibility: Collaborator:
Class:
Description:
Responsibility: Collaborator:
Class:
Description:
Responsibility: Collaborator:
Class: FloorPlan
Description:
Responsibility: Collaborator:
incorporates walls, doors and windows
shows position of video cameras
defines floor plan name/type
manages floor plan positioning
scales floor plan for display
scales floor plan for display
Wall
Camera
40SWE311_Ch08 (071) Software & Software Engineering
Reviewing the CRC ModelReviewing the CRC Model All participants in the review (of the CRC model) are given a subset of the CRC model index All participants in the review (of the CRC model) are given a subset of the CRC model index
cards.cards.
Cards that collaborate should be separated (i.e., no reviewer should have two cards that Cards that collaborate should be separated (i.e., no reviewer should have two cards that collaborate).collaborate).
All use-case scenarios (and corresponding use-case diagrams) should be organized into All use-case scenarios (and corresponding use-case diagrams) should be organized into categoriescategories..
The review leader reads the use-case deliberatelyThe review leader reads the use-case deliberately.. As the review leader comes to a named object, she passes a token to the person holding As the review leader comes to a named object, she passes a token to the person holding
the corresponding class index card.the corresponding class index card. When the token is passed, the holder of the class card is asked to describe the responsibilities When the token is passed, the holder of the class card is asked to describe the responsibilities
noted on the cardnoted on the card.. The group determines whether one (or more) of the responsibilities satisfies the use-case The group determines whether one (or more) of the responsibilities satisfies the use-case
requirement.requirement. If the responsibilities and collaborations noted on the index cards cannot accommodate the use-If the responsibilities and collaborations noted on the index cards cannot accommodate the use-
case, modifications are made to the cardscase, modifications are made to the cards.. This may include the definition of new classes (and corresponding CRC index cards) or This may include the definition of new classes (and corresponding CRC index cards) or
the specification of new or revised responsibilities or collaborations on existing cards.the specification of new or revised responsibilities or collaborations on existing cards.
41SWE311_Ch08 (071) Software & Software Engineering
Analysis PackagesAnalysis Packages
Various elements of the analysis model (e.g., use-cases, analysis classes) Various elements of the analysis model (e.g., use-cases, analysis classes) are categorized in a manner that packages them as a groupingare categorized in a manner that packages them as a grouping
The plus sign preceding the analysis class name in each package indicates The plus sign preceding the analysis class name in each package indicates that the classes have public visibility and are therefore accessible from that the classes have public visibility and are therefore accessible from other packages.other packages.
Other symbols can precede an element within a package. Other symbols can precede an element within a package. A minus sign indicates that an element is hidden from all other packages A minus sign indicates that an element is hidden from all other packages
and and a # symbol indicates that an element is accessible only to packages a # symbol indicates that an element is accessible only to packages
contained within a given package.contained within a given package.
42SWE311_Ch08 (071) Software & Software Engineering
Analysis PackagesAnalysis Packages
Environment
+Tree+Landscape+Road+Wall+Bridge+Building+VisualEffect+Scene
Characters
+Player+Protagonist+Antagonist+SupportingRole
RulesOfTheGame
+RulesOfMovement+ConstraintsOnAction
package name
43SWE311_Ch08 (071) Software & Software Engineering
Behavioral ModelingBehavioral Modeling
The behavioral model indicates how software will respond to external The behavioral model indicates how software will respond to external events or stimuli. To create the model, the analyst must perform the events or stimuli. To create the model, the analyst must perform the following steps:following steps:
Evaluate all use-cases to fully understand the sequence of interaction within the Evaluate all use-cases to fully understand the sequence of interaction within the system.system.
Identify events that drive the interaction sequence and understand how these events Identify events that drive the interaction sequence and understand how these events relate to specific objects.relate to specific objects.
Create a sequence for each use-case.Create a sequence for each use-case.
Build a state diagram for the system.Build a state diagram for the system.
Review the behavioral model to verify accuracy and consistency.Review the behavioral model to verify accuracy and consistency.
44SWE311_Ch08 (071) Software & Software Engineering
State RepresentationsState Representations
In the context of behavioral modeling, two different In the context of behavioral modeling, two different characterizations of states must be considered: characterizations of states must be considered: the state of each class as the system performs its function andthe state of each class as the system performs its function and the state of the system as observed from the outside as the system the state of the system as observed from the outside as the system
performs its functionperforms its function
The state of a class takes on both passive and active The state of a class takes on both passive and active characteristics [CHA93]. characteristics [CHA93]. A A passive statepassive state is simply the current status of all of an object’s is simply the current status of all of an object’s
attributes.attributes. The The active stateactive state of an object indicates the current status of the object as of an object indicates the current status of the object as
it undergoes a continuing transformation or processing. it undergoes a continuing transformation or processing.
45SWE311_Ch08 (071) Software & Software Engineering
State Diagram for the ControlPanel ClassState Diagram for the ControlPanel Class
reading
locked
selecting
password entered
comparing
password = incorrect & numberOfTries < maxTries
password = correct
activation successful
key hit
do: validatePassword
numberOfTries > maxTries
timer < lockedTime
timer > lockedTime
46SWE311_Ch08 (071) Software & Software Engineering
The States of a SystemThe States of a System statestate—a set of observable circum-stances —a set of observable circum-stances
that characterizes the behavior of a system at that characterizes the behavior of a system at a given timea given time
state transitionstate transition—the movement from one —the movement from one state to anotherstate to another
eventevent—an occurrence that causes the system —an occurrence that causes the system to exhibit some predictable form of behaviorto exhibit some predictable form of behavior
actionaction—process that occurs as a consequence —process that occurs as a consequence of making a transitionof making a transition
47SWE311_Ch08 (071) Software & Software Engineering
Behavioral ModelingBehavioral Modeling
make a list of the different states of a system make a list of the different states of a system (How does the system behave?)(How does the system behave?)
indicate how the system makes a transition from indicate how the system makes a transition from one state to another (How does the system one state to another (How does the system change state?)change state?) indicate eventindicate event
indicate actionindicate action
draw a draw a state diagram or a sequence diagramstate diagram or a sequence diagram
48SWE311_Ch08 (071) Software & Software Engineering
Sequence DiagramSequence Diagram
homeowner control panel sensorssystem sensors
system ready
reading
request lookupcomparing
result
password entered
password = correctrequest activation
activation successful
lockednumberOfTries > maxTries
selecting
timer > lockedTimeA
A
Figure 8.27 Sequence diagram (partial) for SafeHome security function
activation successful
49SWE311_Ch08 (071) Software & Software Engineering
Writing the Software SpecificationWriting the Software Specification
Everyone knew exactly what had to be done until someone wrote it down!
50SWE311_Ch08 (071) Software & Software Engineering
Specification GuidelinesSpecification Guidelinesuse a layered format that provides increasing detail as the "layers" deepen use consistent graphical notation and apply textual terms consistently (stay away from aliases) be sure to define all acronyms be sure to include a table of contents; ideally, include an index and/or a glossary write in a simple, unambiguous style (see "editing suggestions" on the following pages) always put yourself in the reader's position, "Would I be able to understand this if I wasn't intimately familiar with the system?"
51SWE311_Ch08 (071) Software & Software Engineering
Specification GuidelinesSpecification GuidelinesBe on the lookout for persuasive connectors, ask why? keys: certainly, therefore, clearly, obviously, it follows that ... Watch out for vague terms keys: some, sometimes, often, usually,ordinarily, most, mostly ... When lists are given, but not completed, be sure all items are understood keys: etc., and so forth, and so on, such as Be sure stated ranges don't contain unstated assumptions e.g., Valid codes range from 10 to 100. Integer? Real? Hex? Beware of vague verbs such as handled, rejected, processed, ... Beware "passive voice" statements e.g., The parameters are initialized. By what? Beware "dangling" pronouns e.g., The I/O module communicated with the data validation module and its contol flag is set. Whose control flag?
52SWE311_Ch08 (071) Software & Software Engineering
Specification GuidelinesSpecification Guidelines
When a term is explicitly defined in one place, try substituting the definition forother occurrences of the term When a structure is described in words, draw a picture When a structure is described with a picture, try to redraw the picture to emphasize different elements of the structure When symbolic equations are used, try expressing their meaning in words When a calculation is specified, work at least two examples Look for statements that imply certainty, then ask for proof keys; always, every, all, none, never Search behind certainty statements—be sure restrictions or limitations are realistic