Wiki Wiki Wiki
James and I have been working on designing the classes related to handling database connections and performing database queries and updates. Since we originally designed the ConnectionManager class, the design has had to be retooled because not everything was thought through thoroughly enough. I think that part of these issues fall from the fact that there is no formal specification for the modules or classes. Being the Software Engineering major, and apparently insane, I feel that there is a need to start building at least semi-formal specifications of the modules and classes. This will lend some traceability to our design decisions and, if we do it properly, should privide us a better understanding of the system and reduce the number of design mistakes we make. So, to that end, I have created a Shoechicken Wiki that we may post specifications on.
It is my suggestion that Wiki pages be created for each module/class that we design, before it is actually "designed." These pages should outline the purpose of the class, how it will interact with other classes, and most importantly its behaviors and error conditions. The Wiki will allow us to easily update the specification as the need arises, which in the beginning will likely be very common but should hopefully become infrequent over time. We should probably develop a "template" for the specification of a class or module, so that all entries will contain the same information and present it in a common format.
The Shoechicken Website received a few small updates. The Documentation section saw the addition of a design page for the database classes. It was the creation of this page that spawned the idea of the Wiki, which could hold formal specifications of these designs. The site now uses a feature of Apache called Server Side Includes (SSI) to include the header on each page. This will make page maintenance much easier. Other, smaller, changes have been made across the site.
The class which spawned this mad tirade of mine is the ConnectionManager class. Originally, James and I had designed the class with a public constructor, so that any class could create one. Then, probably because it was getting late at night, decided (at my erroneous encouragement) that the class should be a Singleton which will load the settings for a ConnectionManager from a properties file. Later, James pointed out the likelyhood that eventually the item and user model databases may split, and that this approach would limit the ability to connect to multiple databases. James and I have started dicussing a Factory approach that would create one ConnectionManager per database, but would allow for multiple databases. This approach is still under discussion.
It is my suggestion that Wiki pages be created for each module/class that we design, before it is actually "designed." These pages should outline the purpose of the class, how it will interact with other classes, and most importantly its behaviors and error conditions. The Wiki will allow us to easily update the specification as the need arises, which in the beginning will likely be very common but should hopefully become infrequent over time. We should probably develop a "template" for the specification of a class or module, so that all entries will contain the same information and present it in a common format.
The Shoechicken Website received a few small updates. The Documentation section saw the addition of a design page for the database classes. It was the creation of this page that spawned the idea of the Wiki, which could hold formal specifications of these designs. The site now uses a feature of Apache called Server Side Includes (SSI) to include the header on each page. This will make page maintenance much easier. Other, smaller, changes have been made across the site.
The class which spawned this mad tirade of mine is the ConnectionManager class. Originally, James and I had designed the class with a public constructor, so that any class could create one. Then, probably because it was getting late at night, decided (at my erroneous encouragement) that the class should be a Singleton which will load the settings for a ConnectionManager from a properties file. Later, James pointed out the likelyhood that eventually the item and user model databases may split, and that this approach would limit the ability to connect to multiple databases. James and I have started dicussing a Factory approach that would create one ConnectionManager per database, but would allow for multiple databases. This approach is still under discussion.
posted by Michael at 4:38 PM
0 Comments:
Post a Comment
<< Home