System Requirements COSE. Helsinki 8th December 2004 Software Engineering Project UNIVERSITY OF HELSINKI Department of Computer Science

Transcription

1 System Requirements COSE Helsinki 8th December 2004 Software Engineering Project UNIVERSITY OF HELSINKI Department of Computer Science

2 Course Software Engineering Project (6 cr) Project Group Pekka Enberg Laura Kataja Oskari Ojala Juha Ojaluoma Miikka Sauramo Timo Toikkanen Client Otso Virtanen Project Masters Juha Taina Turjo Tuohiniemi Homepage Change Log Version Date Modifications End of project, final version Preview release version Version Version Updates based on client comments Incorporated client comments. Final draft Reviewed version. Sent to the client First draft.

3 Contents i 1 Introduction Document Structure Glossary Open Issues System Overview of the System Stakeholders System Architecture External System Interfaces Context Server Data Export Tool Execution Environment Production Environment Development Environment Use Cases Server Receiving Context Data Sending Data to Terminal Exporting Context Data to Filesystem User Interface Logging In Logging Out Browsing Context Data Deleting Context Data Functional Requirements Server User Interface Non-Functional Requirements Robustness

4 ii 5.2 Scalability Maintainability Security Communication Quality Assurance Unit Testing Integration Testing System Testing Acceptance Testing Appendices 18 References 18

5 1 Introduction 1 This is the specification of requirements for the Context Server. The document will specify the external system behavior and the constraints on the implementation. The requirements specification has a number of users. The project group will use this document to understand the system that is to be developed. Furthermore, this specification will serve as a contract between the project group (COSE) and the client (HIIT/BRU). System maintainers may also use this document as a reference tool. 1.1 Document Structure This section has an overview of the remainder of this document. In Chapter 2, the reader will given an overview of the system. We will describe the system, show its stakeholders, give an overview of the system architecture, and describe its execution environment. In Chapter 3, we go through use cases for the context server. In Chapter 4, we present functional requirements for the context server. In Chapter 5, we present non-functional requirements such as performance, usability, and maintenance. Finally, in Chapter 6, we go through the quality assurance requirements for unit, integration, and acceptance testing. 1.2 Glossary Ant Apache Ant is a Java-based build tool. It is similar to Make but is written in the Java language and intended for use with Java. J2EE The Java 2 Platform, Enterprise Edition is a set of coordinated specifications and practices for developing distributed Multi-tier architecture applications, based on modular components. J2EE is a registered trademark of Sun Microsystems, Inc. JBoss JBoss is an open source, J2EE based application server implemented in Java. JBoss is a registered trademark of JBoss, Inc. JUnit JUnit is a testing framework for Java. The structure of test cases and tools to run them are provided by JUnit. Maven Apache Maven is a project management and project comprehension tool for Java. Maven borrows most build tasks from Ant. Series 60 The Series 60 Platform is a suite of libraries and applications for mobile phones. It is built on the Symbian OS by Nokia. Series 60 mobile phones allow new applications to be installed. Various manufacturers have licensed the product.

6 2 Subversion Subversion is a version control system similar to CVS. SOAP Simple Object Access Protocol is an XML-based definition which can be used to make remote procedure calls over the Internet. WEKA Weka is a collection of machine learning algorithms in Java. The algorithms can be called from Java code or user interfaces in Weka. XML Extensible Markup Language is a text format derived from SGML. It can be used for storing, combining, exchanging and publishing information. XML is specified by World Wide Web Consortium. 1.3 Open Issues None 2 System Overview 2.1 of the System This project produces a Context Server that stores, shares, and archives contextual data. The server bridges the gap between sensing and interpreting the context. Context history can be used to establish trends and predict future context values. The client (HIIT/BRU) has a need for context server in upcoming projects. The server provides a sensor independent context acquisition interface. The communication between the server and clients is XML formatted that is specified by this project. A Series 60 terminal client that talks to the Context Server will be implemented by HIIT/BRU in the future. The server offers a subscription service that provides access to context history. A serverside application can make predictions of the context for the clients using data that has been received earlier. These predictions can be used by the terminals directly or by an application inside them. 2.2 Stakeholders There are the following stakeholders to the Context Server: Terminal User Administrator

7 3 Terminal The terminal sends context data to the server using SOAP. It will be implemented by HIIT/BRU in the future. The user browses context data stored on the server that has been sent by her ter- User minal. Administrator The administrator browses stored context data sent by all terminals and manages the server. 2.3 System Architecture The Context Server is responsible for receiving context data, validating, parsing, and storing it to the database. It also allows users and administrators to browse and delete data that is stored on the server. The server provides a notification mechanism of arrived context data for external systems. An export mechanism is also provided for external systems. System architecture is illustrated in [Figure 1]. External System Invokes Context Data DTD Context Server (JBoss) Terminal Sends context data Context Listener Validator Data Queue Filesystem Exports to Security Plug-In Data Export Tool User Interface Parser Notify Queue Notifies Browses and deletes data User or Administrator Database Figure 1: System Architecture The execution sequence for Context Listener is as follows: 1. Terminal sends context data 2. Context Listener authenticates and authorizes the terminal ID with Security Plug-in 3. Context Listener validates the XML document with the Validator 4. Validator puts valid context data to the Data Queue

8 4 5. Parser picks up the context data from the Data Queue [Figure 2] depicts a UML sequence diagram of the Context Listener. Context Listener Security Plug-in Validator Parser Context Data authorize Terminal validate Figure 2: Sequence Diagram External System Interfaces This section describes external system interfaces for the Context Server. Context Data DTD Context Data DTD is the definition for valid XML documents that are used to transmit context data from terminals to the Context Server. The DTD is specified as part of this project. Context Listener Context Listener receives SOAP messages that contain context data. The listener first checks terminal identity with the Security Plug-in and after that gives the XML document to the Validator for verification. User Interface User Interface allows users and administrators to browse and delete context data that is stored on the server through an HTTP/HTML interface. The user is first authenticated with the Security Plug-in.

9 Notification Queue Notification Queue exposes a mechanism for external systems to obtain a notification when new context data has been parsed and stored into the database. The queue contains a notification with an unique ID for the received request. It does not include the actual data within the notification message Context Server This section describes internal Context Server components. Data Queue Data Queue is used to store validated context data temporarily before it is parsed. As the context data is queued, the Context Listener closes SOAP connection to the terminal after validation. Security Plug-in Security Plug-in is responsible for authentication and authorization of incoming SOAP and plain HTTP requests. It can delegate the actual work to an external system. Validator Validator uses XML schema to ensure that received context data follows the Context Data Format. Valid data is put to the Data Queue and invalid data is rejected. Parser Parser is responsible for parsing a Context Data Format document and storing the data into database. Upon completion, it sends a message to the Notification Queue so external systems are aware of the new data Data Export Tool Data Export Tool is an application for exporting context data into Flat File Format and WEKA Attribute-Relation File Format. It polls the Notification Queue. After notification, context data is retrieved from the database and exported to the filesystem. 2.4 Execution Environment The execution environment describes production and development environments for the Context Server. The production environment is the collection of software that is used to run and use the server. The development environment are the additional software, tools, and libraries that are used to develop the Context Server Production Environment For production, the following software is used:

10 6 Computer Science Linux (CSL) # Operating system Sun Java(TM) 2 Runtime Environment, Standard Edition Java run-time JBoss Application Server Application server Development Environment For development, the following tools and libraries is used in addition to the production tools: Apache Ant Build tool Apache Maven Build tool Eclipse SDK Integrated development environment for Java JUnit Unit testing framework for Java Subversion Version control software 3 Use Cases This chapter describes the use cases of the Context Server. The actors are the following: Administrator System administrator. External System System that is executed outside of the application server. Server Context Server. Terminal Series 60 mobile phone. User The owner of the terminal. 3.1 Server Receiving Context Data Actors Server Terminal External System

11 7 Precondition The terminal is running. The server is running. The terminal sends context data to the server. The server authenticates the terminal. The server validates the context data. The server stores the original XML context data into the database. The server parses the context data. The server stores the parsed data into the database. The server notifies external system that new data has been received. Exceptions The terminal is unknown. An error is sent to the terminal. The context data is invalid. An error is sent to the terminal. Postcondition New context data is stored in the database. External system has been notified of the received data Sending Data to Terminal Actors Server Terminal External system Precondition

12 8 The server is running. The server delivers data to an external system. The external system sends data to the terminal. The terminal receives the data. The terminal acknowledges the external system. Exceptions The terminal cannot be reached. The error is logged. Postcondition Data has been transferred from server to terminal Exporting Context Data to Filesystem Actors External System Server Precondition The external system is running. The external system receives notification of new context data. The external system retrieves context data from the server. The external system exports the data to the filesystem. Exceptions The server cannot be reached. An error is logged in the external system logs. The notification has an invalid context data ID. An error is logged in the external system logs. Postcondition Context data is exported to the filesystem.

13 9 3.2 User Interface Logging In Actors User Server Precondition The server is running. The user enters the terminal ID. The server authenticates the terminal ID. Exceptions The terminal ID is invalid. The user is not authenticated. Postcondition The user is authenticated Logging Out Actors User Server Precondition The server is running. The user is logged on.

14 10 The user logs off from the system. The server removes the user session. Exceptions The user session does not exist. The user is logged off. Postcondition The user is logged off Browsing Context Data Actors User Server Precondition The server is running. The user is logged on. The user chooses to browse her context data. The server retrieves context data that is owned by the terminal ID of the user. The server displays retrieved context data. Exceptions The administrator can browse all context data. Postcondition

15 Deleting Context Data Actors User Server Precondition The server is running. The user is logged on. The user is browsing context data. The user selects the content of a context message for deletion. The server asks for user confirmation before the deletion. The server deletes the context data. Exceptions The selected context data no longer exists. An error is logged in the server logs. The administrator can delete all context data. Postcondition Context data is removed from the database. 4 Functional Requirements 4.1 Server Number 1 Receiving data from terminal, DAC.01 The server receives SOAP message with XML formatted context data. XML format follows the example given in [Xml04]. The format is defined using DTD or Schema. [Vir04], Pekka, Juha, Timo

16 Number 2 Exporting to Attribute-Relation File Format (ARFF) The server exports context data in Attribute- Relation File Format. [Pay04] Medium Pekka Number 3 Exporting to Flat File Format Format The server exports context data in Flat File Format such as B-Course Data Format. [Cos02] Medium Pekka Number 4 Validating the XML formatted context data The server validates XML formatted context data. Invalid XML is rejected. Timo Number 5 Storing received data, DAC.01 Every valid XML message is stored into the server database. The actual SOAP message is not stored. [Vir04], Pekka, Juha, Timo Number 6 Parsing XML context data The server can parse XML formatted context information according to a DTD. Timo 12

17 Number 7 Possibility to add a component for sending context data The context server provides interfaces for a component that sends predicted context data to clients. The actual component is out of the scope of Cose project group. The extension would probably work as follows. A client terminal polls the server for predicted context data via SOAP. The client is authenticated. Context data is sent to the terminal. Medium Timo Number 8 Client terminal remains authorised until XML has been validated The SOAP connection remains open, i.e. the client is authorised, until the XML context data has been validated. Timo User Interface Number 9 User interface for browsing and deleting personal context data, UI.01 The server provides a Web interface for terminal users. Users can browse and delete their personal context data. The interface is Web based. Low [Vir04], Pekka, Juha, Timo Number 10 Administrator user interface for browsing and deleting context data, UI.02 The server provides a Web interface for administrators. Administrators can browse and delete context data. The interface is Web-based. Low [Vir04], Pekka, Juha, Timo

18 5 Non-Functional Requirements Robustness Number 11 Receiving data with unknown fields Server receives data with unknown fields without failing. The received data is stored into the database. Juha Number 12 Unknown Format for Received Data The server rejects all context data that is in unknown format. Pekka 5.2 Scalability Number 13 Scalable Parser The server has a scalable parser component. The architecture allows a number of parser instances executed in parallel, possibly in a clustered configuration. Clustered configurations will not be tested. Timo, Pekka 5.3 Maintainability Number 14 Modularity and Clean Interfaces The server is modular and has clean extensible interfaces for future development. Juha, Pekka

19 Number 15 External Documentation The project produces the following documents for the Context Server: System Requirements, Design Document, Test Document, User Manual. Juha, Pekka Number 16 Documentation The source code has JavaDoc comments for all public classes and public methods. Juha, Pekka Number 17 Programming Language The Java programming language is used in the implementation of all Context Server components. Juha, Pekka Number 18 The database must be able to adapt to different XML formats In the future the XML format for context data may be modified. The database must be able adapt as conditions change. Timo Security Number 19 Terminal Identity Every terminal has an ID that is tracked by the Context Server. The ID is used for authentication and authorization. Pekka

20 16 Number 20 User rights A user can only browse data sent by his terminal. Juha Number 21 Administrator rights Administrators can browse all stored data. Juha 5.5 Communication Number 22 Context Data Format The DTD for context data is specified following the example given in [Xml04]. The DTD can be changed later. Juha, Timo Number 23 Server client Server client interface is implemented using HTTP 1.0. Juha Number 24 Terminal client Terminal client interface implements the SOAP protocol Juha 6 Quality Assurance This chapter presents quality assurance requirements. The requirements are divided into four categories as follows: Unit testing Integration testing

21 17 System testing Acceptance testing There is a section for each of the above category in which we will give an definition for the requirement. The project group will provide a separate Test Document for further details. 6.1 Unit Testing A unit test is an automated method of testing the correctness of a particular module of source code. Requirements: Automated with JUnit or equivalent testing framework 100% line coverage as measured with jcoverage Sets up required execution environment (database, application server) automatically as part of the test set up 6.2 Integration Testing An integration test is an automated test for the software to ensure that all components work together. Requirements: Automated with JUnit or equivalent testing framework Tests software end-to-end 6.3 System Testing A system test is a manual test to ensure that the software satifies the requirements specification in the actual hardware environment. Requirements: Executed by the project team. Reproducible after the delivery. That is, the test cases are documented. There is no requirement to test clustered configuration.

22 Acceptance Testing An acceptance test is a manual test for the software executed by the customer to ensure the system performs as expected. Requirements: Executed by the client. Signed off by the client. 7 Appendices 1. Specification of Flat-File Format 2. Paynter, G., Attribute-Relation File Format, 2004 References Cos02 CoSCo, B-course: Data format specification, hiit.fi/format.html. [ ] Pay04 Paynter, G., Attribute-relation file format, waikato.ac.nz/~ml/weka/arff.html. [ ] Xml04 Vir04 Virtanen, O., DEVICE2COSE_interface.txt. Virtanen, O., Requirements for Contex Server (COSE).