I may work on this a little more over time, but here’s a little look at what errors, checked exceptions, and unchecked exceptions look like in Java:
Here are three nice diagrams drawn by Mariko Kosaka that explain HTTP and HTTP2.
Every once in a while when something hits you, you really remember it; it stands out in your mind as an “Aha” moment. One of those moments for me was when I saw a particular “Model/View/Controller” (MVC) diagram, and the light bulb went on. This diagram made the MVC pattern very simple, and I’ve never forgotten it.
When I first started working with Scala, I thought I’d need to really, really understand the Scala collections class hierarchy. After a while, I realized that wasn’t necessary; I just needed to focus on what was important.
If you’ve never read the book Use Case Driven Object Modeling with UML by Doug Rosenberg and Kendall Scott, you’re missing one of the most simple and important Model-View-Controller (MVC) diagrams in the software business.
In their discussion of Robustness Diagrams they introduce a figure called “Robustness Diagram Rules” that succintly tells you how to implement an MVC design in your code. In one figure they tell you:
Question: What UML diagram can I use to show how my application will be distributed in the real world?
Use a UML deployment diagram. They can be used to conceptually show the physical nodes and software components that will be distributed in a software application.
Question: What UML diagram can I use to show how an object state changes during its lifetime?
A UML state diagram will do the trick. A state diagram is very good for showing how an object state changes over the lifetime of a software application, and the triggers (triggering events) that cause the state to be changed.
Question: I want to visualize the activity in a use case ... what UML diagram can I use to do this?
Use an activity diagram. These UML diagrams are good for visual workflow modeling. Swimlanes in UML activity diagrams can also show the behavior of different actors within a workflow process.
Following a speech two days ago, I'm struck by how very little we use the Unified Modeling Language (UML) on our software projects. Occasionally I'll create some activity diagrams to model how users get their tasks done, but that's about it. Typically when we create a software requirements specification this is what we deliver: