Personal Opinion: UML Diagrams Over the years, I have used several types of UML diagrams, including the essential class diagram, package diagrams (my favorite), and the less-often seen deployment diagram. Then there are ones that I am not a fan of, such as the popular sequence diagram. I don't like this diagram because I find it gets complex and cumbersome quickly. However, I'll be the first to tell you that I do not have better and alternative ways to do what some of these diagrams do (at least not yet anyway, but eventually I hope to because I'm currently conducting some research in better ways to model/diagramcheck the visualpatterns.com website for updates periodically, if you are interested). Meanwhile, I use UML diagrams when appropriate because I think they add value when used in the right place and at the right time. In fact, I think UML diagrams are most useful when generated using reverse-engineering tools to document the system already built (perhaps during a system handover). I hope I don't come across as being dismissive about UML, because this isn't quite my intention, especially since it took a lot of work over a number of years from some intelligent people to make a standard such as UML even possible. (In fact, this is precisely why I'm basing all my research on work that has already been done instead of simply trying to reinvent the wheel.) My main complaint about UML diagrams is that they get complex very quickly, specially for larger projects. Another issue I have with UML is that it requires special tools, which, because of software licensing costs, can be expensive for an organization. In addition, some of these tools can have a steep learning curve and hence require training for the people using these tools (one common example being Rational Rose), resulting in additional cost to the organization. Furthermore, simpler tools such as OpenOffice.org, Microsoft PowerPoint, Microsoft Visio, and other similar tools provide the capability to connect a variety of shapes (rectangles, for example) using connectors, which are essentially straight or curved lines that connect two objects and stay tied to those objects when you move them around. This is a powerful feature because it enables you to create flowchart-like diagrams. I use connectors extensively, as you will see in many free-form diagrams in this book; in fact, almost all diagrams in this book were developed using OpenOffice.org! Also, I tend to follow practices recommended by Agile Modeling, such as modeling with a purpose and producing good enough artifacts. Furthermore, I update these only when it hurts, because many artifacts can be thrown away after they have served their purpose. After implementing a design in code, you already have your documentationyes, the code. (As I mentioned earlier, code can be reverse engineered to produce pretty class and other diagrams.) What makes the idea of heavy documentation seem like sheer madness is the fact that I cannot recall one software development project where the documentation was maintained until the very end and matched the end product. This is the case because we live in a fast-paced world with sometimes unrealistic software delivery deadlines, and it becomes a difficult task to keep the documentation up-to-date. In summary, use UML diagrams when appropriate, but don't be shy or hesitant about using simple, yet effective, free-form diagrams. Let me end by providing the same blurb from the agilemodeling.com website I provided in Chapter 2: "Your goal is to build a shared understanding, it isn't to write detailed documentation." |
