System Design

 

Regarding our elevator system design, we weren’t really sure how in-depth our description should have been until Professor Duvall came by and told us that we didn’t need to worry about explaining the complex algorithm governing when and where a given elevator would move to maximize its efficiency. It seemed to us that such an algorithm would be universal enough (a queuing problem) to make it relevant to the assignment. Therefore, our group wasted valuable time thinking about this very challenging aspect of the system design rather than shoring up the much broader strokes.

 

We assumed that we wouldn’t be penalized for designing a solution that wasn’t very cohesive (most of the classes were coupled with one or more classes).

 

It was only so-so for the reasons mentioned above, but the solution we provided does work. Given about 5 more minutes, it could have been tidied up quite a bit.

 

I could have made our experience better by proposing a simple “intelligent agent” design that included only sensors, actuators, and a central processing class. Although our final result ended up being a decent implementation of this (Buttons == Sensors, Control == Actuators, etc), our result could have been simpler, more abstract, more portable, and less coupled. Unfortunately, I was focusing on the trees, not the forest.  

 

Christina seemed to take more of a leadership role while Mike and I took turns as scribe, yes-person, and language-lawyer.