3: The first isolated application
Card access control system (CAC)

  • 3: The first isolated application
    Card access control system (CAC)
    a drawing

    3.1: An Access Control problem
    Area of concern

    a drawing
    We illustrate the OOram method through a simple Access Control example and start by determining our area of concern.

    Focusing on the design of the AccessControl subsystem, we find critical objects to be Persons, Controllers/LocalStations, and Validator/CentralStation. The Zone transitions are implicit in the identity of the LocalStations; each LocalStation servicing an entry point from one Zone to another. Therefore, the building Zones are not explicit objects in this model.

    3.2: User interfaces
    Prototype Program

    a drawing
    Card Reader is simulated by a text input window - reading person's name Door is simulated by an output text window showing door status Management interface shows list of persons, provides functionality of adding, changing, and removing persons and their 'secret' codes. Open Door Alarm shown by red background in management interface.

    3.3: Process Steps

    a drawing
    Explain what we are going to show you:

    3.3.1: System seen from environment
    Environment collaboration view

    AC-System ArchitectureDGR

    We first consider the access control system as a single object. This object is virtual , it will be replaced by a structure of interacting objects in the completed system.

    We then identify the environment objects. An environment object is an object that is not part of the system proper, and influences the system or is influenced by the system. We also make an abstraction by identifying an archetypical pattern of objects and call it a role model. Each role in the role model represents all objects that occupy a corresponding position in the object structure.

    3.3.2: System seen from environment
    Stimulus-Response view

    a drawing

    We next identify the stimulus messages , i.e. the messages that are spontaneously sent from an environment object. A stimulus message triggers a system activity.

    This example assumes that access is by a personal identity card. A stimulus is that the Person lets the system read the card. The response is that the Door is unlocked for a certain period if the card is accepted, or a reject action if not. An alarm will be given if the door remains open after a predetermined time.

    The SystemManager will give other stimuli. We show two examples. e.g., the addition of a person with given access rights. The complete system will of course have a much richer interface for the SystemManager.

    3.3.3: System Architecture
    A Choice

    AC-System ArchitectureDGR
    Rationale: 1. We clearly must have some equipment at door (Door opener, ID-reader) 2. We choose to centralize something, (e.g., access database)

    3.3.4: Separation of Concern

    a drawing
    The two top ones do not describe coherent activities

    DISTRIBUTION COMMENTS:

    3.3.5: Consider Separation of concern

    a drawing
    The systems will split on use case. PEER subsystems Systems share common information: The access database.

    The stimulus-response view shows two categories of stimuli:

    3.3.6: Revised plan for system development

    a drawing
    Explain: System Requirement Model (as seen by users) System Design Model (as seen by programmers)

    3.4: Validation subsystem (VAL)

    a drawing

    3.4.1: Validation Environment

    Virtual CO-Card Only DGR

    Our figure says that in this case, the the environment objects play the following roles within our area of concern:

    3.4.2: VAL Normal access scenario

    No RM model

    This scenario shows the normal message sequence for a successful access through a Door:

    This and other scenarios act as a specification of the external behavior of the System. The set of all interesting scenarios that follow from the readCard stimulus message describes the readCard activity. It is also commonly called a Use Case .

    3.4.3: VAL Open door alarm scenario

    a drawing
    Trenger vi to scenarioer her?? This and other scenarios act as a specification of the external behavior of the System. The set of all interesting scenarios that follow from the readCard stimulus message describes the readCard activity. It is also commonly called a Use Case.

    This scenario shows the message sequence when the Person leaves the Door open:

    Similarly: REJECT

    3.4.4: Validation sub-system
    Controller details

    CO-Card Only SystemDGR
    We begin designing the AccessControl subsystem. Our first observation is that there must be some equipment associated with each entry point for capturing Person identification and for controlling the Door lock. There must also be some equipment associated with the SystemManager for the management of access control data. Both stations will be realized as structures of roles, they are therefore shown as virtual in this collaboration view.

    We decide on a distributed design with a Controller/LocalStation at each entry point, and a Validator/CentralStation...

    3.4.5: Validation
    Normal access scenario
    Controller details

    a drawing
    Instantiation of Delay not shown in notes: Delay forSeconds:

    3.4.6: Inside object perspective
    Controller state diagram

    a drawing

    3.4.7: Inside object perspective
    A Controller Method

    a drawing

    3.5: Management subsystem (MS)

    a drawing

    3.5.1: Area of Concern
    MS Design Model

    a drawing

    3.5.2: Describe object structure
    MS Design Model

    AC-Manager RequirementsDGR

    3.6: Card access control system (CA)

    a drawing

    3.6.1: Synthesize from subsystems
    CA Design model

    CO-Card Only SystemDGR

    3.6.2: The Validator type satisfies
    COValidator and ManagementSubsystem
    Roles

    a drawing

    3.7: Summary
    First isolated application

    a drawing