SecSysController: Hand-Off Model

Edit online

For this tutorial, the Hand-Off model for the SecSysController is used. This model has been developed from the initial requirements following the Harmony process. The engineering of the Security System is the continuous example used in the "System Engineering Best Practices with the Rational Solution for Systems and Software Engineering Deskbook" (Release 4.1) by Hans-Peter Hoffmann. The Hand-Off model SecSysController is the final result of the design synthesis phase.

The model has been slightly modified for the needs of this tutorial. Instead of using OMString for card validation status and for biometric scan result throughout the model, appropriate enumeration types have been introduced. For clarity, the functional and non-funtional requirements have been grouped in separate packages.

Note that the project type of the model is SysML. The project refers to the SysML profile and to the HarmonySE profile.

Structure of the model

  • In package RequirementAnalysisPkg the requirements imported from requirement capturing tool IBM Rational DOORS can be found. According to the classification into functional requirements and non-functional requirements have been stored in separate sub-packages.

    The requirements have been allocated to use cases in the requirement analysis phase. These use cases formed the basis of creation of executable models for the individual use cases in the system functional analysis phase.

    Event though these executable models have been merged and the resulting model has been decomposed during the design synthesis phase, the requirements have been kept in the models of all engineering phases.

    Note that the requirements are referenced by various model elements via dependencies - the result of allocating requirements to model elements in the respective engineering phases.

  • Package ActorsPkg contains the components forming the environment of the essential controller of the Security System. In order to emphasize that these components aren't integral part of respective system under consideration, they have been modeled as actors with dedicated port interfaces with the SecSysContoller (cf. Harmony-Remarks).

    • Admin: This actor represents rather the administrator control than a real administrator. Admin is alarmed on denied entry or exit notification due to card validation or biometric scan failure (after 3 failed attempts). Admin is needed to reset alarm if system locks after raising an alarm.

    • Camera: takes a photograph of user when first attempting to validate the security card on entering the access point.

    • AccessPoint: the access point to the secured area. AccessPoint can be requested to lock and unlock the access to the secured area. On changing its status, AccessPoint indicates its status change by sending an either evAccessPointUnlocked or evAccessPointLocked.

    • CardReaderEntry: The card reader at the entry of the access point. Can request SecSysController to validate a security card. SecSysController will request CardReaderEntry to display the card status in reaction.

      In case of 3 failed attempts to validate a security card, SecSysController will request CardReaderEntry to indicate an alarm. If the alarm is reset by Admin, SecSysController will request CardReaderEntry to reset the alarm indication.

    • CardReaderExit: Similar actor at the exit of the access point of the secured area.

    • FingerprintScanner: biometric scan can be enabled via event reqEnableBiometricScan and disabled via reqDisableBiometricScan. If within a certain interval the fingerprint scan has been performed, FingerprintScanner indicates the authentication status by sending retAuthenticationStatus (AuthenticationStatus_T AuthenticationStatus). If fingerprint scan could not be finished within the time interval, evBsTimeout indicates a timeout.

  • Package DesignSynthesisPkg contains the actual Hand-Off model of sub-system SecSysController.:

    • Block Definition DiagramBDD_SecSysCoontroller shows the logical structure of the model in principle. Note that the associations in the diagram are of no interest w.r.t. the behavior of the model.
    • Internal Block DiagramIBD_SecSysController shows the factual communication infrastructure of the model, i.e. the actors with their ports connected to the ports of the SecSysController.
    • SecSysControllerPkg contains the SecSysControllet itself.
    • ExecutionScopePkg contains the instance declarations of actors and SecSsysController with the links connecting the ports of the instances according to Internal Block DiagramIBD_SecSysController. These instances are needed for interactive execution of the model.
    • Finally, SecSysDControllerHandOff_SD contains relevant scenarios showing typical execution sequences of the system. These scenarios are integral part of the Hand-Off model. Together with the model itself, they serve as specifications for subsequent development.

  • All interface definitions used in the contracts of ports as well as the events communicated among actors and SecSysController are collected in package InterfacesPkg.

  • Package TypesPkg contains the enumeration types enum AuthenticationStatus_T { NotAuthenticated, Authenticated } and enum CardStatus_T { NotValid, Valid }. These enumerations are used instead of the representation of both stati by OMString in the original model.

  • Package RequirementCoverageAnalysis contains two stereotypes for linking model elements to requirements. Their meaning will be explained later in this tutorial. They were introduced for dealing with the fact, that some requirements had been allocated to 'model elements without observable behvior', i.e. to classes, attributes, events, e.t.c. When measuring requirement coverage of a particular execution of the model on the basis of activated model elements (entering a state, invoking an operation, taking a transition, e.t.c.) there is no unique interpretation of e.g. 'activating an attribute'. Does the pure existance of the attribute 'satisfy' the requirement? For non-functional requirements, the answer could be yes. But for functional requirements, a more dynamic interpretation is needed, such as 'the value of the attribute contributes to a decision', 'the attribute is assigned a particular value', e.t.c.

    The stereotypes in package RequirementCoverageAnalysis are used to refine 'satisfy' relations in a well defined way, in order to base requirement coverage on this refinement.