User:Chen Qing
Hello everyone, welcome to my home page. I am a 2008 cosc427 student.
Contents |
Design Study
Recently I have built a “quick and dirty” MS Access based VBA application for a friend. The application is for helping a small printing company to maintain their job records, organize their job flow and providing some reporting function etc. I thought this is a good case to exercises what we have learned through the cosc427 lectures (and also past courses), so I reworked on this application and will build it within an object-oriented environment. This application also connects to a backend database, for the purpose of this design study, I will only consider the basic structure for the business logic layer.
Main Design Decisions
Print Product Family
A good point for start is to model the actual print products produced by the company. At present, there are two main types of print products, one is single sheet/page product, and the other is multiple sheet/page products. The example we chosen to model here are book, business card, NCR booklet and pad. The type of the print product is limited by the actual hardware (printing machine) and employee skill sets. All of the print products are share some common properties and also has some unique properties. The design for this part is illustrated in the following Figure 1.
PrintCompany class is the main class used to represent the printing company. The company holds references to its customers, employees, external contractors (this is quite often used for some design works), and departments. The print company also has a job queue which is used to track all the jobs. Object PrintJob is used to represents each individual print job (their orders). For each individual print job, it could have one or more final print products. Also for each print job, there is a state associated with (i.e. in quoting state, in designing state and in pressing state etc.). The design details for print job and print products are illustrated in Figure 2.
Main Design Decisions
Print Job State Capture
The state for a print job originally is used for system tracking purpose; it is also evolved to provide a precious cost calculation function for each stage of the printing process. In ordinary situation, the company and customer will agree on one quoted price for the entire job, therefore, knowing the actual cost of each job in each printing stage (state) becomes critical. However, the cost calculation method for each state, which is usually done by different department, is drastically different. In order to control the differences in the cost calculation and also maintain a unified interface to the PrintJob, the State pattern is used here.
Family of the Print Product
Various kinds of printing product are produced by the company, and there is going to be new print product added/old print product removed once a while. In order to cope with this requirement and decouple the relationship between client class and concrete print product classes, a common interface PrintProduct is introduced. The print products have been categorized into the single page product, and multiple page products. Examples of them are business card, pad, book, and NCR booklet. The Composite pattern is used here and with all the essential attributes required by all concrete print product classes, so the client class can deal with different concrete product in a uniformed way. Corresponding to the code, PrintProduct interface is the ‘component’, Booklet abstract class is the ‘composite’ and we had BusinessCard, Pad, Book, and NCRBooklet as the ‘leaf’ classes.
However, some problems have been identified with this design, see Problem Yet To Be Solved for more details.
Job Queue Observing
The print company has a job queue used to track all the current jobs, this enable client to know which state of a particular job is in. Department and other people necessary for a print job (i.e. external contractor). Each department and external contractor has a current job queue referencing to all jobs in the company job queue but only the content needed for them. Once the main company job queue gets updated, we also want the current job queue gets updated. The Observer pattern is used in this case. However, currently there is no content filter for the job queue, which is not acceptable, see Job Queue Observing Content Filter under Problems Yet To Be Solved for more details.
One instance of Print Company and Job Queue
To ensure all the client code is talking to one and only print company and job queue across the application. The Singleton pattern is used to ensure this.
Problems Yet To Be Solved
(Hopefully all the problems identified will be solved before the due date.)
Flow of State Transition
The control for the flow of state transition is currently depended on client code to call the set method to set to the new state while all jobs in the old state are finished. Customer requires the application to be able to transit the job state to a new job state once the work for previous job is finished. Furthermore, not all jobs will require all states.
Noop Operation
For the print product family design, the Composite is used for provide a uniformed interface for client classes who needs to work with any concrete print products. However, not all properties of the common interface are valid for all the concrete products. For example number of pages (numOfPages) doesn’t make sense for business card, drillHoles does not make any sense for a book, number of leaves only make sense on NCR booklet. In the implementation of the concrete children classes, the irrelevant methods are done as no-operation method to conform the interface. However, in reality, there are far more unique properties for each kind of print product, we will ends up with huge number of no-operation method. We know we have to face the tradeoffs in the real world, but for a simple business card to include another one hundred properties which only valid for a book is seemed to be too much. Probably a better design should be provided here.
Content Filter for Job Queue Observing
The Observer pattern only provides us a way to ensure department and external contractor get notified when job queue changes, however, we need the change reports to be different based on received roles. Using Strategy to encapsulate the get job queue seems to be a better choice (working on progress).
Design for the Data Access Layer
Coming soon ...
Print Product Creation
Coming soon ...
Used Design Patterns
The design pattern used so far are:
Violated General Design Principles
Coming soon.....
