The activity diagram is all well and good, and can even be super useful in a lot of cases. But for my money, so far in my limited experience, the sequence diagram is where you really start to get a handle on what you need to do as a programmer.
Before the sequence diagram, you're dealing with steps in a process. What needs to happen, in what order, and you could just as easily be talking about employees or way stations or widgets or nothing at all. They're really about systems analysis--that high level, what needs to happen kind of stuff. Really important work, but totally dull from a programmer standpoint.
The sequence diagram is where we start seeing method names and parameters being laid out. The interaction between classes and layers. You start to see what methods you'll need, in what classes, and get a feel for what properties those classes will need. You can see the flow of the data from the start of the operation to the end, note the inputs and the outputs.
In short, this is where one starts to plan the actual code. It's bare bones, skeletal, but you see it. You determine that you complete this use case, you need a certain method in Class A, which takes XYZ parameters. You see what the return is, you decide if you're going to have one or two layers between the user and the database, all the details you need to start typing "public class BananaPeeler."
It's an extremely simple concept, and there isn't much to say about it. But as I've learned over and over and over it's usually the simple things that have the biggest impact. During the CSCI-2630 class, we struggled to sift through hour-long videos of a programmer demonstrating exactly how to code different parts of the program we were building. The struggle, for me, came from the lack of understanding of how everything fit together--the way this gentleman was hopping from class to class just seemed absolutely bananas, and I couldn't figure out how it was working.
Then a guy in my group mentioned CSCI-1275, and how we are trying to program without doing any of the ground work. This made me realize that if I had a sequence diagram, I could chart the path being taken by the the user's input down to the database and back--handy, since on that project we had 5 layers to navigate.
Once I started to spend the first viewing of the videos on developing a sequence diagram, life because so much easier. I could identify the classes I needed for a particular milestone or iteration, and that in turn allowed me to determine which classes needed to be spun up from scratch and which needed to have methods or properties added or modified. In short, it pulled clarity from the fog and turned a straight "copy from the video" process into something that I was able to understand and learn from.
In short (too late), if I can only do one diagram? It'll prolly be a sequence diagram.
Before the sequence diagram, you're dealing with steps in a process. What needs to happen, in what order, and you could just as easily be talking about employees or way stations or widgets or nothing at all. They're really about systems analysis--that high level, what needs to happen kind of stuff. Really important work, but totally dull from a programmer standpoint.
The sequence diagram is where we start seeing method names and parameters being laid out. The interaction between classes and layers. You start to see what methods you'll need, in what classes, and get a feel for what properties those classes will need. You can see the flow of the data from the start of the operation to the end, note the inputs and the outputs.
In short, this is where one starts to plan the actual code. It's bare bones, skeletal, but you see it. You determine that you complete this use case, you need a certain method in Class A, which takes XYZ parameters. You see what the return is, you decide if you're going to have one or two layers between the user and the database, all the details you need to start typing "public class BananaPeeler."
It's an extremely simple concept, and there isn't much to say about it. But as I've learned over and over and over it's usually the simple things that have the biggest impact. During the CSCI-2630 class, we struggled to sift through hour-long videos of a programmer demonstrating exactly how to code different parts of the program we were building. The struggle, for me, came from the lack of understanding of how everything fit together--the way this gentleman was hopping from class to class just seemed absolutely bananas, and I couldn't figure out how it was working.
Then a guy in my group mentioned CSCI-1275, and how we are trying to program without doing any of the ground work. This made me realize that if I had a sequence diagram, I could chart the path being taken by the the user's input down to the database and back--handy, since on that project we had 5 layers to navigate.
Once I started to spend the first viewing of the videos on developing a sequence diagram, life because so much easier. I could identify the classes I needed for a particular milestone or iteration, and that in turn allowed me to determine which classes needed to be spun up from scratch and which needed to have methods or properties added or modified. In short, it pulled clarity from the fog and turned a straight "copy from the video" process into something that I was able to understand and learn from.
In short (too late), if I can only do one diagram? It'll prolly be a sequence diagram.
Comments
Post a Comment