Repository navigation
Engineering Notebook Corrina Del Greco
Corrina Del Greco edited this page Dec 1, 2020
·
31 revisions
- For SRS, SDS, and the test plan:
- Reread and corrected unclear language
- Fixed inconsistencies in usage of Dot/.dot/DOT
- For future reference: .dot only when talking about the file extension, Dot otherwise. (Yeah, Dot is for both the language and the tool)
- Fixed issue where markdown wouldn't let us write text like <this>
- Use the escape character \ before the <
- Copied and pasted wikis into Google docs
- Easiest way to maintain formatting from the wiki but get a .docx version
- Added numbered captions to figures
- Table formatting got messed up when converting to .docx
- Add line width
- Remove spaces after paragraphs
- Adjust width of columns
- SDS only changes:
- Replaced old guide to the command line input in 3.1 with our program's help menu in table form
- SRS only changes:
- Made a new Use Case Diagram with Sam
- Got feedback from Tayler King (product owner):
- Put "includes" on all of the arrows that did not already have "<<extends>>"
- There should be no relationships between the circles (we're assuming that means the type of arrow was the wrong)
- What is in the circles are the use cases (actions) that we should be describing below
- Added circles for new command line options (setting output file, setting logging verbosity level)
- Rewrote use cases so that there's one for each circle
- Got feedback from Tayler King (product owner):
- Wrote new requirements
- FR3, FR4, FR5, SR1
- Seems a little counterintuitive to write reqs that are already met, should have wrote them when we wrote the stories
- Rewrote wording of requirements, mostly in the statement and evaluation method
- Replaced revision history TBDs with created version #, revised version #
- Made a new Use Case Diagram with Sam
- Test plan only changes:
- Converted test plan from Google doc to wiki
- Started over on traceability matrix table so that it applies to new requirements
- Approved Aaron's PR's
- Forgot to pull Aaron's last commit into my branch then pushed the document changes, big mess up. Recovered and reverted to Aaron's commit by doing this:
git reset --hard \<commit hash>git push -f origin \<the branch>I do not recommend this, you have to make sure docs are backed up to desktop since this erases history
- Reviewed Aaron's PRs
- Made a plan with the team to work on documentation
- Finished logging verbosity level tests
- I was concerned that I'd have to read and parse an output log file to test the verbosity level, but I found a way around that
- You can create an instance of the logger in the test file just like you would in any other class, and call getLevel() to see what it was set to
- now the test is as simple as
assertEquals(logger.getLevel(), Level.< whatever we expected it to be>);
- now the test is as simple as
- Technically, we're not checking if it actually outputs properly. Reasoning why this is ok: We created the command line arg and handled it ourselves, so we tested that, but we did not create the logger package/library, so we don't test that. We are assuming that if we set it properly then it will log properly.
- Aaron caught me up on the Graphviz library issue, see his Wiki for details
- Starting to test the Parser
- Finishing other tests so I can PR them
- Doing documentation this week
- Got tests further to completion
- Added tests for Reader
- Question: how to test that the string version of the file contents is correct? Maybe make a dummy file with one line in it to test
- Checked for null returns
- Added tests for Configurator
- Test stubs for each level of logging verbosity
- TODOs inside because we'll have to check the output somehow. Probably should be wait until after we finish the log file writing so that we can just read the file and look for FINE, INFO, etc
- Test stubs for -o and -L
- TODOs because the functionality isn't in the app yet
- Test stubs for each level of logging verbosity
- Deleted test file for Manager -- it was unused, and I don't think that there is anything to test in Manager?
- Added tests for Reader
- Starting work on testing the Parser
- Worked with Luis on logger
- Answered Luis question: what levels are needed? when should they be used?
- Researched it online
- SEVERE should be rare, only for when the app breaks and can't recover
- WARNING means something didn't work as expected or may be concerning but the app can continue on
- INFO is for things the user might want to know (which I think anything that would go in CONFIG could go in INFO)
- FINE/FINER/FINEST is for debugging/tracing, but we probably don't need all 3, just FINE
- Output that is always necessary to get to the user doesn't fit in the logger scheme and should use System.out.println
- Reasoning: SEVERE would always show, but if it's expected functionality then it's not broken. INFO could get muted if the user sets the logging level too high
- Changed all of the logging levels to match this^
- Updated the help menu
- Answered Luis question: what levels are needed? when should they be used?
- Cleaned up sprint board
- Closed stories in the done column
- Wrote stories for final doc submittal
- Worked on Test Plan V1
- Ported template from Canvas to Google doc so team can work on it
- Modified prewritten paragraph descriptions where they were not applicable to our project
- Outlined tests in 4.1 execution plan based on demo criteria from stories
- Question: What should test case look like? Not shown in template
- Listed requirements from SRS in 5.1 Traceability Matrix, linked to corresponding test cases
- Wrote about risks/contingencies
- Wrote about testing environment
- Map implementation instead of array lists
- We can add to and retrieve from maps way easier than array lists, eliminate looping all the time
- Challenge: What do we use as the key? Node label? Module? What would be a useful key depends on what part of the parser you're doing
- Another thing to look into: Aaron said there's memory concerns. Using Integers as keys would be better, but not as useful
- Experimented with implementation the Parser using maps instead of array lists
- Discussed removing inter-module edges with Luis
- Made changes to PR and merged it
- Prepped for Sprint 2 demo
- Worked with Sam to make slides
- Wrapped up work on documents, put Aaron's diagrams in there and made .docx versions
- Worked with team to make sure all stories in PR merged
- Put removing edges story into PR
- Worked with Sam on her story (sorting private/public functions)
- Reviewed Luis' PR
- Began work on removing edges story
- Completed peer evaluation
- Worked with Sam to...
- Update SRS wiki based on feedback from Liu and Tayler
- Create new use case diagram
- Add images to documentation
- Worked with Sam to update SDD Wiki based on feedback from Liu and Tayler
- Wrote and assigned stories for remaining work on Parser, documentation work
- Organized board
- Reviewed and approved Parser PR
- Organized Wiki pages
- Met with team to discuss Parser design, decided Manipulator's jobs were more easily done as a part of the Parser
- Merged the Lexer PR
- Worked with Sam to...
- Change Luis' Parser code so that it uses hash maps instead of 2D arrays for key value pairs
- Because retrieving a value from a map is faster and requires less manual looping and searching
- Because adding values to a map doesn't require index work
- Set up Sam's automatic code formatter in Eclipse
- Change Luis' Parser code so that it uses hash maps instead of 2D arrays for key value pairs
- Worked with Aaron to...
- Change the attributes of the Node class
- Because we wanted to more closely match the grammar definition so it's understandable
- Because we wanted to stop storing information that is irrelevant to us like the font/size/shape/color attribute string
- Delete the Graph class
- Because separating nodes into graph containers to just combine them later seemed disadvantageous
- Because it had no attributes we needed
- Add an Edge class
- Because we had been combining it with the node class, but really there are no shared attributes whatsoever
- Because we needed somewhere to store the source and destination of the edge statements
- Change the Parser to use substrings instead of StringTokenizer
- Because substrings suited our needs better
- Note: I'm referring to the StringTokenizer from java, not our tokenizer (Lexer), that remains untouched.
- Change the attributes of the Node class
- Refactored Lexer code
- Added attributes to TokenType enum (id, keyword, maps)
- Discussed with team if this was a overcomplicated implementation, whether there were benefits
- Used enum to determine if type is a keyword or not
- Fancified regex to simplify code
- Previously regex was used to look for "Node#" which is a prefix for multiple token types, then we scanned ahead to look for more identifiers. A more complex regex meant we could look for the whole phrase, and no more substring business to get the value following
- Learned about regex:
- ^ means it's the beginning of the string - solved problem where "Node# [" was getting confused on the second part of "Node# -> Node# ["
- /d for digit can be used in place of [0-9]
- + means one or more of the thing before it, like from the class Organization of Programming Languages
- Added attributes to TokenType enum (id, keyword, maps)
- Pushed work on Lexer to GitHub
- Learned how to use git stash properly
- Originally, my code changes were made on Aaron's branch, but in order to allow other team members to review it before affecting Aaron's work, I moved it to my own branch to push the code
- Still on Aaron's branch (vandebrook-12), I stored my uncommitted changes:
$ git stash
- Then I made my new branch. Since Aaron's work was in PR and could merge to master, instead of branching off of Aaron's branch I branched off of master and pulled Aaron's work in:
$ git checkout master $ git checkout -b delgreco-12 $ git pull origin vandebrook-12
- I then un-stored my changes to my new branch:
$ git stash apply
- After making sure the code ran as expected, I could stage, commit, and push to my own branch for others to review.
- Learned how to use git stash properly
- Discussed design of the Parser with the team
- Listened to Aaron explain his idea of using a Lexer to tokenize the strings
- Lexer at a high level: each line in the DOT file is parsed to determine what type of information it gives, so we can store that enumerated type and the information. Allows easier processing of the info later, when creating graph objects
- Ex: Node8 -> Node9 [values]; turns into a token of type EDGE_STMT and value "Node8->Node9[values]"
- Lexer at a high level: each line in the DOT file is parsed to determine what type of information it gives, so we can store that enumerated type and the information. Allows easier processing of the info later, when creating graph objects
- Saw Aaron's work-in-progress code
- Design helped break up the Parser and make the next steps clearer
- Agreed to have Aaron finish his code, me help clean it up/refactor, and then divvy up remaining work
- Listened to Aaron explain his idea of using a Lexer to tokenize the strings
- Met with the team to assign stories for Sprint 2
- Parser was going to be a massive job, needed split up in order to assign but wasn't sure how to without a design
- Luis and Aaron had a design idea, needed some time to shape it up
- Resolved issue with submitting SRS/SDS documentation (we had a markdown wiki, Canvas assignment asked for .dox)
- Presented for Sprint 1 Demo
- Met with team to work on SDS
- Discussed Parser--whether looping through each "file" (string) and collecting results was the Manager's job (send one string at a time to the Parser) or the Parser's (receive list, return list). Decided on Parser for simplicity's sake
- Met with team to work on SDS
- Met with team, worked through Luis' merge conflict issue
- Helped Sam pull the changes that I made to the master branch into her PR branch
- Encountered merge conflicts
- Set up merge tool
- Updated wiki page Setting Up Dev Environment to include steps to set up to Tortoise Git as a merge tool to
- Helped with Reader (story card #11) - add checks for invalid file/directory
- Met with team to work on SRS
- Wrote wiki page Setting Up Dev Environment
- Fixed previous PR
- Pull Request for Hotfix
- Removed instances of Manager in the other classes that were leftover from refactoring
- Helped with Reader (story card #11)
- Completed story card #9, Manager
- Pull request for story card #9
- Created skeleton code based on program design flow
- Created method stubs for future stories to know what the expected input and output is
- Refactored my code
- Originally had the helper classes (Reader, Parser, Manipulator, etc) creating instances of the Manager class so they could call a provideXXX() method to give the Manager their result (the thinking behind this was the design: the Manager serves as an intermediary and the classes do not share data)
- Decided that ^ was ridiculous and instead properly used return types (had Manager call a method in the class to return the result)
- Met with team to discuss program design and workflow
- Wrote wiki page Program Flow Design to summarize our talk about program flow
- Updated wiki page Project Workflow on Git to show review process and more Git commands