From ca7dbccf8b3c9c46f8f708a9b561d8f57d36d426 Mon Sep 17 00:00:00 2001 From: "Michael D. Lowis" Date: Fri, 21 Feb 2020 16:29:23 -0500 Subject: [PATCH] updated docs --- Arch.adoc | 195 ++++++++++++++++++++++++++++++++++++++++++++++++ README.adoc | 44 +++++++++++ src/tide.1.adoc | 43 ++++++++--- src/tide.c | 3 +- 4 files changed, 274 insertions(+), 11 deletions(-) create mode 100644 Arch.adoc diff --git a/Arch.adoc b/Arch.adoc new file mode 100644 index 0000000..4604495 --- /dev/null +++ b/Arch.adoc @@ -0,0 +1,195 @@ += Tide Software Architecture +:toc: + +== Introduction + +Asciidoc recreation of the following example: +https://www.ecs.csun.edu/~rlingard/COMP684/Example2SoftArch.htm#introduction + +=== Purpose + +This document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made on the system. + +=== Scope + +This Software Architecture Document provides an architectural overview of the C-Registration System. The C-Registration System is being developed by Wylie College to support online course registration. + +This Document has been generated directly from the C-Registration Analysis & Design Model implemented in Rose. The majority of the sections have been extracted from the Rose Model using SoDA and the Software Architecture Document template. + +=== Definitions, Acronyms and Abbreviations + +*None* + +=== References + +*None* + +== Architectural Representation + +This document presents the architecture as a series of views; use case view, logical view, process view and deployment view. There is no separate implementation view described in this document. These are views on an underlying Unified Modeling Language (UML) model developed using Rational Rose. + +== Architectural Goals and Constraints + +There are some key requirements and system constraints that have a significant bearing on the architecture. They are: + +. The existing legacy Course Catalog System at Wylie College must be accessed to retrieve all course information for the current semester. The C-Registration System must support the data formats and DBMS of the legacy Course Catalog System [2]. +. The existing legacy Billing System at Wylie College must be interfaced with to support billing of students. This interface is defined in the Course Billing Interface Specification [1]. +. All student, professor, and Registrar functionality must be available from both local campus PCs and remote PCs with internet dial up connections. +. The C-Registration System must ensure complete protection of data from unauthorized access. All remote accesses are subject to user identification and password control. +. The C-Registration System will be implemented as a client-server system. The client portion resides on PCs and the server portion must operate on the Wylie College UNIX Server. [3] +. All performance and loading requirements, as stipulated in the Vision Document [3] and the Supplementary Specification [15], must be taken into consideration as the architecture is being developed. + +== Use-Case View + +A description of the use-case view of the software architecture. The Use Case View is important input to the selection of the set of scenarios and/or use cases that are the focus of an iteration. It describes the set of scenarios and/or use cases that represent some significant, central functionality. It also describes the set of scenarios and/or use cases that have a substantial architectural coverage (that exercise many architectural elements) or that stress or illustrate a specific, delicate point of the architecture. + +The C-Registration use cases are: + +- Login +- Register for Courses +- Maintain Student Information +- Maintain Professor Information +- Select Courses to Teach +- Submit Grades +- View Report Card +- Close Registration. + +These use cases are initiated by the student, professor, or the registrar actors. In addition, interaction with external actors; Course Catalog and Billing System occur. + +=== Architecturally-Significant Use Cases + +[plantuml] +.... +usecase Login +actor User +actor Student +actor Professor +actor Registrar +actor "Course Catalog" as Catalog +actor "Billing System" as Billing + +usecase "View Report Card" as UC1 +usecase "Register for Courses" as UC2 +usecase "Select Courses to Teach" as UC3 +usecase "Submit Grades" as UC4 +usecase "Maintain Professor Information" as UC5 +usecase "Maintain Student Information" as UC6 +usecase "Close Registration" as UC7 + +User -up-> Login +Student -left-> User +Student -right-> UC1 +Student -right-> UC2 +Professor -left-> User +Professor -right-> UC3 +Professor -right-> UC4 +Registrar -left-> User +Registrar -right-> UC5 +Registrar -right-> UC6 +Registrar -right-> UC7 + +UC2 -right-> Catalog +UC3 -right-> Catalog +UC7 -right-> Billing + +Student -[hidden]- Professor +Student -[hidden]- Registrar +Professor -[hidden]- Registrar +Registrar -[hidden]- Student +UC1 -[hidden]- UC2 +UC2 -[hidden]- UC3 +UC3 -[hidden]- UC4 +UC4 -[hidden]- UC5 +UC5 -[hidden]- UC6 +UC6 -[hidden]- UC7 +Catalog -[hidden]- Billing + +.... + +== Logical View + +A description of the logical view of the architecture. Describes the most important classes, their organization in service packages and subsystems, and the organization of these subsystems into layers. Also describes the most important use-case realizations, for example, the dynamic aspects of the architecture. Class diagrams may be included to illustrate the relationships between architecturally significant classes, subsystems, packages and layers. + +The logical view of the course registration system is comprised of the 3 main packages: User Interface, Business Services, and Business Objects. + +The User Interface Package contains classes for each of the forms that the actors use to communicate with the System. Boundary classes exist to support login, maintaining of schedules, maintaining of professor info, selecting courses, submitting grades, maintaining student info, closing registration, and viewing report cards. + +The Business Services Package contains control classes for interfacing with the billing system, controlling student registration, and managing the student evaluation. + +The Business Objects Package includes entity classes for the university artifacts (i.e. course offering, schedule) and boundary classes for the interface with the Course Catalog System. + +=== Architecture Overview - Package and Subsystem Layering + +* DIAGRAM HERE * + +== Process View + +A description of the process view of the architecture. Describes the tasks (processes and threads) involved in the system's execution, their interactions and configurations. Also describes the allocation of objects and classes to tasks. + +The Process Model illustrates the course registration classes organized as executable processes. Processes exist to support student registration, professor functions, registration closing, and access to the external Billing System and Course Catalog System. + +=== Processes + +* DIAGRAM HERE * + +=== Process to Design Elements + +* DIAGRAM HERE * + +=== Process Model to Design Model Dependencies + +* DIAGRAM HERE * + +=== Processes to the Implementation + +* DIAGRAM HERE * + +== Deployment View + +A description of the deployment view of the architecture Describes the various physical nodes for the most typical platform configurations. Also describes the allocation of tasks (from the Process View) to the physical nodes. + +This section is organized by physical network configuration; each such configuration is illustrated by a deployment diagram, followed by a mapping of processes to each processor. + +* DIAGRAM HERE * + +=== External Desktop PC + +Students register for courses using external desktop PCs which are connected to the College Server via internet dial up. + +=== Desktop PC + +Students register for courses via local Desktop PCs that are connected directly to the College Server via LAN. These local PCs are also used by professors to select course and submit student grades. The Registrar uses these local PCs to maintain student and professor information. + +=== Registration Server + +The Registration Server is the main campus UNIX Server. All faculty and students have access to the Server through the campus LAN. + +=== Course Catalog + +The Course Catalog System is a legacy system that contains the complete course catalog. Access to it is available via the College Server and LAN. + +=== Billing System + +The Billing System (also called the Finance System) is a legacy system that generates the student bills each semester. + +== Size and Performance + +The chosen software architecture supports the key sizing and timing requirements, as stipulated in the Supplementary Specification [15]: + +The system shall support up to 2000 simultaneous users against the central database at any given time, and up to 500 simultaneous users against the local servers at any one time. +The system shall provide access to the legacy course catalog database with no more than a 10 second latency. +The system must be able to complete 80% of all transactions within 2 minutes. +The client portion shall require less than 20 MB disk space and 32 MB RAM. +The selected architecture supports the sizing and timing requirements through the implementation of a client-server architecture. The client portion is implemented on local campus PCs or remote dial up PCs. The components have been designed to ensure that minimal disk and memory requirements are needed on the PC client portion. + +== Quality + +The software architecture supports the quality requirements, as stipulated in the Supplementary Specification [15]: + +. The desktop user-interface shall be Windows 95/98 compliant. +. The user interface of the C-Registration System shall be designed for ease-of-use and shall be appropriate for a computer-literate user community with no additional training on the System. +. Each feature of the C-Registration System shall have built-in online help for the user. Online Help shall include step by step instructions on using the System. Online Help shall include definitions for terms and acronymns. +. The C-Registration System shall be available 24 hours a day, 7 days a week. There shall be no more than 4% down time. +. Mean Time Between Failures shall exceed 300 hours. +. Upgrades to the PC client portion of C-Registration shall be downloadable from the UNIX Server over the internet. This feature enables students to have easy access to system upgrades. + diff --git a/README.adoc b/README.adoc index 735064b..eda14b7 100644 --- a/README.adoc +++ b/README.adoc @@ -31,11 +31,55 @@ make install [source,shell] ---- +# open files for editing: edit file1 file2 file3 +tide file1 + +# open files for editing at a specific line: +edit file1:42 +tide -l 42 file1 ---- == System Overview +=== System Architecture + +[plantuml] +.... +actor User +User --> [Edit] : Spawns > +User --> [Tide] : Spawns > +[X11 Server] as X +[Edit] <<-->> X +[Tide] <<-->> X +[Registrar] <<-->> X +[Edit] ..> [Registrar] : Spawns > +[Edit] ..> [Tide] : Spawns > +.... + +=== Component Layout Diagram + +[plantuml] +.... +[Edit] --> API +[Fetch] --> API +[Fetchsel] --> API +[Pick] --> API +[Registrar] --> API +[Tide] --> API +frame libedit.a { + [X11 Operations] + [Text View] + [Text Buffer] + [Job Control] + [Debug Telemetry] + [Pseudo Terminal] + [Unicode (UTF-8)] + [IO Functions] +} +API -down-> libedit.a +.... + === Use Case: Editing a file that is not already open [plantuml] diff --git a/src/tide.1.adoc b/src/tide.1.adoc index ed52ae8..c070045 100644 --- a/src/tide.1.adoc +++ b/src/tide.1.adoc @@ -1,6 +1,7 @@ = tide(1) :doctype: manpage + == NAME tide - a text editor inspired by acme(1) from Plan 9 and Inferno @@ -51,7 +52,7 @@ search term incrementally and perform repeated searches through the content region. Searching for a term in the content region will search for the term in the content region however. -=== Text Selection [[S1]] +=== Text Selection *tide* uses a series of rules to determine how much text to select when the user executes a context sensitive selection, a search, or a context sensitive @@ -82,24 +83,24 @@ non-whitespace characters under the cursor. The left mouse button is used for selecting text or moving the cursor. A single-click will move the mose to the clicked location. A double-click will will select the object under the clicked location based on context as - described in <>. A triple-click will select the largest + described in <>. A triple-click will select the largest contiguous chunk of non-whitespace characters at the clicked location. *Middle Button*:: The middle mouse button is used for executing text at the clicked location. The command to be executed is determined by the context rules defined in the - <> section. The cursor position is not changed on a + <> section. The cursor position is not changed on a middle click. *Right Button*:: The right button is used to search for the next occurrence of the clicked text. The search term is determined by the context rules defined in the - <> section. The search direction follows the direction of + <> section. The search direction follows the direction of the previous search operation. The *Shift* key can be held in combination with a click of the right mosue button in order to reverse the search direction. -=== Command Execution [[S2]] +=== Command Execution *tide* allows for the execution of any arbitrary text as a command. The input and output to/from each command executed can be controlled by prepending one of @@ -259,7 +260,7 @@ search operation to be applied in the opposite direction of the previous. *Ctrl+f*:: Search for the next occurrence of the selected text in the content region. If no text is currently selected, the text under the cursor is selected - based on context as described in <>. + based on context as described in <>. *Ctrl+Alt+f*:: Search for the next occurence previous search term in the content region. @@ -273,7 +274,7 @@ search operation to be applied in the opposite direction of the previous. Increase the indent level of the selected text. *Ctrl+h*:: - Highlight the item under cursor following the rules in <> + Highlight the item under cursor following the rules in <> *Ctrl+t*:: Toggle focus between the tags region and the content region. @@ -284,9 +285,9 @@ search operation to be applied in the opposite direction of the previous. within 250ms will ignore the warning and quit the editor without saving. *Ctrl+d*:: - Execute the selected text as described in <>. If no text is + Execute the selected text as described in <>. If no text is selected, the text under cursor is selecte dbased on context as described in - <>. + <>. *Ctrl+o*:: Launch pickfile(1) to choose a file from a recursive list of files in the @@ -359,6 +360,30 @@ search operation to be applied in the opposite direction of the previous. == OPTIONS +*-I _OPT_*:: + Turn on/off auto indenting of new lines. + +*-W _OPT_*:: + Turn on/off trimming of trailing whitespace on save. + +*-E _OPT_*:: + Turn on/off expanding tabs to spaces. + +*-N _OPT_*:: + Turn on/off DOS line ending styles () + +*-T _STRING_*:: + Sets the text of the tags region. + +*-S _SHELL_*:: + Sets the shell to be used for all external command invocation. The shell + must use the -c flag to receive commands to execute + +*-c _CMD_*:: + Executes the given command in a new tide window. + +*-l _LINENUM_*:: + Jumps the view to LINENUM in the document. == ENVIRONMENT diff --git a/src/tide.c b/src/tide.c index 45e99f5..13e2e3a 100644 --- a/src/tide.c +++ b/src/tide.c @@ -10,7 +10,6 @@ #include #include -//#include typedef struct { char* tag; void (*action)(char*); @@ -747,7 +746,7 @@ int main(int argc, char** argv) case 'E': ExpandTabs = BOOLARG(); break; case 'N': DosLineFeed = BOOLARG(); break; case 'T': TagString = STRARG(); break; - case 'C': ShellCmd[0] = STRARG(); break; + case 'S': ShellCmd[0] = STRARG(); break; case 'c': termcmd = STRARG(); break; case 'l': line_num = NUMARG(); break; default: usage(); break; -- 2.49.0