Architecture Plans

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.

Meanwhile, we’ve assigned ourselves user stories to work on. Mine involve determining if the data is valid based on the ignition cycles between the crash and the generated report, as well as encoding the equation into a text format. The first is actually rather easy; the numbers just need to be within 5 cycles of each other to be valid. The latter may be more involved, but since SymPy already has methods to interpret strings as equations, it shouldn’t be to hard. The only issue I’ve encountered is that writing something like “y = x**2” throws an error because “=” gets interpreted as Python assignment rather than the symbolic equality symbol. I’ve seen that this is an open issue on the SymPy GitHub page, so I may need to write a simple helper method to convert statements like “LHS = RHS” into “Eq(LHS, RHS)” before passing them into the SymPy parsing methods. I’ve tested do this using regex and I believe I already have a working solution. I won’t be able to actually write the code till this coming Friday, which will be quite late into the sprint, but it should still be easy to implement and test within that timeframe.