I don’t consider it compulsory, but it is still very useful for communicating either after-the-fact, or on a whiteboard during design/implementation discussions. Same with Entity-Relationship diagramming. The sad thing is, it’s a crapshoot as to whether the audience knows UML (or ER diagramming) these days, which reduces its usefulness. It’s easy enough to teach the basics, though, so I still do it when called for.
When I do use UML it’s mostly class diagrams. Somewhat less frequently, sequence diagrams and deployment diagrams (I find the latter to be a bit inexpressive depending upon the context/scope of what is being described).A UML, use case or any structural representation of a software serves the similar purpose as the blueprint of a physical structural compound. It helps you to understand the individual modules better and how and with wha
t other modules they will interact. Depending upon the need and current stage of your ideation/development you may start with a basic diagram initially and may later revise as and when changes happen which goes well with agile methodology.
I personally try to start with a simple representation initially and later on scale it with further development to a full scale, well defined and thorough diagram to give overview of the software.
No comments:
Post a Comment