State Representations
21.6.2 State Representations
In the context of OO systems, two different characterizations of states must be con- sidered: (1) the state of each object as the system performs its function and (2) the state of the system as observed from the outside as the system performs its function.
The state of an object takes on both passive and active characteristics [CHA93]. A As you begin to
passive state is simply the current status of all of an object’s attributes. For example, identify states, focus
the passive state of the aggregate object player (in the video game application dis- on externally
cussed earlier) would include the current position and orientation attributes of player observable modes of
as well as other features of player that are relevant to the game (e.g., an attribute that behavior. Later, you
may refine these indicates magic wishes remaining). The active state of an object indicates the current sta- states into behaviors
tus of the object as it undergoes a continuing transformation or processing. The object that are not evident
player might have the following active states: moving, at rest, injured, being cured; from outside the
trapped, lost, and so forth. An event (sometimes called a trigger) must occur to force system.
an object to make a transition from one active state to another. One component of
Control representation
A Compare password = incorrect
panel of active state
Password entered
Compare password = incorrect Compare password = correct
"At rest"
"Comparing"
Control panel
"Selecting"
Activation successful
an object-behavior model is a simple representation of the active states for each object and the events (triggers) that cause changes between these active states. Fig- ure 21.9 illustrates a simple representation of active states for the control panel object in the SafeHome system.
Each arrow shown in Figure 21.9 represents a transition from one active state of an object to another. The labels shown for each arrow represent the event that trig- gers the transition. Although the active state model provides useful insight into the “life history” of an object, it is possible to specify additional information to provide more depth in understanding the behavior of an object. In addition to specifying the event that causes the transition to occur, the analyst can specify a guard and an action [CHA93]. A guard is a Boolean condition that must be satisfied in order for the tran- sition to occur. For example, the guard for the transition from the “at rest” state to the “comparing state” in Figure 21.9 can be determined by examining the use-case:
if (password input = 4 digits) then make transition to comparing state; In general, the guard for a transition usually depends upon the value of one or more
attributes of an object. In other words, the guard depends on the passive state of the object.
An action occurs concurrently with the state transition or as a consequence of it and generally involves one or more operations (responsibilities) of the object. For example, the action connected to the password entered event (Figure 21.9) is an oper- ation that accesses a password object and performs a digit-by-digit comparison to validate the entered password.
F I G U R E 21.10
Homeowner
Control panel
System
A partial event System ready trace for Safe-
Enters password
Home Initiates beep Beep sounded
Ready for activation/deactivation Selects stay/away
Activate/deactivate sensors Sensors activated/deactivated
Red light on request Red light on
Ready for next action
The second type of behavioral representation for OOA considers a state repre- sentation for the overall product or system. This representation encompasses a sim- ple event trace model [RUM91] that indicates how events cause transitions from object to object and a state transition diagram that depicts the processing behavior of each object.
Once events have been identified for a use-case, the analyst creates a represen-
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more