User Cases for Executive Subsystem Preben Grosbol, 2003-10-31 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Executive package: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Use Case name: Exec_Startup Description: Before any computer controlled observation can be done with ALMA, the software systems have to be started and initiated. This Use Case illustrate a standard startup sequence of the full ALMA Observing System to the stage where an Operator can see the status of the entire system and commence observations of SchedBlocks. Actors: Primary: Operator Secondary: Database Priority: critical Performance: order of minutes Frequency: a few times per month Precondition: 1) The ALMA software system has been installed Basic course: 1) The Operator issues the startup command on an appropriate computer console. 2) The startup task verifies if CORBA services are available on the local system or starts them if they are not present. 3) The ACS manages is started on the local system. 4) The startup configuration file is read. It contains information on: a) components which have to be started and their order b) events which have to be monitored c) data-flow patterns which have to be checked 5) The Watchdog-Timer is started 6) A basic operator GUI is displayed and shows status of the initiation 7) Components indicated in the configuration file are started and initiated. 8) Error-Monitor is started to check events, errors and logs. 9) Exec Server component is initiated to provide other operator clients access to status information. 10) Operator registers with the Exec-server to obtain full control privileges. 11) Full operator GUI is displayed with active controls 12) The long term scheduler synchronization is started. 13) Access for other operator clients to login is made available. 14) All components are monitored periodically and status displayed. 15) Watchdog-Timer is reset periodically. Alternative course: 1) Parts of the components required do not initiate correctly. 2) Only basic status display are provided 3) Shutdown and initiation controls are active Postconditions: 1) The ALMA software system is running 2) The Operator GUI is available and display the system status 3) Operator can issue commands through the GUI 3) The system accepts external requests for Operator-Clients - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Use Case name: Exec_Shutdown Description: When maintenance or other changes have to be performed on the ALMA Observing System it is necessary to shutdown the entire system or the relevant part of it. This is shown by an Operator who first orders the shutdown of a particular subsystem and afterwards decides to close down the entire system. Actors: Primary: Operator Secondary: Database Priority: critical Performance: order of minutes Frequency: a few times per month Precondition: 1) ALMA software system is running 2) Main operator GUI is available. Basic course: 1) The Operator issues a shutdown command from the main operator GUI. 2) If observations are being done, the operator is asked to confirm the shutdown command 3) Scheduling is set to manual mode 4) Long term scheduling synchronization is terminated. 5) Shutdown commands (i.e. cleanUP()) are send to all subsystems and components in the order defined in the configuration file. 6) The states of all components are monitored and displayed on the operator GUI. 7) After all subsystems have been shutdown, all operator clients are disconnected. 8) Error-Monitor and Watchdog-Timer are shutdown. 9) All ACS services are terminated Alternative course: 1) If some components do not reach the DEFUNCT state within a defined timeout period, it is attempted to stop them with an abort command (i.e. aboutToAbort()). Postconditions: 1) ALMA software system has stopped 2) Operator GUI is in basic configuration indication subsystem - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Use Case name: Exec_OperLogin Description: It is possible for Operators to log into the system from any number of locations (e.g. outside the computer firewall) and monitor the system performance. The login sequence including possible acquisition of control privileges is shown by this Use Case. Actors: Primary: Operator Secondary: Database Priority: major Performance: order of seconds Frequency: a few times per day Precondition: 1) The ALMA software system is running. 2) The ALMA software is installed on system from which the remove operator access is requested. Basic course: 1) The Operator stars the client application 2) The availability of CORBA services it checked and started if needed 3) The connection to the main ALMA system is established by issuing a login request, which includes user-id and password, to the ExecServer 4) The ExecServer authenticates the user login request by comparing the information with the ALMA user database. 5) A access token is returned on successful. 6) The client requests the status information by registration for the specific information it wants at the ExecServer using its login token 7) Whenever new information is available to the ExecServer it will send an event to all client which have asked for it. 8) The client will request the new information when it receives the event. 9) The Operator may also request control privileges for a specific set of tasks (e.g. a sub-array control). 10) The Operator sends a control request to the ExecServer. 11) The ExecServer asked the main operator to confirm and accept the request. 12) If granted, a new token is issued which give control privileges 13) The remote operator issues the commands using the new token. Alternative course: 1) If the ALMA system does not accept remote operator clients an error message is issues and the process terminated 2) After three failed authentications, the application terminates. Postconditions: 1) The operator have access to a client GUI on the current system - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Use Case name: Exec_CheckSystem Description: When the ALMA Observing System is active it will continously check if all required resources are available. If malfunctions are detected the Operator is alerted. S/he can then try to solve problems e.g. by shutting down or re-initializing the relevant systems. Actors: Primary: Operator Secondary: Database Priority: critical Performance: order of seconds Frequency: a few times per week Precondition: 1) ALMA software system is running 2) ALMA Operator GUI is available Basic course: 1) The operator notice that a component/subsystem is in an error state as indicated by the operator GUI. 2) Looking on the error tree provided is determines which subsystems are effected. 3) The relevant components/subsystems are shutdown which may include suspension of observations. 4) Other maintenance actions are initiated (e.g. change of hardware) 5) The relevant subsystems are started again 6) The GUI indicates that all systems are operational. 7) Normal operations is resumed including start of observations Alternative course: 1) Standard re-initiation of components/subsystems does not solve the failure. 2) Full system is shutdown 3) Detailed error logs are analyzed 4) Appropriate patched are provided and system restarted. Postconditions: 1) Failing subsystem/component is working 2) Executive continues to monitor system performance - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Use Case name: Exec_SelectSB Description: The Operator can switch the scheduling system for SchedBlocks between dynamic and manual modes. One task of the Operator is to verify and possibly change the sequence of SchedBlocks proposed by the scheduling system. This Use Case illustrates this task. Actors: Primary: Operator Secondary: Database Priority: critical Performance: order of seconds Frequency: a few times per hour Precondition: 1) ALMA software system is running 2) Operator GUI is available 3) Scheduling is running and SB's are available in the database Basic course: 1) When the Scheduler is in dynamic scheduling mode it will present a ranked list of possible SB's to the Operator. 2) The Operator will select one of the SB's listed. 3) The SB's is sent to the Scheduler which will start it as the next SB's to be observed. Alternative course: 1) If the Operator does not respond before the timeout the highest ranked SB will be selected. 2) If no SB's are available for execution a warning will be issued. Postconditions: 1) The selected SB is being executed + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + UserAdmin package: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Use Case name: Create_AlmaUser Description: All user of the ALMA observing system must be authenticated and provided with appropriate access privileges before using the facilities. Thus, this information (and other required data such as name, affiliation, addresses and e-mail) must be available in the ALMA database. An administrator, with special privileges to modify user information, performs the task to create and modify the AlmaUser database. Actors: Primary: Administrator Secondary: Database with user information Priority: major Performance: order of seconds Frequency: a few times per week Precondition: 1) Database with AlmaUser information is available. 2) Administrator can be authenticated (e.g. by pre-loading the database with the information of the administrator). Basic course: 1) Administrator logs into the system and gets authenticated . 2) An empty AlmaUser object is created. 3) A UserID is selected. 4) This userID must be unique and is therefore checked against existing UserID's in the database. 5) The user is allocated to one or more privilege groups defined in the database. 6) Additional information (such as name, affiliation, e-mail) is inserted. 7) A default password is defined for the user. 8) The new AlmaUser object is added to the database. 9) Administrator logs out or continues with other related tasks. Alternative course: 1) Administrator fails the authentication. 2) The processing is terminated. Postconditions: 1) A new AlmaUser is created in the database. 2) A transaction log is saved. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Use Case name: Manage_UserInfo Description: The AlmaUser administration has access to three main types of information namely: 1) individual data on users, 2) individual data on resources, and 3) a list of valid groups. To keep information upto-date, the administrator must be able to change any data item. Further, s/he should be able to perform consistency checks e.g. usage of groups. Actors: Primary: Administrator Secondary: Database with user information Priority: major Performance: order of seconds Frequency: a few times per week Precondition: 1) Database with AlmaUser information is available. 2) Administrator can be authenticated (e.g. by pre-loading the database with the information of the administrator). Basic course: 1) Administrator logs into the system and gets authenticated . 2) S/he can choose look on user, group or/and resource information with the option of performing a search for a subset. 3) The selection information is displayed 4) The data can be modified. 5) Any modified data is saved in the database. 6) Administrator logs our or continues doing related work. Alternative course: 1) Administrator fails the authentication. 2) The processing is terminated. Postconditions: 1) A new AlmaUser is created in the database. 2) A transaction log is saved. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Use Case name: Modify_UserInfo Description: User information may have to be updated or modified. A user is allowed to change her/his own non-restricted data (i.e. affiliation, address and password) while only an administrator can modify restricted data such as name and group. As an API to change information exists, implementation security issues may be present and should be considered e.g. by verifying that only allowed fields has been changed. Actors: Primary: User, Administrator Secondary: Database with user information Priority: major Performance: order of seconds Frequency: a few times per week Precondition: 1) Database with AlmaUser information is available. Basic course: 1) User/administrator logs into the system and gets authenticated. 2) Depending on if it's a user or an administrator different privileges are granted i.e. a normal user can only modify standard fields of s/he own information while an administrator can modify any information. 3) The user information is shown (in the case of a normal user it will always be s/he own whereas an administrator can select the user for which data have to be modified. Password information is blanked out. 4) User/administrator modifies the data. For password changes, a confirmation is required. 5) The modified information is saved in the database 6) User/administrator logs out. Alternative course: 1) Authentication of user/administrator fails. 2) The processing is terminated. Postconditions: 1) Modified information on an AlmaUser is stored in the database. 2) A transaction log is saved. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + AlmaAdmin package: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Use Case name: Alma_TransferInfo Description: The ALMA Observing System will store most of its operational state information as logs in a database (e.g. changes, commands, errors and warnings). These data are stored in XML format defined by ALMA and not necessarily easy to ingest in the external tool (to be defined) which will be used for generation of operational reports and maintenance of the system. This Use Case illustrated the request by an administrator to get log information for a well defined time range ingested into the external administrative tool. Actors: Primary: Administrator Secondary: Database Priority: critical Performance: order of minutes Frequency: a few times per week Precondition: 1) ALMA archive is available for access to logging and error information 2) ALMA software is installed on system 2) The external administrative tool is available and running Basic course: 1) The administrator starts the AlmaAdmin tools 2) It verifies that it can connect to both the ALMA archive and the external administrative tool 3) The administrator specifies which kind of data should be transfered and for which time period. 4) AlmaAdmin requests the requested data from the archive 5) The data are re-formatted to suit the external administrative tool and submitted to it. 6) A summary of the transfer is provided to the administrator. Alternative course: 1) If no connection can be established to either the archive or the external tool, the application terminated with an error message. 2) If no data are available for the request, a warning is issued. Postconditions: 1) New information is ingested into the administrative tool + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Security package: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Use Case name: Secu_VerifyUser Description: When users want to perform privileges actions (e.g. controlling to observing sequence) they have to be authenticated before they are granted permission. Actors: Primary: User, User application Secondary: Database Priority: critical Performance: fraction of second Frequency: several times per second Precondition: 1) ALMA archive is available for access to user data 2) ALMA software services are available Basic course: 1) When a user/application requires privileges it has to be authenticated by giving a valid UserId/password combination. 2) The password is encrypted locally. 3) UserId and encrypted password are then compared with the information in the user database 4) If the comparison is successful, the user/application of given the privileges associated to the groups associated to the user. Alternative course: 1) If the comparison fails an exception is thrown. Postconditions: 1) User is authenticated