On day 2, I didn’t got to the second session because I was busy having an excellent lunch with the other ladies at the conference thanks to DevChix for organizing and sponsored by Thoughtbot! When I got back, it was time for session three. I wasn’t sure what to attend for session three (day 2 in fact was much higher level, I thought than day one so I was often choosing between sessions where I didn’t really understand any of them so it was a little bit flip of a coin, but the sessions ended up being really interesting). I ended up at The Big Picture with Jim Weirich.

TL;DR: UML can help diagram code which helps programmers see it and organize it with more clarity.

The Big Picture was all about UML which stands for unified modeling language. An initial warning, UML is a visual representation so I’m writing about some of the information but in order to really get the full picture and idea of what Jim discussed, I think it will be necessary to see the diagrams and models alongside the explanatory information.

Moving into the talk, there are three primary ways that you can use UML. You can use it to sketch a process. You can use it as a blueprint and finally you can use it as a programming language. Jim talks about using it primarily as a sketch. The first example he discussed in terms of explaining usefulness was showing dependencies. When you diagram something, you really think through the code and know what your code depends on. This is shown visually via the direction of the arrows. The direction of the arrow is the direction of the dependency. You can also use this diagram to break up certain sections of the code so, at one point, on the example, the controllers were outside of the box (in red) and the application was in the green box (see, this is where seeing the diagram is obviously useful).

One of the primary examples discusses was a sketch of Rake. Rake has few classes, but the classes that do exist contain lots of methods. There is no rules class in rake. There are also no domain specific locations in rake. The application is rake. Within that application, namespaces exist and the scope is constantly changing as you define a task. The file tasks ignore scope. I had never thought about the rake task in this way and broken it apart with this methodology so it was interesting to see the task essentially pulled apart into the different commands and components that comprise it.

There was a brief discussion of object diagrams and how it is important to keep in mind that an object diagram captures how an object looks at that exact time.

He then talked about another use of diagramming when talking about creation. It related to creating a process, but more importantly he used an AR Drone to demonstrate it so pretty much all my focus went to that leaving me with little/no notes on what creating a process actually means and why this methodology is useful for it.

Next we covered dynamic engagement which is a state diagram. In this diagram, you have a start state (represented by a black dot). Then the arrows represent transitions which happen with a trigger that make an action happen which finally switches the state.

Finally, we discussed interactions which are sequence diagrams. My notes for this part are a little shady but sequence diagrams are like object diagrams but with more lines and different lines. The diagrams show sequencing calls and are timing related.

Summarily, I can see where diagraming out code is interesting and useful. After this talk, I also heard others discussing how UML is a waste of time, which I can understand as well. I think in certain scenarios diagramming and utilizing UML could be very helpful and useful but in others, I can understand how it wouldn’t make as much sense.