Wednesday, November 2, 2016

Project 3 Phase 2 Implementation

For this phase, we had very strict deadlines and guidelines that were established to finish the project for the day immediately following the 28th after class.

A couple of things changed throughout the course of our design phase and through the implementation phase. We omitted the thought process of having two classes to use for the GameInput class and combined it into a single class.

We also thought that there should maybe be a mouseclick event to interact with the page on things that could not be inputted through the keyboard. This was omitted when we started implementing the project as we deemed it unnecessary to the overall design at that point and to some extent was deemed out of our use case for this project.

From our design phase, we each had our classes that we established to start working on. The GameScore class was established by Matthew as a Singleton. This piece was responsible for methods that manipulate the score of the game. The GameScore class also uses the Constant class to calculate scores, which he also established. Ola established a time frame for our project and initially put together some questions for implementation as well as implementing the InputDebouncer. I was set to establish the GameInput, but after some deliberation, I had trouble implementing it within the 24 hour time frame to finish the project on Friday. Ola helped implement this with use of Tetrino class.

A lot of this deliberation and class design was established through our discussion on our group slack page for Team Bravo Tetris. During implementing our design, we also decided against the click listener. A lot of the overall implementation in terms of architecture was established by Bryce, our team lead, as he helped guide us on pieces that deemed unnecessary or incoherent with our design.

This part of the project was finished in record time on Saturday within the 24 hour time frame established.

-Ellen E

Friday, October 28, 2016

Project 3 phase 2 implementation details

For the next phase, Ellen will implement GameInput and Matt will implement GameScore as documented in the class diagram.  Ola will oversee the implementation and make sure the implementation is completed in a timely fashion.  In addition, Ola will make sure the InputDebouncer and GameInput classes interact as described in the design diagram.

Please consider the following during implementation:
   
1. Does the design diagram give sufficient information to complete the implementation?
If not, what needs to change in order for that to happen?
Please submit any questions regarding design to the Slack channel or here.
   
2. What role does my implementation serve in the overall game design?
Since we are focused on input, our implementation is critical to the testing of the application. Because we are so critical to the success of the project we will have a condensed timeline for implementation.
   
 3.  Am I using all available resources to complete my implementation?
 If, at any time, you become stuck or don't believe what you are doing is correct, ask questions.
Also, the prototype provides most of the information necessary to develop your solution.

We will be following this timeline from here until completion.

The initial implementation should be completed no later than 29 October 2016 at 3 p.m. CST.
 Matt, please review your implementation and make any necessary changes by this time.
 Ellen, I will begin your implementation so you have something to reference.

I will code review at 3:15 p.m. CST on the aforementioned date.  I will message/post all changes, if any, that need to be made.
All subsequent changes are due by 7 p.m. CST on 29 October 2016.

Please note:
The changes we make will be based on our design not the overall implementation.  There's no telling what additions/subtractions will need to be made until integration testing takes place.

If this timeline doesn't work for you, please say something immediately.  If these times don't work, please say something immediately.  I will pick up as much slack as I can.

Wednesday, October 26, 2016

Project 3 - Tetris Initiation


Initially, we looked at the project as a whole and began by breaking down each part into components to start working through as individuals. These became the input, the input bouncer, and something to keep track of points as the game was being scored. For me, it was slightly overwhelming seeing the light at the end of the tunnel, but as we started breaking down each component things starting fitting into place.

When we started looking at each component, we first started playing the game to see the general layout and how the game was played (differences from other tetris games etc). For the input, we had to document each interaction that a user would have with the game and how the game reconciled these inputs. This included keystrokes, mouse, and sound. At later stages it also included how these things affected one another in the sense of how the game was played.

At later stages of our discussion, we were able to get some classes identified for each list of interaction and set a layout for our design with a series of established interconnected classes. A big part of this challenge was compiling and syncing everyone's ideas into a general format, but it came together and with some small commissions and additions a final design was established and ready to be implemented.

Wednesday, October 19, 2016

Project 2 - Implementation Phase

Immediately following the distribution of team projects and receiving our "Spin Design" implementation and having Matthew set up our project, Ola jumped on building the architecture for our methods. The design that we received was very detailed, but with a lot of loops and hard work an excellent draft came about. Working through the solution and a lot of back and forth discussion behind the scenes, we put together a main to test the methods established and had Bryce upload fixes. We corrected the bugs and errors and tried to work with the other group to correct any misunderstandings. Upon completion, we also saw that other designs had been uploaded and we were allowed access to view the implementation of our design as well as others. A note made after reviewing the other team's implementation was that interfaces were not a useful implementation to our bucket design, so we have set to notify them of our feedback. I look forward to going through other team's code and seeing their solutions. While some teams had unit tests that weren't a requirement for the design, we put together our tests in the main. After further analysis, we denoted that the main program would be sufficient.
-Ellen E

Saturday, October 15, 2016

Perforce Project File Upload

Tonight, I have uploaded the Perforce shared project file to our team folder,  and created the three empty classes that we will be filling in. We still need to figure out the best way to split up the work load among us, but I figure it's better to start everyone off with the classes started rather than empty.

Thursday, October 13, 2016

Project 2 Implementation Phase

Last night, at the end of lecture we met with our group that we are implementing the design of. We are going to be complementing the "Spin" customer specification. We are going to be going through Bryce, from our group, and Brian, of group 4, as our means of communication. We are all going to read through their documentation individually, and will set a time of when to decide how we are going to delegate the work out to each of us. This should happen within the next day or so, and I will be posting further details at that time.

Wednesday, October 12, 2016

Project 2 Evaluation

While a lot goes on behind the scenes, our project 2 is coming together. During our meeting this weekend, we discussed different implementation strategies and overall architectural designs for our project. Based on the document requirements for our project, we discussed efficiency and running time for our implementation ideas. After a lot of fine print reading, we established a preliminary design based on a type of doubly linked-list that could be a container for lists of items. In the next couple of days we regrouped and discussed through our portal any changes and different tweaks that we could make to the design implementation to make it even better. At this stage, after many revisions our group has established a comprehensive design to implement our strategy and the general consensus is that this is a strong design.
-Ellen E.

Tuesday, October 11, 2016

Project 2 Design Documentation

After discussing amongst our group, Bryce had offered to create some UML class diagrams to further illustrate our implementation plan. Using these diagrams as a visual, we began the collaborative process of creating the document that is to be used by the group meant to implement our design. Over the past few days we have refined the document and will be posting this to our team's project 2 blog, that the next group can use as a guide.

Saturday, October 8, 2016

SE 475 - Project 2 (Design) - Buckets

For project 2, I, Matthew Smeraglia, will be the group leader. We are tasked to design the Buckets customer specifications. To plan this project, among our group we agreed to review the project and come up with an implementation plan individually. Today, we are going to discuss and review each others' plan and come to a common agreement and create a plan to move forward with the most efficient implementation. We will also be delegating specific portions of the design docs among each other.

Wednesday, October 5, 2016

My Final Evaluation of Project 1

Well, I have to admit, this project was a bit more time consuming than I originally thought it would be.  It seemed as though I was running out of time every time I started developing a new test.  I know for a fact that testing takes a long time, but for some reason this was overkill.  I'm not sure if it was the language (C#) and understanding the nuances around it, or if it was the type of program we were testing.  Ultimately, I'm not sure it matters all that much.  What does matter, is that our team finished the project on time with the amount of detail necessary to effectively test an application.  The experience we gained from this exercise will certainly help us going forward.

Tuesday, October 4, 2016

Project 1 Report

Our project is coming along! Everyone is nearly finished with their methods. The full written report is located here.

Wednesday, September 28, 2016

This week I went through the AESIllustrated code and updated the team spreadsheet with a few methods I found.  I didn't really justify between needed/unneeded methods, instead; I went through every method and calculated the cyclomatic complexity of each method I reviewed.  This specific task didn't really take much time.  However, I did find myself drifting into the code.  This drastically increased the time it took me to evaluate methods.

Ola

Methods for Unit Testing

We have devised that we will be testing for the following methods:
(Please edit and add your methods)

Matthew Smeraglia:
- Rijndael.Decrypt(byte[] input)  (CC Level 2)
- Constants.GetNumberOfRoundsLookupTable() (CC Level 3)
- RijndaelDecryptionTransformFactory.Create() (CC Level 5)
- PaddingUtilities.ApplyPadding() (CC Level 6)

Ellen Ericson
-FiniteFieldMath.AntiLog(byte) (CC Level 2)
-FiniteFieldMath.Multiply(byte, byte) (CC Level 4)
-FiniteFieldMath.CalculateG(byte) (CC Level 5)
-FiniteFieldMath.CalculateF(byte) (CC Level 11)

Ola McDaniel
-ByteUtilities.GetBytes(string) (CC lvl 2)
-Round.Inverse(State, int) (CC lvl 3)
-PaddingUtilities.RemovePadding(PaddingMode, byte[]) (CC lvl 5)
-KeySchedule.Rekey(byte[], int)

Bryce Butler
-ByteMatrix.Xor(ByteMatrix) (CC lvl 2)
-Rijndael.Encrypt(byte) (CC lvl 4)
-RijndaelEncryptionTransformFactory.Create() (CC lvl 5)
-ByteUtilities.ToPolynomial(byte) (CC lvl 7)


Monday, September 26, 2016

Sunday, September 25, 2016

Saturday, September 24, 2016

Project set up

Hi All! I have added the project to or perforce team directory. I have also added the unit test framework to the project and have added test files for each of us (designated by name). This way we can all have our own space for writing our tests.

I have also created a spreadsheet for our team to use for finding complexity and assigning methods (link here). We can each go through and add methods to the complexity pools i set up. Afterward, we can each claim 4 from each complexity to write. This way we will know who is working on what.

Blog Created!

Welcome to the team blog for Team E (name to be determined soon)!

Our Team Members include:
  • Bryce Butler (Lead)
  • Ola McDaniel
  • Matthew Smeraglia
  • Ellen Ericson