









Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
This file is all about software requirements analysis of grap editor
Typology: Study Guides, Projects, Research
1 / 16
This page cannot be seen from the preview
Don't miss anything!
This specification establishes the functional, performance, and development requirements for Release 1 of a software application for displaying and editing graphs.
The Graph Editor Software is an interactive application that allows the user to create, edit, layout, save, and print arbitrary graphs. It uses the GXL graph notation standard for storing graphs to files.
CSCI Computer Software Configuration Item DTD Document Type Definition GDO Graph Data Object CSCI GEI Graph Editing Interface CSCI GLG Graph Layout Generator CSCI GSP Graph Save and Print CSCI GUI Graphical User Interface GXL Graph Exchange Language SRS Software Requirements Specification XML Extensible Markup Language
The following standards apply
J-STD-016-1995 IEEE/EIA Standard for Information Technology, Software Lifecycle Processes, Software Development, Acquirer-Supplier Agreement IEEE-STD-P1063 IEEE Standard for Software User Documentation
The following documents describe the course in which this software is to be developed:
CSC444-HND-001 Course Orientation Handout CSC444-HND-002 Notes on the Software Trading Game
http://www.cs.toronto.edu/~sme/CSC444F Course website
The following documents describe aspects of file formats for graph storage:
http://www.gupro.de/GXL/ The Graph Exchange Language Standard and XML DTDs
http://www.w3.org/XML/1999/XML-in-10-points An introduction to XML
There are many papers available describing graph layout algorithms, and the aesthetic principles underlying them. Try a websearch for phases such as “graph layout algorithm”. The following paper provides a detailed survey:
Giuseppe Di Battista, Peter Eades, Roberto Tamassia, and Ioannis Tollis, “Annotated Bibliography on Graph Drawing Algorithms” Computational Geometry: Theory and Applications 4:235-282 (1994). Available on the web at: http://www.cs.brown.edu/people/rt/papers/gdbiblio.pdf
Section 1 identifies the scope of this document, the purpose of the software, and lists the definitions, acronyms and reference documents. Section 2 provides an overview of the system, and a description of the functional architecture. Section 3 identifies the four main Computer Software Configuration Items (CSCIs) that comprise the system, and gives the functional requirements and constraints for each CSCI. Section 3 also describes the quality requirements for the software. Appendix A contains some sample graphs and their GXL representations.
Graphs are commonly used throughout software engineering and computer science to present structured information in a form that is easy to read. Many forms of information can readily be presented as a graph, including structural and behavioural views of a software system, such as call graphs, data flow diagrams, state machine models, etc. Briefly, a graph is a collection of nodes and connected edges. The edges may be directed (in which case they are usually shown using arrowheads) or undirected. For different applications, the nodes may be drawn as circles, dots, boxes, etc, while the edges are nearly always drawn as straight lines or arcs. Nodes and/or edges may be labelled, and for some applications, there are conventions for how the labels are presented.
The software described in this specification consists of an application for creating, viewing, editing, laying out, saving, and printing the kinds of graphs commonly used in software engineering. The application shall input graphs created by other applications, represented in the standard graph language GXL. It shall also support the creation of new graphs through the use of a graphical user interface. In either case, the application shall support automated layout of graphs according to aesthetic principles such as minimizing the crossing of edges. It shall also allow the user to manipulate an automatically-generated layout, by moving nodes and edges interactively. The application shall allow graphs to be saved in GXL format, and shall also support common imaging formats for outputting pictures of graphs.
There are essentially four main functional areas, which correspond to the four CSCIs specified in section 3:
The architecture is summarized in Figure 2.1.
All interaction with the user shall be via the GEI CSCI. The interface provided by the GEI may be graphical or textual. The interface shall always give a view of the current graph. If the current graph is too large to display on the screen, the GEI shall display part of it, and provide controls for scrolling to the hidden parts. The GEI shall also provide a mechanism for zooming out, to allow the user to see the entire graph in a single view (without necessarily seeing all the detail). The GEI shall also provide an interface for loading and saving files. It shall provide a visual reminder if the current graph has been edited but not yet saved, and in this state, shall warn the user if she attempts to close the graph (or open a different one) without saving the current graph first. It shall also provide a warning if the user attempts to overwrite an existing file. For ease of use, the GEI shall allow the user to browse the file system when opening or saving files, and the GEI shall remember the name and location of the last file opened.
None
The system shall make use of the operating system calls to the file management system to store and retrieve files containing graphs and images. Platform independence and portability requirements are described in section 3.5.5.
The system shall be capable of exchanging graph information with other applications that are GXL compliant.
This section describes the functional requirements for each of the four CSCIs: Graph Data Object CSCI (GDO), Graph Editing Interface CSCI (GEI), Graph Layout Generator CSCI (GLG), and Graph Save and Print CSCI (GSP).
The GDO CSCI shall store the current graph in memory, and provide a functional interface to other CSCIs to access and make changes to the current graph. It shall also be responsible for checking the validity of the current graph.
3.2.1.1 GDO Internal Data
The main internal data used by the GDO shall be a representation of the current graph. GDO shall hold all data about the current graph in a suitable data structure, and shall provide information about the graph to the other CSCIs. The following data shall be stored:
Note that information about the size, location and appearance of nodes and edges can be stored in GXL either as attributes of nodes and edges, or as type information. In the latter case, a graph schema will typically define a small number of node and edge types, so that appearance information needs to be defined only once. For example, a dataflow diagram may have three different node types (e.g. “process”, “datastore”, and “external entity”), where the
attributes of each type define its appearance, and each node in the graph is declared to be one of these types. In either case, GDO shall store the relevant information in appropriate data structures, so that it can be saved again to a GXL file in the same form as it originally appeared.
GDO shall also perform validity checks on the current graph when requested. For a graph to be valid, there must be no disconnected nodes, and no disconnected subgraphs, all edges must connect to valid nodes, and all grid references representing node locations must lie with the graph’s given grid size.
3.2.1.2 GDO External Interface
The GDO CSCI provides the following functions for external use by other CSCIs:
new_graph(): initializes the internal data structure with a new empty graph.
add_node(nodeID): given a string containing a node identifier that is not already a node in the current graph, creates a new node in the current graph with this identifier. Returns true if the creation was successful, false otherwise.
delete_node(nodeID): given a valid node identifier in the current graph, deletes that node from the current graph. Returns true if the deletion was successful, false otherwise.
add_edge(nodeID, nodeID, edgeID): given two valid node identifiers in the current graph, and a string containing an edge identifier that is not already an edge in the current graph, adds an edge between the two nodes with the given identifier. Returns true if the creation was successful, false otherwise.
delete_edge(edgeID): given a valid edge identifier in the current graph, deletes that edge from the current graph. Returns true if the deletion was successful, false otherwise.
get_label(edgeID|nodeID): given a valid edge identifier or a valid node identifier in the current graph, returns a string containing the textual label for that edge or node.
set_label(edgeID|nodeID, label): given a valid edge identifier or a valid node identifier in the current graph, and a string, set the textual label for that edge or node to the given string. Returns true if the change was successful, false otherwise.
get_position(nodeID): given a valid node identifier in the current graph, returns a pair of coordinates describing the position of that node on the grid.
set_position(nodeID, coordinates): given a valid node identifier in the current graph and a pair of coordinates on the grid, sets the position of the given node to the given coordinates. Returns true if the change was successful, false otherwise.
get_grid(): returns a pair of integers representing the grid size used in the layout of the current graph.
set_grid(X, Y): given two positive integers, sets the grid size of the current graph to the given values.
expand_grid(factor): given a positive integer, expands the size of the current grid by this factor, multiplying all node location coordinates by the same factor (this function effectively increases the resolution of the grid). Returns true if the change was successful, false otherwise.
get_node_style(nodeID): given a valid node identifier in the current graph, returns a record giving appearance parameters for the given node.
set_node_style(nodeID, appearance): given a valid node identifier in the current graph, and a record giving appearance parameters for the given node, sets the appearance of the node to the given parameters. Returns true if the change was successful, false otherwise.
get_edge_style(edgeID): given a valid edge identifier in the current graph, returns a record giving appearance parameters for the given edge.
set_edge_style(edgeID, appearance): given a valid edge identifier in the current graph, and a record giving appearance parameters for the given edge, sets the appearance of the edge to the given parameters. Returns true if the change was successful, false otherwise.
list_neighbours(nodeID): given a valid node identifier in the current graph, returns a list of all nodes that are directly connected to this node via edges.
The GLG CSCI shall be responsible for automatically generating a layout for the current graph. If the current graph has location information for some nodes and not for others, GLG shall use the existing layout for those nodes that have locations defined, and layout the remaining nodes. If the current graph has a grid size defined, GLG shall attempt to use this grid. If there is no grid size, or the grid size is smaller than the number of nodes in the current graph, GLG shall set a new, appropriate grid size.
GLG shall use a standard graph layout algorithm to find an aesthetically pleasing layout. Typical aesthetics for graph layouts include minimizing the number of edges that cross one another, keeping the lengths of edges to be similar to each other, and keeping nodes that are connected to one another closer together than nodes that are not. Note that most standard graph layout algorithms have input parameters that affect the way the layout is generated. These parameters should be made available to the user to select via the ask_user command of the GEI. If appropriate, GLG may include more than one layout algorithm. If so, the user should be allowed to select between the available algorithms.
GLG shall not store any data about the current graph. GLG shall use the GDO to store the current graph, including layout information, and to check that the current graph is valid.
GLG shall not interact with the user directly. All user interactions shall be handled by GEI.
3.2.3.1 GLG Internal Data
The GLG may need to store temporary information about the layout being generated, according to the algorithm(s) used.
GLG shall keep a copy of any layout information for the current graph that it overwrites, so that old layouts can be retrieve by the user via the undo command.
3.2.3.2 GLG External Interface
The GLG shall provide the following functions for use by other CSCIs:
layout(): completes a layout for the current graph, preserving any location information already defined. Returns true if it successfully generates a new layout, false otherwise.
new_layout(): generates a new layout for the current graph, discarding any existing location information defined. Returns true if it successfully generates a new layout, false otherwise.
partial_layout(list of nodeIDs): given a list of valid node identifiers, generates a new layout for the current graph, by discarding any existing location information for the given nodes, but preserving location information for all nodes not in the given list. Returns true if it successfully generates a new layout, false otherwise.
undo_layout(): restores the previous layout. Returns true if it successfully restores a layout, false otherwise.
The GSP CSCI shall be responsible for opening GXL files, saving the current graph to a GXL file, and for exporting views of the current graph to image files for displaying in other applications and for printing. GSP shall be responsible for all interactions with the file system, including checking whether a file exists, and moving between directories.
GSP shall preserve all information in a GXL file opened by the software and subsequently saved as GXL (whether to the same file or a different file), except where information is explicitly deleted by the user prior to saving. Information the in GXL files that must be preserved includes, but is not limited to: unique identifiers; location information for nodes; type information; all attributes of nodes and edges; links to external documents; GXL extensions; and features of GXL not used by this software.
GSP shall support one image export format chosen from the following list: GIF image, JPEG image, Encapsulated Postscript (EPS), BMP bitmap, TIFF bitmap, or portable document format (PDF). The image saved shall correspond as closely as possible to the appearance of the graph displayed by GEI.
All code shall be fully documented. Each function shall be commented with pre- and post-conditions. All program files shall include comments concerning authorship and date of last change.
The code shall be modular to permit future modifications.
The software shall be designed to run on at least one of the following four platforms:
No other specific portability requirements have been identified.
No safety requirements have been identified.
No specific training should be necessary for a user to begin using this application.
The system shall be packaged along with source code and all documentation, and shall be available for electronic transfer as a single compressed file. The uncompressed set of files shall include a README file containing a minimal guidance for installing and running the software, including recompilation if needed. If recompilation is necessary during installation, the system shall include a makefile.
Copyright laws and license agreements must be respected for any third party software used in the creation of this system.
There are no other requirements.
A dependency graph generated from a simple C program. Note that the type information is linked to a separate GXL file that contains a schema for this type of graph. The schema is not shown here.
P: Progfile
name = main.c
Q: Headerfile
name = test.h
includes (Line = 64)
ringtone OFFHOOK=T CALLEE_SEL=T CALLEE_FREE=T CONNECTED=F
busytone OFFHOOK=T CALLEE_SEL=T CALLEE_FREE=F CONNECTED=F
idle OFFHOOK=F CALLEE_SEL=F CALLEE_FREE=T CONNECTED=F
dialtone OFFHOOK=T CALLEE_SEL=F CALLEE_FREE=T CONNECTED=F
connected OFFHOOK=T CALLEE_SEL=T CALLEE_FREE=F CONNECTED=T
putdown
putdown
putdown
putdown
pickup
isfree
isbusy
cutoff
answered