[IGSTK-Developers] Extracting requirements from the bug tracker to latex file
David Gobbi
dgobbi at atamai.com
Mon Jul 18 09:41:56 EDT 2005
Hi Andy,
Can you get the latex file (and ideally a pdf as well) to be posted to
the dashboard directory or the wiki on a nightly basis?
- David
Andy Cedilnik wrote:
>Hi All,
>
>Latest version does all this. Attached is the latex file.
>
>#!/usr/bin/env python
>
>import MySQLdb
>import sys
>import string
>
>HOST = '*****'
>DATABASE = '*****'
>USER = '*****'
>PASSWORD = '*****'
>
>def CleanString(str):
> res = ""
> for a in UnEncodeString(str):
> if a == '_': res += "\\_"
> elif a == '%': res += "\\%"
> elif a == '{': res += "\\{"
> elif a == '}': res += "\\}"
> elif a == '[': res += "\\["
> elif a == ']': res += "\\]"
> elif a == '\\': res += "\\\\"
> elif a == '\r': pass
> else: res += a
> return res
>
>def UnEncodeString(str):
> res = string.replace(str, """, "\"")
> res = string.replace(res, "<", "<")
> res = string.replace(res, ">", ">")
> res = string.replace(res, "&", "\\&")
> return res
>
>sql = MySQLdb.connect(db=DATABASE, host=HOST, user=USER, passwd=PASSWORD)
>cursor = sql.cursor()
>cursor.execute("SELECT bug_id, title, description FROM phpbt_bug WHERE
>project_id = 10;")
>
>bugs = {}
>comments = {}
>
>while 1:
> res = cursor.fetchone()
> if not res:
> break
> if not bugs.has_key(res[1]):
> bugs[res[1]] = res
> else:
> print "Problem!! Found two bugs with the same requirement:\n%s\n%s"
>% (`res`, `bugs[res[1]]`)
> sys.exit(1)
> comments[res[1]] = []
>
>ks = bugs.keys()
>ks.sort()
>
>print """\\documentclass[letter]{article}
>
>\\begin{document}
>
>\\begin{description}
>"""
>
>
>for a in ks:
> if a.startswith("REQ"):
> bug = bugs[a]
> print "\item[%s - %d]" % (a, bug[0])
> print "%s" % CleanString(bug[2])
> print ""
> cursor.execute("SELECT comment_text FROM phpbt_comment WHERE bug_id
>= %d;" % bug[0])
> while 1:
> res = cursor.fetchone()
> if not res:
> break
> print CleanString(res[0])
>print """\\end{description}
>
>\\end{document}"""
>
> Andy
>
>David Gobbi wrote:
>
>
>
>>Hi Andy,
>>
>>The latex requirement document was discussed at the IGSTK t-con, and
>>we decided to move ahead with it. The python script just needs to be
>>completed so that it produces a complete latex document (see
>>attached), and so that it runs pdflatex to produce a .pdf file and
>>then posts that file somewhere on the web.
>>
>>The pdf file could go into the nightly doxygen documentation, into the
>>nightly dashboard directory, or somewhere on the wiki.
>>
>>If you can dedicate the time, there was also an interest in adding
>>section headings according to the attached taxonomy document. These
>>were not considered to be absolutely necessary, but would be a very
>>nice feature.
>>
>>- David
>>
>>Andy Cedilnik wrote:
>>
>>
>>
>>>Hi All,
>>>
>>>Here is script that I can run every night. It produces the attached
>>>file. Let me know if the format is ok.
>>>
>>>Current problems:
>>>
>>>* Handle special characters
>>>* Do something with NEW_REQ_TEXT
>>>
>>>#!/usr/bin/env python
>>>
>>>import MySQLdb
>>>import sys
>>>
>>>HOST = '****'
>>>DATABASE = '****'
>>>USER = '****'
>>>PASSWORD = '****'
>>>
>>>
>>>sql = MySQLdb.connect(db=DATABASE, host=HOST, user=USER,
>>>passwd=PASSWORD)
>>>cursor = sql.cursor()
>>>cursor.execute("SELECT bug_id, title, description FROM phpbt_bug WHERE
>>>project_id = 10;")
>>>
>>>bugs = {}
>>>comments = {}
>>>
>>>while 1:
>>> res = cursor.fetchone()
>>> if not res:
>>> break
>>> if not bugs.has_key(res[1]):
>>> bugs[res[1]] = res
>>> else:
>>> print "Problem!! Found two bugs with the same requirement:\n%s\n%s"
>>>% (`res`, `bugs[res[1]]`)
>>> sys.exit(1)
>>> comments[res[1]] = []
>>>
>>>ks = bugs.keys()
>>>ks.sort()
>>>
>>>for a in ks:
>>> if a.startswith("REQ"):
>>> bug = bugs[a]
>>> print "\section{%s - %d}" % (a, bug[0])
>>> print "%s" % bug[2]
>>> print ""
>>> cursor.execute("SELECT comment_text FROM phpbt_comment WHERE bug_id
>>>= %d;" % bug[0])
>>> while 1:
>>> res = cursor.fetchone()
>>> if not res:
>>> break
>>> print res[0]
>>>
>>>
>>>
>>>
>>>
>
>
>
>
>------------------------------------------------------------------------
>
>\documentclass[letter]{article}
>
>\begin{document}
>
>\begin{description}
>
>\item[REQ 04.01.01 - 1068]
>IGSTK components shall execute a high-level task autonomously requiring minimal interaction.
>
>Discuss and verified this REQ on October 7.
>\item[REQ 04.01.02 - 1069]
>IGSTK components shall not expose underlying class structure in header files.
>
>Discussed and verified this requirement on 10/7/2004
>\item[REQ 04.02.01 - 1070]
>At a minimum, IGSTK shall support general components for tracker capabilities, viewer capabilities, segmentation, and registration.
>
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 04.02.02 - 1071]
>The IGSTK platform shall include a minimum of two application examples.
>
>Discussed and verified this requirement on 10/7/2004
>\item[REQ 04.02.03 - 2002]
>IGSTK will provide platform-independent access to the system real-time clock, and will provide an absolute time with millisecond precision.
>
>\item[REQ 05.01.01 - 1072]
>IGSTK components that manage events shall include threading capability.
>
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 05.02.01 - 1073]
>A test case shall be included for each IGSTK component.
>
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 05.02.02 - 1074]
>Each IGSTK components must have 100\% testing coverage.
>
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 05.03.01 - 1075]
>IGSTK components shall enable compilation via CMake.
>
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 05.03.02 - 1076]
>Each IGSTK components shall be documented with corresponding DOxygen files.
>
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 05.04.01 - 1077]
>Each IGSTK component must be controlled by the IGSTK internal state machine code.
>
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 05.05.01 - 1078]
>Each configuration management action must be supported by a requirement number.
>
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 05.06.01 - 1246]
>The IGSTK platform shall contain a general communication component that acts as a proxy to all communication ports to and from the application such as the serial/parallel ports or wireless connectivity.
>
>Verified via discussions on October 26.
>\item[REQ 05.06.02 - 2007]
>Communication component need to be able to communicate binary data as well as ascii data
>
>\item[REQ 05.06.03 - 2008]
>Communication component needs to be able to support "Canonical" and "Non-Canonical" communication. "Canonical" communication means that replies are terminated by special characters (e.g. a carriage return) while Non-Canonical communication means that the data record size must be known ahead of time.
>
>\item[REQ 05.06.04 - 2009]
>Communication component must report a timeout event rather than simply freezing when communication is broken.
>
>\item[REQ 05.07.01 - 1247]
>The IGSTK platform shall contain a general logging capability that can encapsulate logging capabilities for all IGSTK components.
>
>NEW\_REQ\_TEXT: The IGSTK platform shall contain a general, centralized logging capability that can be used for all IGSTK components.
>Requirement verified at October 26th meeting.
>\item[REQ 05.07.02 - 1248]
>The logging capability shall support timestamps for the audited information.
>
>Requirement verified on October 26th meeting.
>\item[REQ 05.07.03 - 1249]
>The logging capability shall enable logging for multiple components concurrently and support auditing into multiple files.
>
>Requirement verified at October 26th meeting.
>\item[REQ 05.07.04 - 1900]
>Each IGSTK component should be enable with logging capability using the PrintSelf function
>
>\item[REQ 06.01.01 - 1082]
>The tracker component shall have the ability to initialize the tracker hardware.
>
>Additional comments
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 06.01.02 - 1083]
>The tracker component shall have the ability to reset the tracker hardware.
>
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 06.01.03 - 1084]
>The tracker component shall have the ability to start and stop tracking independent of the tracker hardware.
>
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 06.01.04 - 1085]
>The tracker component shall have the ability to restart the tracker hardware.
>
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 06.01.05 - 1086]
>The tracker shall incorporate a state machine that supports the following states: Tracker Off, Tracker On But Invalid (Not Initialized), Track Available But Tools Not Valid, Track Available With Valid Tools, Tracker Tracking.
>
>NEW\_REQ\_TEXT: The tracker shall incorporate a state machine that, at a minimum, supports the following states: IdleState, CommunicatingState, ToolsActiveState, TrackingState, SetUpCommunication, SetUpTools, StartTracking, UpdateToolsStatus, StopTrackingCommunicatingState.
>Discussed and verified this requirement on 10/7/2004.
>1. The state machine transition methods need to be defined.
>2. SetUpCommunication and SetUpTools methods should not be made available for use. Instead these functionalities should be made part of initialization.
>3. Access method for tool status should be made available.
>
>\item[REQ 06.01.06 - 2003]
>The transforms that the tracker component provides for the spatial objects need to be in patient coordinates. To accomplish this, it must be necessary to provide the tracker component with a "patient transform" that will be applied to the raw transforms provided by the tracking device to convert them to the chosen patient coordinate system.
>
>\item[REQ 06.01.07 - 2004]
>The tracker component should allow a reference tool to be set, so that all other tools will be tracked relative to the reference tool.
>
>\item[REQ 06.01.08 - 2006]
>The tracker component will support, as a minimum, the Aurora and Polaris devices.
>
>\item[REQ 06.02.01 - 1087]
>The tracker component shall have an integrated module to support logging that can be enables or disabled at initialization time.
>
>NEW\_REQ\_TEXT: The tracker component shall have an integrated module to support connectivity to the logging capability.
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 06.02.02 - 1088]
>The tracker component shall have an integrated module to support the loading configuration files and the management of the configuration data.
>
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 06.02.03 - 1089]
>The integrated configuration file management component must support configuration files in the Extensible Markup Language (XML).
>
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 06.02.04 - 1091]
>The tracker component shall have a non-limiting design to support up to 10 tools connected to a specific tracker hardware.
>
>NEW\_REQ\_TEXT: The tracker component shall have a non-limiting design to support at least 4 tools connected to a specific tracker hardware.
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 06.02.05 - 1092]
>The tracker component must allow a tool refresh rate at initialization time which checks the status of the tool at the frequency of that rate. The default tool refresh rate will be the same refresh rate as the tool.
>
>NEW\_REQ\_TEXT: The tracker component will verify if the rate requested by the user is lower or equal than the rate supported by the tracker, if the requested rate is higher then the tracker component should create an exception.
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 06.02.06 - 1093]
>The tracker component shall support diagnostic procedures that occur at the frequency of the tool refresh rate when a tool is substituted or disabled.
>
>NEW\_REQ\_TEXT: The tracker component shall support diagnostic procedures that occur at the frequency designated by the application developer to determine when a tool is substituted or disabled.
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 06.02.07 - 1094]
>The tracker component shall have multiple levels of diagnostic support. At the highest level, a component and human diagnostic must be executed at the insertion of each new tool.
>
>NEW\_REQ\_TEXT: The tracker component shall have multiple levels of diagnostic support. At the highest level, a component and human diagnostic must be executed at configuration time.
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 06.02.08 - 1095]
>The tracker component shall have an open interface to the viewing component using a universally-acceptable data structure.
>
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 06.02.09 - 1096]
>The tracker component interface should send messages to that at a minimum contain position, orientation, quality (error), number of tools, and tool identification.
>
>NEW\_REQ\_TEXT: The tracker component interface should send messages at a minimum comprising position, orientation, quality (error), number of tools, and tool identification.
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 06.02.10 - 1097]
>The tracker component shall report its refresh rate and time latency on demand.
>
>NEW\_REQ\_TEXT: The tracker component shall report the maximum refresh rate and time latency on demand.
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 06.02.11 - 1098]
>The tracker component shall support a hot swapping routine that consists of ….
>
>NEW\_REQ\_TEXT: All tracker tools must be installed and verified at initialization time. Tracker will only support hot swapping for tools that enable this capability.
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 06.02.12 - 1099]
>The tracker component must confirm that the tools are at the same refresh rate as the tracker hardware.
>
>Discussed and verified this requirement on 10/7/2004.
>\item[REQ 06.02.13 - 1998]
>The tracker component will have a "top-down" approach to application control such that it will not push data to other components, but allow other components to request their desired data.
>
>\item[REQ 06.02.14 - 1999]
>Upon a data request, the tracker component will push data into an internal data area from which it can be accessed by other components enabling the synchronization of multiple tools such that a single update can be followed by access of tracker data from multiple components, and each component will get data that was generated at the same time point.
>
>\item[REQ 06.02.15 - 2000]
>The tracker component's state machine must be fully encapsulated and private to the tracker base class making it impossible for derived classes to disrupt the state machine of the base class.
>
>\item[REQ 06.02.16 - 2001]
>State machine transitions in the base class of the tracker component will drive actions in the derived classes via a protected internal interface enabling the state machine to have complete control over which derived class methods are executed.
>
>\item[REQ 06.02.17 - 2005]
>The tracker component should provide identification information for each tool that is tracked. This information must be sufficient such that it is possible to determine whether it is valid to use a particular tool as a reference.
>
>\end{description}
>
>\end{document}
>
>
More information about the IGSTK-Developers
mailing list