Should a developer adhere to the class diagrams produced during system design?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.