Software requirements for TASTE GUI for Windows

From TASTE
Jump to: navigation, search

Introduction

This wiki page intends to be a draft Software Requirements Specification document for a system that will enable the use of the TASTE process under a Windows platform. All of its content has been elaborated by Peter Bradley under the supervision of Maxime Perrotin and Julien Delange as part of the PRESTIGE PROGRAMME for the ESA. A page is available for the Project Schedule.

Purpose

The purpose of this specification is to define in a concise and precise way all of the functionalities and restrictions of the Windows TASTE process system to be developed.

Scope

The development of this Windows GUI comes from the need to make available the TASTE toolset to a wider range of users. The idea is to provide a GUI to use TASTE where no special technical knowledge of TASTE is needed. The starting point consists on:

  • A Windows host.
  • A Debian TASTE GUI.
  • A console-based Debian virtual machine under QEMU with a network interface defined and a subset of the TASTE toolchain.
  • tasted (TASTE daemon) on the console-based Debian virtual machine.
  • TASTE-IV, TASTE-DV editors for Windows platforms developed by Ellidiss Technologies.

Definitions, acronyms, and abbreviations

Definitions

Acronyms

TASTE The ASSERT Set of Tools for Engineering
VM Virtual Machine
SRS Software Requirements Specification
IV Interface View
DV Deployment View
GUI Graphical User Interface

Abbreviations

References

IEEE Recommended Practice for Software Requirements Specifications. IEEE Std. 830-1998 (http://standards.ieee.org/findstds/standard/830-1998.html).

Overview

This wiki page consists on three sections. This introduction section that presents a general overview of the SRS. The overall description section which gives a general description of the main product functions, associated data, constraints, assumptions and dependencies that will affect the development of the product without getting into details. Finally, the specific requirements section that describes in a detailed way the requirements that the system must meet.

Overall Description

This section presents a high-level description of the system to be built.

Product perspective

The system on this first approach will interact with a remote machine running a console-based Debian with a subset of the TASTE toolchain installed and tasted running. Also with TASTE-IV and TASTE-DV editors for Windows as well as with a text editor. All of this will make it possible for the system to follow the TASTE process on a Windows host.

Product functions

In general terms the system will provide support for:

  • Establishing and maintaining a connection with a remote machine running a console-based Debian with a subset of the TASTE toolchain installed and tasted running.
  • Opening a text editor to edit the data view.
  • Opening the TASTE Interface Editor to edit the interface view.
  • Opening the directory that contains the functional code.
  • Opening the TASTE Deployment Editor to edit the deployment view.
  • Building a given fully defined TASTE project.
  • Managing TASTE projects in Windows.
  • Keeping the TASTE project synchronized with the remote machine running the TASTE subset.
  • Managing the TASTE process between the remote machine and the Windows host.

User characteristics

The user of the GUI must have a general knowledge on how the TASTE development process works.

Constraints

  • Communication with the remote machine will by managed by the TASTE daemon (tasted).
  • A GUI must be developed for the system.
  • The GUI's looks and functionality must be as close as possible as the Debian TASTE GUI.
  • The system's architecture will separate device dependent/independent modules.
  • A system GUI will be developed using the QT framework.
  • The programming language used for the development will be python.

Assumptions and dependencies

Assumptions

It is assumed that the requirements described in this wiki page are stable once they are approved either by Maxime Perrotin or Julien Delange. Any change to the specifications must be approved by either Maxime Perrotin or Julien Delange and by Peter Bradley. This change process will be handled by Peter Bradley.

Dependencies

The system highly depends on the remote machine with the TASTE subset installed and its connection with it to handle the TASTE workflow. Both the remote machine and the established connection must be correctly configured so that the system is able to perform its task.

Also, the system depends upon the Windows tools TASTE-IV (Interface view) and TASTE-DV (Deployment view).

Future requirements

As a future requirement the TASTE GUI to be developed will also need to run on GNU/Linux and Mac OS.

Specific Requirements

This section presents the requirements the system must satisfy. All of the requirements exposed in this section are essential, meaning that the system must comply with all of them. All of the requirements are in some way verifiable.

External Interfaces

User Interfaces

As stated previously a graphical user interface to use the system must be provided. This interface must be window-oriented and will work using a mouse and a keyboard.

Hardware Interfaces

None defined.

Software Interfaces

The system will interact with a remote machine running a console-based Debian with a subset of the TASTE toolchain installed and tasted running.

Communication Interfaces

The system will connect to the remote machine using the TCP/IP stack. By using sockets a point-to-point connection is established between the host Windows machine and the remote machine running a console-based Debian. This connection can be defined with the IP address and a PORT number for each of the machines. The TASTE daemon (tasted) manages this communication. A protocol to exchange messages between the two machines must be defined.

Functions

  • REQ01: The system will be able to connect with the TASTE daemon tasted of the remote machine given an IP address and a port. In case connection is not possible a second attempt is made a message will be shown if this retry did not succeed.
  • REQ02: The system will monitor the connection with tasted. In case it goes down an appropriate message will be presented by the system.
  • REQ03: The system will let the user start a project creating a tmp directory. The project will be set as the current project to edit.
  • REQ04: The system will let the user open an existing project by setting it as the current project to edit. If the archive file with the name of the project does not exist a message will be prompted. Also, if the selected project doesn't comply with the TASTE project format a message will be prompted.
  • REQ05: If no project is being edited the system will only let the user create or open a project.
  • REQ06: If a project is being edited the system will always let the user edit the Data View.
  • REQ07: Each time the user wants to edit the Data View the system will open an internal editor with dataview.asn from the project tmp directory. In case dataview.asn does not exist the system will create and open a predefined dataview.asn dummy file.
  • REQ08: When the system notices a change in the dataview.asn file the system sends the updated project archive file to tasted in order to receive a project archive file with dataview.aadl updated.
  • REQ09: If no project is being edited or if the tmp directory doesn't contain dataview.aadl the Interface View will not be available for editing.
  • REQ10: Each time the user wants to edit the Interface View the system will check if interfaceview.aadl exists in the tmp directory. If it doesn't it will simply call TASTE-IV. If it does it will then open TASTE-IV with interfaceview.aadl as parameter.
  • REQ11: If interfaceview.aadl and dataview.aadl are available the system will generate the code skeletons automatically. Skeletons will be generated sending tasted the project tar.gz file and requesting to create the skeletons. tasted will return the updated project tar.gz file and the associated message of success or failure. In case of success the system will enable the user to open the folder with the generated skeletons. In other case, a message will be shown to the user.
  • REQ12: If interfaceview.aadl and dataview.aadl Deployment View will be available for editing.
  • REQ13: Each time the user wants to edit the Deployment View the system will check if deploymentview.aadl exists in the project. If it doesn't it will simply call TASTE-DV. If it does it will then call TASTE-DV with deploymentview.aadl as parameter.
  • REQ14: Only when interfaceview.aadl, dataview.aadl and deploymentview.aadl are available in the tmp directory the system will enable the user to build the project. The project will be built by sending to tasted the project tar.gz file and requesting to build the system. tasted will return the updated project tar.gz file and the associated message of success or failure. In case of success the system will enable the user to open the folder with the generated binaries. In other case, a message will be shown to the user.

Performance requirements

None described.

Design constraints

The live cycle to develop the system will follow an evolutionary prototyping, meaning that new features and changes can be easily added. The main goal is to build a robust prototype in a structured manner and then constantly refine it.

Other requirements

TASTE project

A taste project is a .tar.gz file with the following file hierarchy:

  • dataview.asn (file written by the tool)
  • interfaceview.aadl (file generated by TASTE-IV)
  • deploymentview.aadl (file generated by TASTE-DV)
  • dataview.aadl (file generated from third party tools)
  • skels (folder generated from third party tools)
  • binary (folder generated from third party tools)

dataview.asn dummy file

TASTE-Dataview DEFINITIONS ::=
BEGIN

-- A few simple types to start with ASN.1
MyInteger   ::= INTEGER (0..255)

MyReal        ::= REAL (0.0 .. 1000.0)

MyEnum        ::= ENUMERATED { hello, world, howareyou }

MySeq        ::= SEQUENCE {
            a MyInteger,
            b ENUMERATED { taste(1), welcomes(2), you(3) }
}

MyChoice    ::= CHOICE {
            a BOOLEAN,
            b MySeq
}

MySeqOf        ::= SEQUENCE (SIZE (2)) OF MyEnum

MyOctStr    ::= OCTET STRING (SIZE (3))

-- You can also declare variables (they will be visible in C, Ada and RTDS)
myVar        MySeqOf    ::= { hello, world }
-- myVar2        MyChoice    ::= a:TRUE
END

Communication protocol

See here.

Links