UK CS499 Project with Delta V Innovations
#Welcome to Tyler’s Blog!
Total Word Count: 3619
Overall, I believe I have done well in terms of progress, but that I set myself up with too much to expect to get done by the end of the sprint. I initially set out with the goal of getting the equation solving system completed by the end of the sprint. However, as I explored what needed to go into the code to complete it, I quickly realized that a fully working implementation would not be possible. There seems to be a plethora of edge cases and desired sub-features that would be involved with it that need to be handled by future teams. In hindsight, It would have been better for me to have broken the user story up into more pieces somehow and assigned myself only a few of those pieces. The team and I knew that this would be an epic, but I still believe that in terms of story points that this was an underestimate.
Unfortunately, due to time constraints, I’ve been unable to perform as much code development as I would have preferred. Currently, I have re-designed the configuration files to be encoded using YAML rather than using my own “parser” to read them in. In the long run this will be a much more maintainable solution, as adding more information to the configuration files will require little/no changes to the code that loads it in. This will allow for our and future teams to focus our attention more on operations that use and manipulate that information. There might need to additional code to confirm the structure of the objects derived from the YAML files, but that is out of scope for this sprint and will likely need to be left to another team.
I’ve finished all the code I set out to at the beginning of the sprint. It carried over the official end of the sprint Tuesday though, because I needed to help my family with some outdoor work over the weekend, which ended up eating a lot of my time over the weekend. The tests are there and they are passing. I’m having to add some extra configuration files for letting the program know about which variables can be substituted with each other and mappings between variables and units, but I’ll work on those on the next sprint to make sure I have enough time to finish this one.
Since we started the sprint Tuesday, there isn’t a lot of time to work on the user I selected, which involves implementing the equation solving part of the system. This is an epic, so that’s not surprising. I plan on completing some ancillary parts of the system first. This includes creating/updating a constants file, defining how vehicle information comes in from the crash data package, etc. In the meantime, I hope to have enough time to plan out how the actual equation solving code will look like. I’ve gotten some of it done already, but I’ll spend the weekend finishing out what I can. I also hope to write the tests for it then as well.
As of today, I have finished all the user stories I had. After using the regular expression detailed in my prior post and the built-in parser with SymPy, the code boiled down to a simple for loop. I also added a little extra feature to allow for comments by starting a line with #. Since all the parsing is line based, that was simple to add. Plus, it is a nice extra that’ll help when the list of equations becomes large. The ignition cycles was also as easy as I expected. I made the parameter for the maximum difference in cycles a parameter of the method itself with a default value of five, in case this number needs to be flexible for whatever reason.
I’ve not made much progress code-wise since the beginning of the sprint. I anticipated this, given the timing of the sprint with midterms. I’ve figured out what I can do for the problem of converting equation text from a = b to Eq(a, b). As I suspected, regular expressions will allow me to both verify that a line of the text file is formatted in the standard form for an equation, and then obtain the text of the left and right hand side in order to reformat them into proper SymPy notation. The regular expression I’ve chosen for this is the following.
For the architecture assignment, I have been tasked primarily with developing the class diagram for the detailed design section. I have a rough idea for how the classes should look. I can think of dividing the tasks into at least four classes in a sort of “pipeline”. One class would be for taking in input, one for converting that data and doing some preprocessing, one to actually perform the iterative equation solving, and one to write a results report. There may need to be a fifth for writing to the data package, however it seems like the data written to the data package can be separated into each class rather cleanly so that may not need to be the case. I’m also helping Honor with the metrics as well, though this more as an advisory role; Honor seems to have a good handle on the metrics.
SymPy is a symbolic mathematics library for Python. More formally, it is a computer algebra system or CAS, which allows for symbolic manipulation of mathematical expressions. For this project, such a system sounds like it could be used, as a key element of the project involves taking formulas and iteratively deriving new variables from a given set of data. This blog will detail the currently know needs of the software project, and how SymPy is able to address these issues.
Today, we meet with Mike about our requirements. The only problem he saw was that there was no mentioning of lateral data in the requirements. From how he explained it, it now seems obvious that this data needs to be taken into consideration just like the longitudinal data. I was also able to talk with Mike more about the users for the end product. To put in briefly, someone with a high school diploma should be able to use this piece of software. So, we need to focus on low-technical users. This should help with designing it, though it does seem to push the need for a GUI for this project. Mike has stated that his wife Susan can help us with the UI components if need be, so that could be beneficial.
Today, we discussed the formulation of the project plan. This needs to be done by the 18th, so we’ve decided to split up the work into parts. Some sections of it, such as the requirements, need to be created as a group. We therefore decided to pick parts which could be done individually. I decided to deal with business requirements and the metrics.
Today was the meeting with Mike Flamm, the owner and business contact for DeltaV. After talking with him about the new software system, I along with the rest of my team got a clear idea about the function of the software system and its requirements. There appeared to be two main components to it:
subscribe via RSS