Use cases

The current implementation focused on 2 use cases: edit an assembly file, and run the assembler. A third use case would be interact with the development board; currently, only a preliminary effort is included for this use case (the codebender serial monitor is borrowed using a single HTML iframe, and is not as within the scope of the IDE as, for example, debugger integration). A unimplemented fourth use case is the ability to upload an assembled program (S-Record) to the development board. These four use cases correspond to four commands that a programmer typically runs when developing for any similar microcontroller: run a text editor, invoke the compiler or assembler, download the program to the microcontroller, then interact with the microcontroller using a terminal emulator.

Download use case diagram as SVG Download use case diagram as PDF

Use case: Edit assembly file

Scope: Web S12 IDE (web page)
Level Primary actor: Programmer
Stakeholders and interests:

• Programmer: Must be able to make changes as needed to their assembly file. Does not want changes to be lost unexpectedly. Wants a familiar, intuitive way of creating, opening, editing, and saving assembly files. Wants an editor that has sufficient features that enable effective programming (e.g. clipboard, search, undo management). Wants the editor to be fast, "responsive".
• Administrator: Wants the Web S12 IDE and required functionality to remain available to Programmer. Preconditions: Web page is open and programmer has existing assembly file ready (if any). Success guarantees: Programmer has all changes made to their assembly file saved to a file stored locally on their computer.

Main success scenario:

1. Programmer creates new file or opens existing file in assembly editor.
2. The IDE populates the editor with the contents of the file being edited.
3. Programmer interacts with editor to makes some changes.
4. After some changes, the Programmer saves a backup modified assembly file.
5. The IDE instructs the Programmer's web browser to save the editor's contents to a file on the Programmer's computer.
6. The Programmer specifies how to handle the download (e.g. where to save, whether to open; browsers such as Chrome download without prompting).
   Programmer repeats steps 3-6 until the final version has been saved. Programmer can proceed directly to use case "Run assembler" or start editing a different assembly file.

Extensions/alternate flows:

1a. The programmer is opening an existing file rather than creating a new file:

1. the Programmer interacts with the "Open file…" dialog that appears. (The appearance and steps depends on which web browser and operating system is used by the Programmer.)
   1b. The editor contains "unsaved changes" (i.e. the undo manager is not marked clean):
2. The IDE shows a prompt asking the Programmer whether to cancel editing a different file, or discard unsaved changes and proceed.
   1a. Programmer asks to discard unsaved changes.
   1. The IDE continues to step 2.
   1b. Programmer asks to cancel editing a different file.
   1. The IDE retains editor's current contents and does not proceed with this use case.

3a. Programmer attempts to Edit different assembly file. (This is the same as 1b., occurring from the perspective of this use case being started again concurrently.)

1. The IDE shows a prompt asking the Programmer whether to cancel editing a different file, or discard unsaved changes and proceed (same prompt appearing for 1b.)
   1a. Programmer asks to discard unsaved changes.
2. The IDE discards the editor's contents and does not proceed with this use case.
   1b. Programmer asks to cancel editing a different file.
3. The system retains editor's current contents proceeds waits for steps 3a or 4.

3b. Programmer navigates away from web page

1. IDE prompts Programmer asking whether to cancel navigating or discard unsaved changes and or proceed with navigating
   1a. Programmer asks to discard unsaved changes.
2. The IDE discards the editor's contents and allows browser to navigate, and does not proceed with this use case.
   1b. Programmer asks to cancel navigating.
3. The IDE retains editor's current contents and proceeds with use case.

6a. Programmer navigates away from web page

1. IDE allows navigating away from web page and does not proceed with use case. (The editor's undo manager was marked clean in step 5; no unsaved changes are lost.)

Special requirements:

• Programmer is using modern desktop web browser (e.g. Chrome, Firefox) with JavaScript enabled.
• Programmer has access to server and CDNs used for third party components (e.g. Ace editor; i.e. additional resources are functional and not blocked by firewall filter).

Technology and data variations list: Not specified.
Frequency of occurrence: Variable. Lower bound: one file every few minutes; upper bound: one file every few days.
Open issues:

• How to handle repeated saving more efficiently? (See discussion in future work.)

Use case: Run assembler

Scope: Web S12 IDE (web page, server)
Level Primary actor: Programmer
Stakeholders and interests:

• Programmer: Wants minimal turnaround time for obtaining results from the assembler. The assembler output should match the output of a locally run assembler and be compatible with the Development board.
• Administrator: Wants the Web S12 IDE and required functionality to remain available to Programmer.
  Preconditions: The Programmer has the file for assembling open in the editor, and the IDE web page can communicate with the IDE server.
  Success guarantees: The Programmer has assembled version of their program (S-Record file) stored locally on their computer; the Programmer is able to inspect the list file; the Programmer is able to inspect the messages output from the assembler.
  Main success scenario:

1. Programmer invokes assembler.
2. IDE web page sends editor contents (assembly file) to the server
3. IDE server receives assembly file.
4. IDE server runs assembler on received file.
5. IDE server sends response containing assembled program (S-Record), list file, and assembler messages
6. IDE web page receives response and populates viewers for list file and assembler messages
7. Programmer inspects list file and assembler messages
8. Programmer requests S-Record
9. IDE web page saves S-Record as download
10. Programmer specifies how to handle the download (e.g. where to save, whether to open; browsers such as Chrome download without prompting).

Extensions/alternate flows:

7a. Programmer observes errors reported by the assembler in the list file or assembler messages.

1. The programmer returns to the editor to make necessary changes (beginning at step 3 of use case "Edit assembly file").

Special requirements:

• Development board is compatible with the S-Record being generated. The assembler is currently configured to generate S-Records compatible with the Dragon12 boards running D-Bug12 v4.
• Programmer is using modern desktop web browser (e.g. Chrome, Firefox) with JavaScript enabled.
• Programmer has access to server and CDNs used for third party components (e.g. Ace editor; i.e. additional resources are functional and not blocked by firewall filter).

Technology and data variations list: Not specified
Frequency of occurrence: Variable. Lower bound: every minute as small changes are made; upper bound: every few days between work on a program.
Open issues:

• There is no syntax highlighting in the list file viewer, so the location of errors can be difficult to spot without using the viewer's find feature.
• If there is no connectivity to the server, then steps 1-2 fail without notifying the user; the list file viewer, assembler message viewer, and previous S-Record are retained by the IDE web page. (Opened as GitHub issue #7.)