CS616 – Software Engineering II

Lecture 1

Object-oriented Software Engineering

Evolutionary Object-Oriented Process Model

Advantages of Object-Oriented Architectures

Class Construction Options

 

Object-Oriented Concepts

Identifying the Elements of an Object Model

Objects can be:

Example: Defining objects during the early stages of analysis - SafeHome system

Input:

SafeHome software enables the homeowner to configure the security system when it is installed, monitors all sensors connected to the security system, and interacts with the homeowner through a keypad and function keys contained in the SafeHome control panel.

During installation, the SafeHome control panel is used to "program" and configure the system. Each sensor is assigned a number and type, a master password is programmed for arming and disarming the system, and telephone number(s) are input for dialing when a sensor event occurs.

When a sensor event is sensed by the software, it rings an audible alarm attached to the system. After a delay time that is specified by the homeowner during system configuration activities, the software dials a telephone number of a monitoring service, provides information about the location, reporting and the nature of the event that has been detected. The number will be redialed every 20 seconds until telephone connection is obtained.

All interaction with SafeHome is managed by a user-interaction subsystem that reads input provided through the keypad and function keys, displays prompting messages on the LCD display, displays system status information on the LCD display. Keyboard interaction takes the following form . . .

 

Output:

SafeHome software enables the homeowner to configure the security system when it is installed, monitors all sensors connected to the security system, and interacts with the homeowner through a keypad and function keys contained in the SafeHome control panel.

During installation, the SafeHome control panel is used to "program" and configure the system. Each sensor is assigned a number and type, a master password is programmed for arming and disarming the system, and telephone number(s) are input for dialing when a sensor event occurs.

When a sensor event is recognized, the software invokes an audible alarm attached to the system. After a delay time that is specified by the homeowner during system configuration activities, the software dials a telephone number of a monitoring service, provides information about the location, reporting the nature of the event that has been detected. The telephone number will be redialed every 20 seconds until telephone connection is obtained.

All interaction with SafeHome is managed by a user-interaction subsystem that reads input provided through the keypad and function keys, displays prompting messages on the LCD display, displays system status information on the LCD display. Keyboard interaction takes the following form . . .

 

       All verbs are SafeHome processes

       All nouns are either external entities , data or control objects , or data stores

       Nouns and verbs can be attached to one another

 

       Extracting the nouns, creates a number of potential objects:

 

Potential Object/Class

General Classification

homeowner

role or external entity

sensor

external entity

control panel

external entity

installation

occurrence

system (alias security system)

thing

number, type

not objects, attributes of sensor

master password

thing

telephone number

thing

sensor event

occurrence

audible alarm

external entity

monitoring service

organizational unit or external entity

 

       Selection characteristics that should be used when considering each potential object for inclusion in the analysis model:

1.     Retained information. The potential object will be useful during analysis only if information about it must be remembered so that the system can function.

2.     Needed services. The potential object must have a set of identifiable operations that can change the value of its attributes in some way.

3.     Multiple attributes. During requirement analysis, the focus should be on "major" information; an object with a single attribute may, in fact, be useful during design, but is probably better represented as an attribute of another object during the analysis activity.

4.     Common attributes. A set of attributes can be defined for the potential object and these attributes apply to all occurrences of the object.

5.     Common operations. A set of operations can be defined for the potential object and these operations apply to all occurrences of the object.

6.     Essential requirements. External entities that appear in the problem space and produce or consume information essential to the operation of any solution for the system will almost always be defined as objects in the requirements model

       To be a legitimate object for inclusion in the requirements model, a potential object should satisfy all (or almost all) of these characteristics.

       The decision for inclusion of potential objects in the analysis model is somewhat subjective

       Applying these selection characteristics to the list of potential SafeHome objects gives :

 

Potential Object/Class

Characteristic Number That Applies

homeowner

rejected: 1, 2 fail even though 6 applies

sensor

accepted: all apply

control panel

accepted: all apply

installation

rejected

system (alias security system)

accepted: all apply

number, type

rejected: 3 fails, attributes of sensor

master password

rejected: 3 fails

telephone number

rejected: 3 fails

sensor event

accepted: all apply

audible alarm

accepted: 2, 3, 4, 5, 6 apply

monitoring service

rejected: 1, 2 fail even though 6 applies

 

Specifying Attributes

       Attributes describe an object that has been selected for inclusion in the analysis model. In essence, it is the attributes that define the object—that clarify what is meant by the object in the context of the problem space.

       To determine object attributes:

o      Study the processing narrative (or statement of scope) for the problem and select those things that reasonably "belong" to the object.

o      Answer the following question for each object: "What data items (composite and/or elementary) fully define this object in the context of the problem at hand?"

 

Defining Operations

o      Operations change one or more attribute values that are contained within an object.

o      Three categories of objects:

(1)  operations that manipulate data in some way (e.g., adding, deleting, reformatting, selecting)

(2)  operations that perform a computation

(3)  operations that monitor an object for the occurrence of a controlling event.

o      To derive a set of operations for the objects of the analysis model, study the processing narrative (or statement of scope) for the problem and select those operations that reasonably belong to the object.

o      Study the grammatical parse again to isolate verbs.

o      Some verbs will be legitimate operations and can be easily connected to a specific object.

o      e.g. from SafeHome processing narrative –

        "sensor is assigned a number and type"

       "a master password is programmed for arming and disarming the system."

o      These two phrases indicate a number of things:

       An assign operation is relevant for the sensor object.

       A program operation will be applied to the system object.

o      Also consider communication between objects.

Finalizing the Object Definition

       Definition of operations is the last step in completing the specification of an object.

       Generic life history of an object can be defined by recognizing that the object must be created, modified, manipulated or read in other ways, and possibly deleted.

       Some of the operations can be ascertained from likely communication between objects.

o      e.g.

       sensor event will send a message to system to display the event location and number

       control panel will send system a reset message to update system status

       audible alarm will send a query message

       control panel will send a modify message to change one or more attributes without reconfiguring the entire system object;

       sensor event will also send a message to call the phone number(s) contained in the object.

       Final Result

 

 

Management of Object-Oriented Software Projects

Modern software project management can be subdivided into the following activities:

(1)  Establishing a common process framework for a project.

(2)  Using the framework and historical metrics to develop effort and time estimates.

(3)  Establishing deliverables and milestones that will enable progress to be measured.

(4)  Defining checkpoints for risk management, quality assurance, and control.

(5)  Managing the changes that invariably occur as the project progresses.

(6)  Tracking, monitoring, and controlling progress.

 

The Common Process Framework for OO

       A common process framework defines an organization's approach to software engineering.

       It identifies the paradigm that is applied to build and maintain software and the tasks, milestones, and deliverables that will be required.

       It establishes the degree of rigor with which different kinds of projects will be approached.

       The CPF is always adaptable so it can meet the individual needs of a project team.

       Object-oriented software engineering applies a process model that encourages iterative development

 

Berard and Booch’s recursive/parallel model for object-oriented software development.

 

Recursive/parallel model:

  1. Similar to the spiral or evolutionary paradigm: Progress occurs iteratively.
  2. The differences in the recursive/parallel model are:

(1)  Systematically decompose the problem into highly independent components.

(2)  Reapply the decomposition process to each of the independent components to decompose each further (the recursive part).

(3)  Conduct this reapplication of decomposition concurrently on all components (the parallel part).

(4)  Continue this process until completion criteria are attained.

(5)  Note:  decomposition process is discontinued if the analyst/designer recognizes that the component or subcomponent is available in a reuse library.

  1. Project manager must recognize:

 

OO Project Metrics and Estimation

 

o       Each script is organized into triplets of the form {initiator, action, participant} where:

 

An OO Estimating and Scheduling Approach

(1)  Develop estimates using effort decomposition, FP analysis, and any other method that is applicable for conventional applications.

(2)  Using OOA develop scenario scripts (use-cases) and determine a count. Recognize that the number of scenario scripts may change as the project progresses.

(3)  Using OOA, determine the number of key classes.

(4)   Categorize the type of interface for the application and develop a multiplier for support classes:

Interface type

Multiplier

No GUI

2.0

Text-based user interface

2.25

GUI

2.5

Complex GUI

3.0

Multiply the number of key classes (step 3) by the multiplier to obtain an estimate for the number of support classes.

(5)  Multiply the total number of classes (key + support) by the average number of work-units per class. Lorenz and Kidd suggest 15 to 20 person-days per class.

(6)   Cross check the class-based estimate by multiplying the average number of work-units per scenario script.

Tracking Progress for an OO Project

 

Technical milestone: OO analysis completed

 

Technical milestone: OO design completed

 

Technical milestone: OO programming completed

 

Technical milestone: OO testing

 

Object-Oriented Analysis

Conventional vs. OO Approaches

1.     Identification/classification of entities

2.     General-to-specific and whole-to-part entity relationships

3.     Other entity relationships

4.     Description of attributes of entities

5.     Large-scale model partitioning

6.     States and transitions between states

7.     Detailed specification for functions

8.     Top-down decomposition

9.     End-to-end processing sequences

10. Identification of exclusive services

11. Entity communication (via messages or events)

       Many variations exist for structured analysis and dozens of OOA methods have been proposed

       However, modeling dimensions 8 and 9 are always present with SA and never present when OOA is used.

The OOA Landscape

       The popularity of object technologies spawned dozens of OOA methods during the late 1980s and into the 1990s

       Each of these introduced:

o      a process for the analysis of a product or system

o      a set of diagrams that evolved out of the process

o      a notation that enabled the software engineer to create the analysis model in a consistent manner.

       Among the most widely used were:

 

The Booch method.  Eencompasses both a "micro development process" and a "macro development process."

       The micro level defines a set of analysis tasks that are reapplied for each step in the macro process

       OOA micro development process identifies classes and objects and the semantics of classes and objects and defines relationships among classes and objects and conducts a series of refinements to elaborate the analysis model.

The Rumbaugh method.  Object modeling technique (OMT) for analysis, system design, and object-level design.

       Analysis activity creates three models:

o      object model (a representation of objects, classes, hierarchies, and relationships)

o      dynamic model (a representation of object and system behavior)

o      functional model (a high-level DFD-like representation of information flow through the system).

The Jacobson method.  OOSE (object-oriented software engineering)

       Simplified version of the proprietary objectory method,

       Method is differentiated from others by heavy emphasis on the use-case — a description or scenario that depicts how the user interacts with the product or system.

The Coad and Yourdon method.  One of the easiest OOA methods to learn.

        Modeling notation is relatively simple

        Guidelines for developing the analysis model are straightforward.

        A brief outline of Coad and Yourdon's OOA process:

(1)  Identify objects using "what to look for" criteria.

(2)  Define a generalization/specification structure.

(3)  Define a whole/part structure.

(4)  Identify subjects (representations of subsystem components).

(5)  Define attributes.

(6)  Define services.

The Wirfs-Brock method.  

        Does not make a clear distinction between analysis and design tasks.

        A continuous process that begins with the assessment of a customer specification and ends with design is proposed. A brief outline of Wirfs-Brock et al.'s analysis-related tasks follows:

(1)  Evaluate the customer specification.

(2)  Extract candidate classes from the specification via grammatical parsing.

(3)  Group classes in an attempt to identify superclasses.

(4)  Define responsibilities for each class.

(5)  Assign responsibilities to each class.

(6)  Identify relationships between classes.

(7)  Define collaboration between classes based on responsibilities.

(8)  Build hierarchical representations of classes.

(9)  Construct a collaboration graph for the system.

        To perform object-oriented analysis, perform the following generic steps:

  1. Elicit customer requirements for the system.
  2. Identify scenarios or use-cases.
  3. Select classes and objects using basic requirements as a guide.
  4. Identify attributes and operations for each system object.
  5. Define structures and hierarchies that organize classes.
  6. Build an object-relationship model.
  7. Build an object-behavior model.
  8. Review the OO analysis model against use-cases or scenarios.

A Unified Approach to OOA

        Over the past decade, Grady Booch, James Rumbaugh, and Ivar Jacobson have collaborated to combine the best features of their individual object-oriented analysis and design methods into a unified method.

        The result, called the Unified Modeling Language (UML), has become widely used throughout the industry.

        UML allows expression of an analysis model using a modeling notation that is governed by a set of syntactic, semantic, and pragmatic rules.

        Eriksson and Penker explain these:

        The syntax tells us how the symbols should look and how the symbols are combined.

        The semantic rules tell what each symbol means and how it should be interpreted by itself and in the context of other symbols; they are compared to the meanings of words in a natural language.

        The pragmatic rules define the intentions of the symbols through which the purpose of the model is achieved and becomes understandable for others. This corresponds in natural language to the rules for constructing sentences that are clear and understandable.

        UML represents a system using five different "views" that describe the system from distinctly different perspectives.

        Each view is defined by a set of diagrams.

        The following views are present in UML:

(1)  User model view.  This view represents the system (product) from the user's (called actors in UML) perspective. The use-case is the modeling approach of choice for the user model view.

(2)  Structural model view.  Data and functionality are viewed from inside the system. That is, static structure (classes, objects, and relationships) is modeled.

(3)  Behavioral model view.  Represents the dynamic or behavioral aspects of the system. It also depicts the interactions or collaborations between various structural elements described in the user model and structural model views.

(4)  Implementation model view.  The structural and behavioral aspects of the system are represented as they are to be built.

(5)  Environment model view.  The structural and behavioral aspects of the environment in which the system is to be implemented are represented.

 

Domain Analysis

Domain analysis, is performed when an organization wants to create a library of reusable classes (components) that will be broadly applicable to an entire category of applications.

Reuse and Domain Analysis

Object-technologies are leveraged through reuse.

The Domain Analysis Process

        Software domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain . . .

        Object-oriented domain analysis is the identification, analysis, and specification of common, reusable capabilities within a specific application domain, in terms of common objects, classes, subassemblies, and frameworks . . .

        Goal of domain analysis is to find or create those classes that are broadly applicable, so that they may be reused.

        Domain analysis is an ongoing software engineering activity that is not connected to any one software project.

        Role of the domain analyst is to design and build reusable components that may be used by many people working on similar but not necessarily the same applications.

        Sources of domain knowledge are surveyed in an attempt to identify objects that can be reused across the domain.

        During domain analysis, object (and class) extraction occurs.

        Domain analysis process characterized by a series of activities that begin with the identification of the domain to be investigated and end with a specification of the objects and classes that characterize the domain:

       Define the domain to be investigated.

       isolate the business area, system type, or product category of interest

       both OO and non-OO "items" must be extracted.

o      OO items include specifications, designs, and code for existing OO application classes; support classes (e.g., GUI classes or database access classes); commercial off- the-shelf (COTS) component libraries that are relevant to the domain; and test cases.

o      Non-OO items encompass policies, procedures, plans, standards, and guidelines; parts of existing non-OO applications (including specification, design, and test information); metrics; and COTS non-OO software.

       Categorize the items extracted from the domain.

       Items are organized into categories and the general defining characteristics of the category are defined.

       A classification scheme for the categories is proposed and naming conventions for each item are defined.

       When appropriate, classification hierarchies are established.

       Collect a representative sample of applications in the domain.

       Ensure that the application in question has items that fit into the categories that have already been defined.

       Analyze each application in the sample.

       Identify candidate reusable objects.

       Indicate the reasons that the object has been identified for reuse.

       Define adaptations to the object that may also be reusable.

       Estimate the percentage of applications in the domain that might make reuse of the object.

       Identify the objects by name and use configuration management techniques to control them. In addition, once the objects have been defined, the analyst should estimate what percentage of a typical application could be constructed using the reusable objects.

       Develop an analysis model for the objects. The analysis model will serve as the basis for design and construction of the domain objects.

       Domain analyst should create a set of reuse guidelines and develop an example that illustrates how the domain objects could be used to create a new application.

 

Generic Components of the OO Analysis Model

       Monarchi and Puhr define a set of generic representational components that appear in all OO analysis models:

o      Static components are structural in nature and indicate characteristics that hold throughout the operational life of an application. These characteristics distinguish one object from other objects.

o      Dynamic components focus on control and are sensitive to timing and event processing. They define how one object interacts with other objects over time.

       Static view of semantic classes.

       Requirements are assessed and classes are extracted (and represented) as part of the analysis model.

       These classes persist throughout the life of the application and are derived based on the semantics of the customer requirements.

       Static view of attributes.

       Every class must be explicitly described.

       The attributes associated with the class provide a description of the class, as well as a first indication of the operations that are relevant to the class.

       Static view of relationships.

       Objects are "connected" to one another in a variety of ways.

       Analysis model must represent these relationships so that operations can be identified and the design of a messaging approach can be accomplished.

       Static view of behaviors.

       Relationships define a set of behaviors that accommodate the usage scenario (use-cases) of the system.

       These behaviors are implemented by defining a sequence of operations that achieve them.

       Dynamic view of communication.

       Objects must communicate with one another and do so based on a series of events that cause transition from one state of a system to another

       Dynamic view of control and time.

       The nature and timing of events that cause transitions among states must be described.

 

The OOA Process

       OOA process begins with an understanding of the manner in which the system will be used

Use-Cases

        Use-cases model the system from the end-user's point of view.

        Created during requirements elicitation, use-cases should achieve the following objectives:

        During OOA, use-cases serve as the basis for the first element of the analysis model.

        UML notation is used to diagram a use-case

o      can be represented at many levels of abstraction.

o      contains actors and use-cases.

       Actors are entities that interact with the system. They can be human users or other machines or systems that have defined interfaces to the software.

 

Class-Responsibility-Collaborator Modeling

       Class-responsibility-collaborator (CRC) modeling provides a means for identifying and organizing the classes that are relevant to system or product requirements.

       A CRC model is a collection of standard index cards that represent classes

       Cards are divided into three sections:

o      Class name along the top of the card

o      Card body:

       Left: class responsibilities

       Right: the collaborators

       CRC model may make use of actual or virtual index cards.

       Intent is to develop an organized representation of classes.

       A Responsibility is anything the class knows or does

       Collaborators are those classes that are required to provide a class with the information needed to complete a responsibility.

Classes

       To identify classes and objects perform a grammatical parse on the processing narrative for the system

       All nouns become potential objects.

       Six selection characteristics were defined:

  1. Retained information. The potential object will be useful during analysis only if information about it must be remembered so that the system can function.
  2. Needed services. The potential object must have a set of identifiable operations that can change the value of its attributes in some way.
  3. Multiple attributes. During requirements analysis, the focus should be on "major" information; an object with a single attribute may, in fact, be useful during design but is probably better represented as an attribute of another object during the analysis activity.
  4. Common attributes. A set of attributes can be defined for the potential object and these attributes apply to all occurrences of the object.
  5. Common operations. A set of operations can be defined for the potential object and these operations apply to all occurrences of the object.
  6. Essential requirements. External entities that appear in the problem space and produce or consume information that is essential to the operation of any solution for the system will almost always be defined as objects in the requirements model.

 

       Potential object should satisfy all six of these selection characteristics if it is to be considered for inclusion in the CRC model.

       Firesmith extends this taxonomy of class types:

o      Device classes  model external entities such as sensors, motors, keyboards.

o      Property classes  represent some important property of the problem environment (e.g., credit rating within the context of a mortgage loan application).

o      Interaction classes  model interactions that occur among other objects (e.g., a purchase or a license).

       Objects and classes may be categorized by a set of characteristics:

o      Tangibility. Does the class represent a tangible thing (e.g., a keyboard or sensor) or does it represent more abstract information (e.g., a predicted outcome)?

o      Inclusiveness. Is the class atomic (i.e., it includes no other classes) or is it aggregate (it includes at least one nested object)?

o      Sequentiality. Is the class concurrent (i.e., it has its own thread of control) or sequential (it is controlled by outside resources)?

o      Persistence. Is the class transient (i.e., it is created and removed during program operation), temporary (it is created during program operation and removed once the program terminates), or permanent (it is stored in a database)?

o      Integrity. Is the class corruptible (i.e., it does not protect its resources from outside influence) or guarded (i.e., the class enforces controls on access to its resources)?

Responsibilities

       Attributes represent stable features of a class -> information about the class that must be retained to accomplish the objectives of the software specified by the customer.

       Attributes can be extracted from the statement of scope or discerned from an understanding of the nature of the class.

       Operations can be extracted by performing a grammatical parse on the processing narrative for the system.

       All verbs become candidate operations.

       Each operation that is chosen for a class exhibits a behavior of the class.

       Five guidelines for allocating responsibilities to classes:

  1. System intelligence should be evenly distributed.

(1)  It concentrates all intelligence within a few classes, making changes more difficult

(2)  It tends to require more classes, hence more development effort.

       To look for even distribution lok at the responsibilities noted on each CRC model index card to see if any class has a extra long list of responsibilities.

       Responsibilities for each class should exhibit the same level of abstraction.

       e.g. aggregate class called checking account - two responsibilities: balance-the-account and check-off-cleared-checks.

o      First operation implies a complex mathematical and logical procedure.

o      Second is a simple clerical activity.

o      Since these two operations are not at the same level of abstraction, check-off-cleared-checks should be placed within the responsibilities of check-entry, a class that is encompassed by the aggregate class checking account.

  1. Each responsibility should be stated as generally as possible.
  1. Information and the behavior related to it should reside within the same class.
  2. Information about one thing should be localized with a single class, not distributed across multiple classes.
  3. Responsibilities should be shared among related classes, when appropriate.

       e.g. video game that must display the following objects: player, player-body, player-arms, player-legs, player-head.

       Each of these objects has its own attributes (e.g., position, orientation, color, speed) and all must be updated and displayed as the user manipulates a joy stick.

       The responsibilities update and display must therefore be shared by each of the objects noted.

       Player knows when something has changed and update is required. It collaborates with the other objects to achieve a new position or orientation, but each object controls its own display.

Collaborations

       Classes fulfill their responsibilities in one of two ways:

       A class can use its own operations to manipulate its own attributes, thereby fulfilling a particular responsibility

       A class can collaborate with other classes.

       Collaboration definition:

       Collaborations represent requests from a client to a server in fulfillment of a client responsibility.

       A single collaboration flows in one direction—representing a request from the client to the server.

       From the client's point of view, each of its collaborations are associated with a particular responsibility implemented by the server.

       Collaborations identify relationships between classes.

       When a set of classes all collaborate to achieve some requirement, they can be organized into a subsystem.

       A collaboration exists if a class cannot fulfill each responsibility itself

 

       Identification of collaborators -> examine three different generic relationships between classes

(1)  the is-part-of relationship

(2)  the has-knowledge-of relationship

(3)   the depends-upon relationship.

       Create a class-relationship diagram to develop the connections necessary to identify these relationships

 

       All classes that are part of an aggregate class are connected to the aggregate class via an is-part-of relationship.

o      e.g. video game -> the class player-body is-part-of player, as are player-arms, player-legs, and player-head.

       When one class must acquire information from another class, the has-knowledge-of relationship is established.

o      The determine-sensor-status responsibility noted earlier is an example of a has-knowledge-of relationship.

       The depends-upon relationship implies that two classes have a dependency that is not achieved by has-knowledge-of or is-part-of.

o      e.g. player-head must always be connected to player-body (unless the video game is particularly violent)

 

The Object-Relationship Model

       The CRC modeling approach establishes the first elements of class and object relationships.

       The first step in establishing relationships is to understand the responsibilities for each class.

       The next step is to define those collaborator classes that help in achieving each responsibility.

 

       A relationship exists between any two classes that are connected

       Most common type of relationship is binary—a connection exists between two classes.

       A binary relationship is defined based on which class plays the role of the client and which acts as a server.

       Relationships can be derived by examining the stative verbs or verb phrases in the statement of scope or use-cases for the system.

       Using a grammatical parse, the analyst isolates verbs that indicate:

o      physical location or placement (next to, part of, contained in)

o      communications (transmits to, acquires from)

o      ownership (incorporated by, is composed of)

o      satisfaction of a condition (manages, coordinates, controls).

       The object relationship model (like the entity relationship model) can be derived in three steps:

  1. Using the CRC index cards, a network of collaborator objects can be drawn.

o      First the objects are drawn, connected by unlabeled lines (not shown in the figure) that indicate some relationship exists between the connected objects.

  1. Reviewing the CRC model index card, responsibilities and collaborators are evaluated and each unlabeled connected line is named. A

o      An arrow head indicates the "direction" of the relationship

  1. Once the named relationships have been established, each end is evaluated to determine cardinality (

o      Four options exist: 0 to 1, 1 to 1, 0 to many, or 1 to many.

o      e.g. the SafeHome system contains a single control panel (the 1:1 cardinality notation indicates this).

o       At least one sensor must be present for polling by the control panel. However, there may be many sensors present (the 1:m notation indicates this). One sensor can recognize from 0 to many sensor events (e.g., smoke is detected or a break-in has occurred).

       The steps continue until a complete object-relationship model has been produced.

 

The Object-Behavior Model

       The object-behavior model indicates how an OO system will respond to external events or stimuli.

       To create the model, perform the following steps:

  1. Evaluate all use-cases (Section 21.4.1) to fully understand the sequence of interaction within the system.
  2. Identify events that drive the interaction sequence and understand how these events relate to specific objects.
  3. Create an event trace [RUM91] for each use-case.
  4. Build a state transition diagram for the system.
  5. Review the object-behavior model to verify accuracy and consistency.

Event Identification with Use-Cases

       An event occurs whenever an OO system and an actor exchange information.

       An event is Boolean.

       A use-case is examined for points of information exchange.

       e.g.

1.  The homeowner observes the SafeHome control panel to determine if the system is ready for input. If the system is not ready, the homeowner must physically close windows/doors so that the ready indicator is present. [A not-ready indicator implies that a sensor is open, i.e., that a door or window is open.]

2.  The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password is incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action.

3.  The homeowner selects and keys in stay or away to activate the system. Stay activates only perimeter sensors (inside motion detecting sensors are deactivated). Away activates all sensors.

4.     When activation occurs, a red alarm light can be observed by the homeowner.

 

       Underlined portions of the use-case scenario indicate events.

       An actor should be identified for each event

       Information that is exchanged should be noted

       Any conditions or constraints should be listed.

       Once all events have been identified, they are allocated to the objects involved.

       Objects can be responsible for generating events (e.g., homeowner generates the password entered event) or recognizing events that have occurred elsewhere (e.g., control panel recognizes the binary result of the compare password event).

State Representations

       Two different characterizations of states must be considered:

(1)  the state of each object as the system performs its function

(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:

o      A passive state is the current status of all of an object's attributes.

o      The active state of an object indicates the current status of the object as it undergoes a continuing transformation or processing.

        An event trace is a shorthand version of the use-case. It represents key objects and the events that cause behavior to flow from object to object

o      Each of the arrows represents an event (derived from a use-case) and indicates how the event channels behavior between SafeHome objects.

o      The first event, system ready, is derived from the external environment and channels behavior to the homeowner object. The homeowner enters a password. The event initiates beep and "beep sounded" and indicates how behavior is channeled if the password is invalid.

o      A valid password results in flow back to homeowner. The remaining events and traces follow the behavior as the system is activated or deactivated