The class diagram is modeled on the system requirements, and it is important to create solutions based on those requirements. If I have said class diagram should I strictly adhere to it? What about refactoring? What if the diagram did not provide some design principle that I feel were left out?
-
1I think you answered your own question with "What if the diagram did not provide some design principle that I feel were left out?". Software development is about writing good maintainable code, not about strictly following requirements if they prove to be faulty.– ysolikSep 23, 2010 at 13:59
-
1yes and no. If the design is flawed you should go back to the designer. You should not go rogue and ignore the design.– jwentingNov 10, 2011 at 14:26
-
Feel free to take "were left out" bits and pieces as a sign post that you need to improve your design skills, not turn cowboy. Refactoring is an iteration on the design, not an ad hoc process to engage in while writing code. If this sound onerous then take that as a sign post that your cycles are too long ;-)– Patrick HughesFeb 17, 2012 at 18:14
Add a comment
|
3 Answers
Short Answer: No.
Your output should be working (hopefully tested) code that performs the business function it's supposed to do. How you accomplish that task shouldn't be mandated (again, unless you work for NASA).
A lame analogy: I get into a taxi and tell them where to go. I leave it up to them to drive me there. I trust them to get me there safely and in a timely manner. I am not going to sit there and micromanage the taxi driver and tell him when to turn on his turn signal, how much to press the accelerator, or when to get gas. That's his job.
-
In addition, a class diagram should be treated as a starting point because that's what it is. It is common to discover a need for additional classes (aka more code encapsulation) after you start adding the code for the classes. Sep 23, 2010 at 16:00
-
2Add "and delete the now out-of-date class diagram" as well, before some poor sucker thinks the class diagram's still an accurate reflection of the codebase. Oct 19, 2010 at 12:39
-
@Frank, honest question... In your experience, does the UML contain design information that isn't as accessible from the code? If so, I'd hesitate to delete even an out-of-date diagram... Feb 17, 2011 at 16:44
-
1@Aidan I hardly ever use UML. My point's more that artifacts tend to get out of date, so unless the UML diagram's generated on the fly from the code, it's wrong. It's wrong, and it looks easy to grasp, but because the code's changed, you think you know something but you don't. Feb 17, 2011 at 20:28
You have class diagrams in your requirements? It should be part of a specification, not your requirements, but I guess everyone's shops are different ;) It's important to adhere to your spec. If you don't, you may be impacting another area of the application without even knowing it when you deviate. If the spec is wrong, you reopen it, communicate the change and have it reviewed and then change code. Even when you disagree. You may not know all of the reasons one implementation was chosen over another.
The following points are presented for you to consider before making your decision, the idea is to examine the factors that would generally affect a case such as yours.
Point 0: You need to implement all the business rules whatever your implementation style may be.
Point 1: In UML, Class Diagrams are only part of the entire model. There are other diagrams that utilize defined classes such as Use Case, Sequence, etc.
Point 2: In OO applications using RDBMS you need to decide whether your application is built using an Object First Approach or a Data First Approach. Based on this the domain model is built. The two types of model may be very different. See: Object Relational Imp. Missmatch.
Point 3: In OO and partially as a result of point #3, objects representing the database layer may be different from objects that are used in other application layers or services. If you are using web services, then chances are the API would even define objects in a different way than you business layer definition and the data layer definition.
Point 4: UML models have phases, usually defined by a methodology as in Mapping Models to Dev. Process, each phase may produce a different model. Changing an implementation phase model is of course, the least desirable and most critical due to its impact.
Point 5: You should consider the impact of change on the project life cycle stage, its existing data if any and on other fellow workers and DBAs.
