Docstoc

Analysis Modeling

Document Sample
Analysis Modeling Powered By Docstoc
					           Unit 4
Building the Analysis Model

                     Prepared by
                   Swarnalata Rao
Introduction
 The analysis model is actually a set of models , is the first
  technical representation of a system.

 Analysis modeling uses a combination of text and diagrammatic
  forms to depict requirements for data, function and behavior in a
  way that is easy to understand and more important,
  straightforward to review for correctness, completeness and
  consistency.
Requirements analysis
 Requirements analysis
   specifies software’s operational characteristics
   indicates software's interface with other system elements
   establishes constraints that software must meet
 Requirements analysis allows the software engineer (called an
  analyst or modeler in this role) to:
   elaborate on basic requirements established during earlier
    requirement engineering tasks
   build models that depict user scenarios, functional activities,
    problem classes and their relationships, system and class behavior,
    and the flow of data as it is transformed.
   Provides the developer and customer to assess quality once s/w is
    built.
Requirements analysis
 Throughout analysis modeling, s/w engineer:
   Primary focus is on what and not how
   What objects does the system manipulate
   What functions must the system perform.
   What behaviors does the system exhibit and what interfaces are
    defined
   What constraints apply?             syste m
                                       de scription


                                                      analysis
                                                       mode l


                                                                 de sign
                                                                 mode l
Analysis Rules of thumb
 The model should focus on requirements that are visible
    within the problem or business domain. The level of
    abstraction should be relatively high.
   Each element of the analysis model should add to an overall
    understanding of software requirements and provide insight
    into the information domain, function and behavior of the
    system.
   Delay consideration of infrastructure and other non-
    functional models until design.
   Minimize coupling throughout the system.
   Be certain that the analysis model provides value to all
    stakeholders.
   Keep the model as simple as it can be.
Domain Analysis
 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 . . .
                                            Donald Firesmith
Domain Analysis
 The role of domain analyst:
   Discover and define reusable analysis patterns
   Analysis classes
   Related information
 Key inputs to domain analysis
   Technical literature
   Existing applications
   Current/future requirements
 Key outputs of domain analysis
   Class taxonomies
   Reuse standards
   Functional models
Analysis Modeling Approaches
1.    Structured Analysis:
      Considers data and the processes that transforms data


2.    Object-Oriented Analysis:
      Focuses on definition of classes and the ways they
       collaborate.

Basic elements of Analysis model:
    Scenario-based elements
     Flow- oriented elements
     Class-based elements
     Behavioral-based elements
Data Modeling Concepts
 examines all data objects that are processed within the system
 Relationship between the data objects
 Other information related to relationships.


 Data Objects:
 Data object is a representation of almost any composite
  information (no. of attributes) that must be understood by s/w.
 It can be an external entity, a thing, an occurrence or an event, a
  role or a structure.
 It encapsulates data only. For eg., Tata Nano is an instance of the
  data object car.
Data Modeling Concepts
  Data Attributes:
    A data object contains a set of attributes that act as an aspect,
     quality, characteristic, or descriptor of the object.
    They can be used to :
      Name an instance of the data object
      Describe the instance
      Make reference to another instance


     Example:
     Data Object: Car
     Attributes: Make, Model, ID, Color etc..
Data Modeling Concepts
  Relationships: indicates ―connectedness‖;
  for example:
    A person owns a car
    A person is insure to drive a car.



             Person                        Car

  Basic connection between data objects

                            owns
             Person                        Car
                            Insured
                            to drive
  Relationship between data objects
Data Modeling Concepts
 Cardinality and Modality:
   several instances of a relationship can exist
   objects can be related in many different ways
 Cardinality: it is the specification of the number of occurrences of
  one object that can be related to the number of occurrences of another
  object.
   1:1 relationship: one object related to only one object
   1:N relationship: one object related to many objects
   M:N relationship: some no. of occurrences of one object related
    to some no. of occurrences of another object
Data Modeling Concepts
 Modality: provides an indication of whether or not a particular data
  object must participate in the relationship.
 The modality of a relationship is 0 if there is no explicit need for the
  relationship to occur.
 The modality of a relationship is 1 if an occurrence of the relationship
  is mandatory.

    The object/relationship pairs can be represented using
     entity/relationship diagram (ERD)
Object-Oriented Analysis
 Intent: to define all classes ( and the relationships and behavior
  associated with them)

 Number of tasks can occur:
   Basic user requirements must be communicated
   Classes must be identified
   A class hierarchy is defined
   Object-to-object relationships should be represented
   Object behavior must be modeled.
Scenario-based modeling
 Writing use-cases:
 A use-case captures the interactions that occur between producers and
  consumers of information and the system itself.

 Questions to be answered:
   What to write about?
   How much to write about it?
   How detailed to make our description?
   How to organize the description?
 Developing Use-cases?
 What are the main tasks or functions that are performed by the actor?
 What system information will the actor acquire, produce or change?
 Will the actor have to inform the system about changes in the external
  environment?
 What information does the actor desire from the system?
 Does the actor wish to be informed about unexpected changes?
    Actors
   Entities external to the system who interact with the system.
   Communicate with the system by sending and/or receiving
    messages.
   Represents a role, not individuals; can be a person or a device or
    another system.
   An actor may participate in many use cases; a use case may have
    several actors participating in it.




          Notation:
     Finding Actors
   Who uses the main functionality of the system?
   Who needs support from the system?
   Who will need to maintain, administrate, and keep the system
    working?
   Which hardware devices the system needs to handle?
   Which other systems does the system need to interact with?
   Actors - Example
The Bookworm is a circulating library that lends books for a
specified period of time. Books are lent to members only. If available,
the book is issued forthwith to the requesting member. If the book is
not currently available, the member can reserve the same. If the
member fails to return the book after the specified period and/or
loses or damages the book, he is required to make good the
loss/damage.


       Actors:

                        Librarian           Member
    Use Case
   Is an abstraction of a set of sequences that yield some
    functionality.
   Represents some user-visible function.
   Is always initiated by an ―actor‖.
   Describes the interaction between the actors and the system
    for a system function.
   Achieves a discrete goal for the actor.


           Notation:                     Login
Finding Use Cases
    What functions does the system perform?
    What functions do the ―actors‖ require?
    What input/output does the system need?
   Use Case - Example
The Bookworm is a circulating library that lends books and
journals for a specified period of time. Books are lent to members
only. If available, the book is issued forthwith to the requesting
member. If the book is not currently available, the member can
reserve the same. If the member fails to return the book after the
specified period and/or loses or damages the book, he is required to
make good the loss/damage. Alternatively, at the end of the period,
the borrower may renew the issue.
Membership is accorded for a period of one year, at the end of which
the member has the option to renew his membership.
  Use Case - Example (contd.)
Use Cases:

  ReserveBook   IssueBook     ReturnBook




  CollectDues   RenewIssue    RnwMship




                ViewCatalog
    Use Case Diagram
   A graphical representation of the Use Cases of a system, its
    actors, and the interaction between them.
   It depicts the system boundary.
   Diagram Model elements
        Actors
        Use cases
        Relationships
           between Actors and Use Cases
           between Use Cases themselves
       Use Case Diagram: Example
             IssueBook


                                   ReturnBook

             CollectDues

Librarian                                        Member
                                   ReserveBook

             RenewIssue


                                   RnwMship


                         ViewCatalog
     Use Case Description - Example
Use Case:             ViewCatalog
  Actors:             Librarian, Member
 Purpose:             Browse the Catalog of books and journals
Overview:             Allows the librarian or a member to browse through
                      the catalog of books. The catalog contains details such
                      as …..

Main flow of events:
The use case begins when either actor starts browsing for a book. They can specify a
specific book by Title, Author or Publisher. All books satisfying the specified criteria are
displayed to the user (Librarian or Member).
Developing an Activity Diagram
 The UML Activity diagram supplements the use-case by
  providing a graphical representation of the flow of interaction
  within a specific scenario.

 Notations:


 System function: Rounded rectangles
 Arrows: flow through the system
 Diamond: decision making
 Solid horizontal line: parallel activities
Developing an Activity Diagram: Example



      Request
      Service


                         Take Order

        Pay
                                          Fill Order


                           Deliver
       Accept              Order
       Delivery
Developing an Activity Diagram
 Basic Elements:


 Initial State
 Final State
 Action states
 Action flows
 Object flows
Developing an Activity Diagram
 Action States
   represent execution of atomic actions or steps in the execution of an
    algorithm
   each action state labeled by an action-expression
   completion of the action in the state implicitly triggers outgoing
    transition
   outgoing transitions may include guard conditions


 Action Flows
   represent flow of control between action states
   are triggered by the completion of actions in action states
Developing an Activity Diagram
 Object Flows
   show the flow of objects between action states
   shows objects that are input/output of actions
   denoted by dashed lines between action states and object boxes
Developing an Activity Diagram: Example
                  Initial State


      Request                         Action State
      Service
                                                     Action Flow
                                  Take Order

        Pay
                                                             Fill Order


                                    Deliver
       Accept                       Order
       Delivery


                  Final State
Developing an Activity Diagram
 Decisions
   depicted by diamond shape icon, with one or more incoming arrows
    and two or more outgoing arrows, each labeled by a distinct guard
    condition

                                  [Cost<500]
         Calculate Total
                                                    Issue Item
             Cost



                                               Get Approval
                               [Cost>=500]
Swimlane Diagrams
 It is a useful version of the activity diagram and allows the
  modeler to represent the flow of activities described by the use-
  case and at the same time indicate which actor has responsibility
  for the action described by an activity rectangle.

 Responsibilities are represented as parallel segments that divide
  the diagram vertically, like the lanes in a swimming pool.
Developing an Activity Diagram: Example
     Customer
                         Sales            Inventory

      Request
      Service


                         Take Order

        Pay
                                            Fill Order


                            Deliver
       Accept               Order
       Delivery
Flow-Oriented Modeling
 Data flow-oriented modeling is one of the most widely used
  notations.
 A data flow diagram (DFD) is the diagrammatic form that is used
  to represent how data objects are transformed at they move
  through the system.



                            computer
        input                based               output
                             system



 DFD takes an input-process-output view of a system.
     Flow Modeling Notation


                  external entity



                  Process/ transactions


                  data flow


                  data store


36
Flow-Oriented Modeling
 DFD is presented in a hierarchical fashion.
 The first data flow model is called Level 0 DFD or Context
  Diagram which represents the system as a whole.
 Subsequent data flow diagrams refine the context diagram,
  providing increasing detail with each subsequent level.
     External Entity
        A producer or consumer of data


       Examples: a person, a device, a sensor

       Another example: computer-based
       system

       Data must always originate somewhere
       and must always be sent to something



38
 Process
        A data transformer (changes input
        to output)

     Examples: compute taxes, determine area,
     format report, display graph

     Data must always be processed in some
     way to achieve system function




39
     Data Flow


       Data flows through a system, beginning
       as input and be transformed into output.

            base
                       compute
                                  area
                       triangle
           height         area




40
     Data Stores
                         Data is often stored for later use.

                    sensor #
                                             sensor #, type,
                               look-up       location, age
                                sensor
       report required           data
                                                type,
                                                location, age
                           sensor number


                                           sensor data




41
Creating a Data Flow Model: Guidelines
1.   The level 0 DFD should depict the s/w or system as a single
     bubble.
2.   Primary input and output should be carefully noted
3.   Refinement should begin by isolating candidate processes, data
     objects and data stores to be represented in next level.
4.   All arrows and bubbles should be labeled with meaningful
     names.
5.   Information flow continuity must be maintained from level to
     level
6.   One bubble at a time should be refined.
   Example Context Diagram

             course
student      selections




          schedule
                          Registration
                                         Registration details
                          System


                                                  business
                                                  office
     Constructing a DFD—I
      review the data model to isolate data objects and use a
       grammatical parse to determine ―operations‖
      determine external entities (producers and consumers
       of data)
      create a level 0 DFD




44
     Level 0 DFD Example
                processing
      user        request                 requested
                                            video
                                digital     signal
                                video                 monitor
                              processor
       video
      source      NTSC
               video signal




45
     Constructing a DFD—II

       write a narrative describing the transform
       parse to determine next level transforms
       ―balance‖ the flow to maintain data flow continuity
       develop a level 1 DFD
       use a 1:5 (approx.) expansion ratio




46
     The Data Flow Hierarchy


                   a                         b
            x                    P                    y       level 0



        a              c        p2
             p1
                                         f

                                             p4                  b
                   d                                      5
                           p3        e            g
         level 1



47
     Flow Modeling Notes

      each bubble is refined until it does just one
       thing
      the expansion ratio decreases as the number of
       levels increase
      most systems require between 3 and 7 levels
       for an adequate flow model
      a single data flow item (arrow) may be
       expanded as levels increase (data dictionary
       provides information)


48
Creating a Control Flow Model
 Represents ―events‖ and the processes that manage events
 An ―event‖ is a Boolean condition that can be ascertained by:
      listing all sensors that are "read" by the software.
      listing all interrupt conditions.
      listing all "switches" that are actuated by an operator.
      listing all data conditions.
      recalling the noun/verb parse that was applied to the
       processing narrative, review all "control items" as possible
       CSPEC inputs/outputs.
The Control Specification (CSPEC)
 It represents the behavior of the system in two different ways:
   It contains a state diagram that is a sequential specification of
    behavior
   It may also contain program activation table – a combinatorial
    specification of behavior.



   The CSPEC describes the behavior of the system, but it gives us no
    information about the inner working of the processes that are
    activated as a result of this behavior.
The Process Specification (PSPEC)
   It is use to describe all flow model processes that appear at the final
    level of refinement.
   It includes following:
      Narrative text
      A program design language (PDL) description of the process
        algorithm
      Mathematical equations
      tables
      diagrams
      Charts

     A PSPEC with each bubble serves as a guide for design of the s/w
      component that will implement the process.
The Process Specification (PSPEC)
    PSPEC (process password):
    The process password transform performs password validation at the
      control panel. Process password receives a 4-digit password from the
      interact with user function. The password is first compared to the
      master password stored within the system……
    Class-Based Modeling
 Developing class- based elements of an analysis model
  includes:
   Classes and Objects
   Attributes
   Operations
   Packages
   CRC Models
   Collaboration Diagrams
Identifying Analysis Classes
 Identify analysis classes by examining the problem statement
 Use a ―grammatical parse‖ to isolate potential classes
 Identify the attributes of each class
 Identify operations that manipulate the attributes
     Analysis Classes
 External entities (e.g., other systems, devices, people) that produce
    or consume information to be used by a computer-based system.
   Things (e.g, reports, displays, letters, signals) that are part of the
    information domain for the problem.
   Occurrences or events (e.g., a property transfer or the completion
    of a series of robot movements) that occur within the context of
    system operation.
   Roles (e.g., manager, engineer, salesperson) played by people who
    interact with the system.
   Organizational units (e.g., division, group, team) that are relevant
    to an application.
   Places (e.g., manufacturing floor or loading dock) that establish the
    context of the problem and the overall function of the system.
   Structures (e.g., sensors, four-wheeled vehicles, or computers) that
    define a class of objects or related classes of objects.
    Analysis Classes
 Coad and Yourdon suggest six selection characteristics to consider
   each potential class for inclusion in the analysis model:
1. Retained Information: the potential class will be useful during
   analysis only if information about it must be remembered so that the
   system can function
2. Needed services: the potential class must have a set of identifiable
   operations that can change the value of its attributes in some way.
3. Multiple Attributes: the focus should be on major information.
4. Common Attributes: a set of attributes can be defined for the
   potential class, and these attributes apply to all instances of the class.
5. Common operations: a set of operations can be defined for the
   potential class and these operations apply to all instances of the class.
6. Essential requirements: External entities essential to the
   operation of any solution for the system.
Specifying Attributes
 Attributes describe a class.
 Study use-case and select those ―things‖ that reasonably ―belong‖ to
  the class.

 For example:
 Identification information: system ID + verification phone number
  + system status.
Defining Operations
 Operations define the behavior of an object.
 They can be divided into foll. broad categories:
   Operations that manipulate data in some way (adding, deleting,
    reformatting, selecting)
   Operations that perform a computation
   Operations that inquire about the state of an object
   Operations that monitor an object for the occurrence of a controlling
    event

 The grammatical parse is studied and verbs are isolated.
        Class Diagram
Class name
                          System
             systemID
             verificationPhoneNumber
             systemStatus
                                       attributes
             dela yTime
             telephoneNumber
             masterPassw ord
             temporaryPassword
             numberTrie s



             program()
             displa y()
             reset()
             query()                    operations
             modif y()
             call()
Class Diagram
                                                                Flo o rPlan
                                                         type
                                                         name
                                                         outsideDimensions


                                                         determineType ( )
                                                         positionFloorplan
                                                         scale( )
                                                         change color( )




                             is plac ed wit hin

                                                                                       is par t of




          Cam er a                                                              Wall

t y pe                                                            t y pe
ID                                                                w allD im ens ions
loc at ion
f ieldV iew
panA ngle
Zoom Set t ing
                                                                  determineType ( )
                                                                  computeDimensions          ()
det er m ineTy pe ( )
t rans lat eLoc at ion ( )
dis play ID ()
dis play V iew ()
dis play Zoom ( )
                                                 is us ed t o build                                  is us ed t o build

                                                                                        is us ed t o build

                                      WallSegm ent                            Window                                  Door

                               t y pe                                 t y pe                              t y pe
                               s t ar t Coor dinat es                 s t art Coordinat es                s t ar t Coor dinat es
                               s t opCoor dinat es                    s t opCoor dinat es                 s t opCoordinat es
                               nex t WallSem ent                      nex t Window                        nex t D oor

                               determineType ( )                      determineType ( )                  determineType ( )
                               draw( )                                draw( )                            draw( )
Class-Responsibility-Collaborator (CRC) Modeling
  CRC modeling provides a simple means for identifying and
   organizing the classes that are relevant to system or product
   requirements.
  The intent is to develop an organized representation of classes.
  Analysis classes have ―responsibilities‖
    Responsibilities are the attributes and operations encapsulated by
     the class
  Analysis classes collaborate with one another
    Collaborators are those classes that are required to provide a class
     with the information needed to complete a responsibility.
    In general, a collaboration implies either a request for
     information or a request for some action.
            CRC Modeling

Class:
  Class:
Descrip tion:
    Class:
  Descrip tion: FloorPlan
       Class:
    Descrip tion:
Responsibility:
       Descrip tion:                    Collaborator:
  Responsibility:                        Collaborator:
    Responsibility:                        Collaborator:
       Responsibility:                          Collaborator:
     defines floor plan name/type
     manages floor plan positio ning
     scales f lo or plan for display
     scales f lo or plan for display
     incorporates w alls , doors and w indow s   Wall
     show s position of video cameras            Camera
                    Class Types
 Entity classes, also called model or business classes, are extracted
  directly from the statement of the problem (e.g., Floor Plan and
  Sensor).
 Boundary classes are used to create the interface (e.g.,
  interactive screen or printed reports) that the user sees and
  interacts with as the software is used.
 Controller classes manage a ―unit of work‖ from start to finish.
  That is, controller classes can be designed to manage
    the creation or update of entity objects;
    the instantiation of boundary objects as they obtain
     information from entity objects;
    complex communication between sets of objects;
    validation of data communicated between objects or between
     the user and the application.
    Responsibilities
 Five guidelines for allocating responsibilities to
    classes:

 System intelligence should be distributed across classes to
    best address the needs of the problem
   Each responsibility should be stated as generally as possible
   Information and the behavior related to it should reside
    within the same class
   Information about one thing should be localized with a single
    class, not distributed across multiple classes.
   Responsibilities should be shared among related classes,
    when appropriate.
 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, or
    a class can collaborate with other classes.
 Collaborations identify relationships between classes
 Collaborations are identified by determining whether a class can
  fulfill each responsibility itself. If it cannot, then it needs to
  interact with another class . Hence, a collaboration.
 three different generic relationships between classes:
    the is-part-of relationship
    the has-knowledge-of relationship
    the depends-upon relationship
 Collaborations
 All classes that are part of an aggregate class are connected to
  the aggregate class via an is-part-of relationship.

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

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




   PlayerHead   PlayerBody            PlayerArms   PlayerLegs
Reviewing the CRC Model
 All participants in the review (of the CRC model) are given a subset of
  the CRC model index cards.
    Cards that collaborate should be separated (i.e., no reviewer should
     have two cards that collaborate).
 All use-case scenarios (and corresponding use-case diagrams) should
  be organized into categories.
 The review leader reads the use-case deliberately.
    As the review leader comes to a named object, she passes a token to
     the person holding the corresponding class index card.
Reviewing the CRC Model
 When the token is passed, the holder of the class card is asked to
  describe the responsibilities noted on the card.
    The group determines whether one (or more) of the responsibilities
      satisfies the use-case requirement.
 If the responsibilities and collaborations noted on the index cards
  cannot accommodate the use-case, modifications are made to the
  cards.
    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.
Associations and Dependencies
 Two analysis classes are often related to one another in some
  fashion
   In UML these relationships are called associations
   Associations can be refined by indicating multiplicity (the term
    cardinality is used in data modeling)


 In many instances, a client-server relationship exists between
  two analysis classes.
   In such cases, a client-class depends on the server-class in some
    way and a dependency relationship is established
              Multiplicity
                                                   Wall




                                          1       1       1

                     is used to build                             is used to build

              1..*                               0..* is used to build      0..*

            WallSegm ent                Window                   Door




1..* = one or more
0..* = zero or more
                Dependencies
             DisplayWindow                             Camera

                                <<access>>

                                         {passw ord}




Dependencies are defined by a stereotype. A stereotype is an ―extensibility
mechanism within UML that allows a s/w engineer to define a special modeling
element whose semantics are custom-defined.‖ It is represented in double angle
brackets.
Behavioral Modeling
 The behavioral model indicates how software will respond to
  external events or stimuli.

 make a list of the different states of a system (How does the
  system behave?)
 indicate how the system makes a transition from one state to
  another (How does the system change state?)
   indicate event
   indicate action
 draw a state diagram or a sequence diagram
Behavioral Modeling
 To create the model, the analyst must perform the following steps:
      Evaluate all use-cases to fully understand the sequence of
       interaction within the system.
      Identify events that drive the interaction sequence and
       understand how these events relate to specific objects.
      Create a sequence for each use-case.
      Build a state diagram for the system.
      Review the behavioral model to verify accuracy and
       consistency.
   State Representations
 In the context of behavioral modeling, two different
  characterizations of states must be considered:
   the state of each class as the system performs its function and
   the state of the system as observed from the outside as the
    system performs its function
 The state of a class takes on both passive and active
  characteristics:
   A passive state is simply the current status of all of an object’s
    attributes.
   The active state of an object indicates the current status of the
    object as it undergoes a continuing transformation or
    processing.
The States of a System
 state—a set of observable circumstances that characterizes
  the behavior of a system at a given time
 state transition—the movement from one state to another
 event—an occurrence that causes the system to exhibit
  some predictable form of behavior
 action—process that occurs as a consequence of making a
  transition
State Diagram for the ControlPanel Class
                                                                            t imer < lockedTime




                                    t imer > lockedTime                           locked



                                        password = incorrect
                                     & numberOfTries < maxTries


                     reading                    comparing               numberOfTries > maxTries
           key hit
                               password
                                ent ered    do: validat ePassw ord
                                                                        password = correct



                                                                                 select ing




                                             act iv at ion successful
The States of a System
 Each arrow represents a transition from one active state of
  a class to another.
 Labels for each arrow represent the event that triggers the
  transition.
 A guard is a Boolean condition that must be satisfied in
  order for the transition to occur.
 An action occurs concurrently with the state transition or
  as a consequence of it and generally involves one or more
  operations of the object.
Sequence Diagram
 It is a representation of how events cause flow from one
  object to another as a function of time.

 In this,
 Arrows represent an event and indicates how the event
  channels behavior between objects.
 Time is measured vertically (downwards)
 Narrow vertical rectangles represent time spent in
  processing an activity.
 States may be shown along a vertical line.
   Sequence Diagram
     homeowner                              co nt rol panel                        syst em                          sensors
                                                                                                                    sensors



                                               readin g
syst em                    A
ready
                   password ent ered

                                                              request lookup
                                             comparing

                                                                   result

                                                              password = correct
             num berOf Tries > m axTries                                                     request act ivat ion
                                                locked

                      t imer > lockedTime
             A



                                               select ing


                 act ivat ion successful                                                 act ivat ion successful




                         Figure 8 .2 7 Sequence diagram (part ial) f or Saf eHome securit y f unct ion

				
DOCUMENT INFO