During the design stage, I usually come up with a class diagram that looks something like this
However, during coding stage, I would never create a class like Librarian with issueStatus() or searchBook() method.
100% of the time, class Librarian, will be a plain-old-object with only getter and setter method, and issueStatus() or searchBook() functionality will be implemented in a class of it's own (possibly class IssueStatusActionHandler or class SearchBookActionHandler, which will be triggered by user action (e.g clicking a button)
Does this mean that I have to include the software architecture during the design stage, or do I need to revise my class diagram documentation in parallel with coding?
Best Answer
It highly depends on your goal of what to achieve with your design.
As it seems, you are not targeting a code generator that directly translates your class diagram into code. Hence, the diagram is just that: a pretty picture. You may want to first rethink the actual value you get from it and why you are making the effort. Contrast that to scribbling out the diagram on a whiteboard with your colleagues and once you're all satisfied, take a photo. What's the big difference?
As for your questions: Do you need to include architecture in the design stage - we'd hope so. The whole point of architecture is to be a framework into which you fit your design considerations. So clearly, you will have to take it into account.
Do you need to revise your diagram during code? This again depends on why you have that diagram. If you want it to describe your code, then obviously it needs to be revised. If all you need is to be able to tell people "look, this is how we envisioned it three years ago. Nothing in the code is anything close to that now though" then feel free to neglect it.
Should you however have a need for an up-to-date UML diagram, then I strongly suggest to move closer to actual modelling (as opposed to simple drawing) such that you can generate code and therefore ensure that the diagram is really corresponding to your code.
Finally a remark on your "100% of the time" way to write your code: While this has nothing to do with your actual questions, I urge you to reconsider your idea of writing business logic (like issuing a status) into action handlers. This violates many good design principles. If you like to read, you may want to take a look at the DDD book by Eric Evans to get a better idea of how business logic like that is served better.