Visual Patterns

Personal Opinion: UML Diagrams

2009-08-13T21:56:00.000-07:00

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 diagrams. 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/alternative ways to do what some of these diagrams do (at least not yet anyways but eventually I hope to as I'm currently conducting some research in better ways to model/diagram -- check this website for updates periodically, if you are interested).

Meanwhile, I do use UML diagrams when appropriate because I do think they add value when used in the right place and at the right time. In fact, I feel 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 is that it requires special tools, which can be expensive for an organization due to software licensing costs. In addition, some of these tools can have a steep learning curve and hence require potential 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 ability 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 since it enables you to create flowchart-like diagrams. I use connectors extensively as you will see in many free-form diagrams in my work (books, articles, etc.).

Also, I tend to follow practices recommended by Agile Modeling such as modeling with a purpose and producing good enough artifacts. Furthermore, I only update these when it hurts, since many artifacts can be thrown away after they have served their purpose – after implementing a design in code, you already have your documentation… yes, 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 till 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, "your goal is to build a shared understanding, it isn’t to write detailed documentation".

From Java to Ruby... and Back

2009-08-13T21:53:00.000-07:00

View a presentation from JavaOne 2008 (PDF; 8.4 MB), titled "From Java to Ruby... and Back." Learn how and why Java and Ruby work so well together.

AMDD using Comic Illustrations

2009-08-13T21:51:00.000-07:00

See an Agile Model Driven Development (AMDD) 8-week project illustrated using comics.

Concept: Agile Draw

2009-08-13T21:49:00.001-07:00

Agile Draw - A virtually notation-less freeform technique for conceptual modeling and marketing your design to others. Highly complementary to UML and Agile methods.

(Disclaimer: I probably could have picked a better name than Agile Draw since the word "Agile" is so hyped.)

Effectively Developing Software

2009-08-13T21:47:00.000-07:00

View a 24-slide presentation (14MB PDF) on how to effectively develop software using agile processes and models.

Concept: Continuous Software Construction Snapshot

2009-08-13T21:35:00.000-07:00

In my opinion, the Unified Modeling Language (UML) is best suited for physical/detailed modeling of a system (i.e. blueprint style; for conceptual modeling, I prefer something along the lines of Agile Draw). I believe UML particuarly shines for reverse engineering diagrams for an existing system, such as the UML package and class diagrams. Recently, I have been thinking of a concept I call Continuous Software Construction Snapshot. This concept is closely tied (and highly complementary) to the Continuous Integration concept described by Martin Fowler and Matthew Foemmel at http://www.martinfowler.com/articles/continuousIntegration.html -- this new concept is described next.

UML diagrams can be reverse engineered typically using a UML diagramming tool such as Rational Rose, Borland Together, Poseidon, OmniGraffle, or a variety of other tools -- this is done manually by a person. However, in the past I have used a tool that generated UML diagrams automatically (e.g. on the server side). In the late 90s, I had launched a site called isavix.net (now developerhub.com), which grew to over 100,000 registered Java developers and won several awards. This site focused on providing free and unique tools versus content. Among other things, we provided a tool called "My UML Diagrams". This tool enabled users to upload .java and/or .jar files and automatically generated a class diagram on the server side using these file(s) as input.

Given the manual and automatic server-side UML diagram generation I just described, leads us to the notion of Continuous Software Construction Snapshot. The idea behind this is to show people (e.g. project leads, developers) continuous progress of a software being constructed (developed); it also allows developers to see where their piece fits into the big picture. Similar to how one can see a building or home being constructed, we should be able to get a view of the software under construction. This can be done as follows.

Each time a build (continuous integration) happens, a package diagram and class diagrams are also generated.

Alternatively, these diagrams can be generated at the time they are needed (e.g. when goes to a web site to see the state of a software application).

For example, these generated diagrams could be viewed via a web browser. The first view (presumably after some sort of a welcome screen) a person would see is a package diagram, as shown next.

From the package diagram, the user could drill down into a specific package (e.g. web in above diagram) to see a class diagram (shown next) for the classes within that package.

Note: It is important to keep the level of detail in the generated diagrams to a minimum, in order to make this concept useful.

The next level of detail could be the source code (e.g. actual code, revisions, unit test coverage), perhaps using web-based view of a CVS repository, as shown next.

Some benefits of this continuous snapshot approach could include:

Ability for developers to get a "big picture" view of the entire application being coded by multiple developers.

Getting a birds eye view of how much of the coding (construction) has been completed.

Determining average lines of code produced per developer (e.g. to determine Mythical Man-Month type stuff).

Measuring percentage of unit test coverage by comparing unit test code to actual code.

Comparing project velocity to lines of code coded for each iteration.

In summary, Continuous Software Construction Snapshot can give a project lead, developer or other, a high level view of the application, while enabling them to drill down to details - using this combination of a big picture and low-level details can provide an in-depth understanding of the status and overview of a software application... as it is being built.