I’m having a difficult time wrapping my head around the best way to lay out my classes for an application. I’ve included an attachment of what I have so far and am wondering if I’m headed down the “right” path since it all seems so convoluted.
Basically, what I have is a collection of Project objects, each of which has a collection of Department objects, a collection of Project Qualification objects, a Job Scope object and an Estimate object. Each of the Department objects, in turn, has a collection of Drawing Category objects, a collection of Drawing objects, and a collection of Standard Qualification objects. Each Drawing object references one Drawing Category (I thought I’d use a NameValueList of Categories for this), one or more Standard Qualification objects (another NameValueList), and one or more Project Qualification objects (yet another NameValueList). On top of this, the Estimate object references the Job Scope object and all the Drawing objects pertaining to a Project grouped by department by sub-department for reporting purposes. Should I go on and make the Job Scope object a singleton child of the Estimate object? What of the rest of my layout? Am I headed down the “right” path?
i may be wrong since i dnt knw the entire BL but here are some points which i noticed after seeing yr class diagram:
1. why is there an association b.w deptt and DrawingCategries(DCs)? I mean, a DC is related to a Drawing, so by putting the a list of DCs in Deptt object you will have duplicate DC objects in the Deptt object as: (i) DC objects in the DC List (ii) DC object in each drawing object in the Drawing objects list. Is DC is also categorised deptt wise? Same thing with StdQualification objects.
2. Each project has a JobScope and an Estimate. Now each estimate references a Job Scope object. I think there is a redundancy here if i am getting it correctly. There is no need for a JobScope to be associated with a Project directly when it is inside an Estimate already.
Tell me if my points make sense.
vivek
Your points are well made. This has been a case of not being able to see the trees for the forest rather than the more common occurrence of not being able to see the forest for the trees. What use cases I've been able to form have come through poring over code for the current product that is definitely non-OO; it was written in dBase III/IV between 1991 and 1993. Anyway...
For each Department, there may be several Areas, each of which has its own Drawing Categories. The DrawingCategoryID for these consists of one alpha and three numerical characters, with the alpha character representing the Area. Each Drawing object must contain a DrawingCategoryID. Each Department also has its own StandardQualifications, which are non-Area specific. Each Drawing object may contain a reference to one or more StandardQualification objects; the case is also true for ProjectQualification objects. Because of this, I decided around 4 a.m. this morning to handle the Drawing object somewhat along the same line Rocky does with the Assignment object in PTracker.
I've also decided to make JobScope part of the Project object. As originaly designed, in dBase III/IV, the job scope could be modified by anyone having write privileges regardless of what Department they were in. Thus, someone in Architectural could make an entry for the job scope and someone else in Machine Design or Piping could come back and edit/delete/overwrite what had been entered. Definitely a flawed design. So I'm now going to allow only Project Managers and their superiors access to this field. I'm also going to handle ProjectQualifications pretty much the same way.
I strongly suggest designing your objects based around your use cases, not your data. You do not appear to be describing objects in terms of their responsibilities or roles in a use case, but rather in terms of their data relationships - and this is a recipie for a lot of pain later.
You should be thinking about all the various scenarios through which users will interact with your system. Each of them is likely a use case. Beneath each user interaction is a "business use case", which reflects that actual business task the user is trying to accomplish.
Implementing a business use case (not the user scenario - because that often has UI components) requires objects. Each concept and step in the use case should be represented by an object, and each of those objects should have exactly one responsibility.
Chapter 6 should give you some more informatoin on this way of approaching the design task.
Copyright (c) Marimer LLC