You can see that main begins first (because its first activation is higher than the others). Between the activations are dashed lines called the life lines of the objects. The vertical boxes, or activations, represent the life of a call. Arrows represent method (or function) calls. The script is in the main package (which is always Perl’s default). The sequence diagram for the die rollerĮach package has a box at the top of the diagram. My ($total, $doubles) = $die_pair->roll() įigure 1 shows the sequence diagram for this driver.įigure 1. Rather than modeling a real game like craps, I use a small driver, which will simplify the resulting diagram. It returns both total and doubles, saving the driver from having to call back for them. The roll() method rolls each die, storing the value, then totals them and decides whether the roll was doubles. The constructor makes two die objects and stores them in a hash reference, which it blesses and returns. Return bless = ( $value1 = $value2 ) ? 1 : 0 To roll the dice, I wrote a little script. In it, I made each die an object of the Die class and the pair of dice an object of the DiePair class. My over-engineered solution gives a nice diagram to discuss. I’ve diagrammed many non-OO programs with it (including some in COBOL).Ī simple example will work best for a first look at UML sequence diagrams, so consider rolling two dice. Don’t think that objects are necessary for sequence diagrams. If you already know how to read sequence diagrams, you can skip to the next section.īecause most uses of UML involve object-oriented projects, that’s where I’ve drawn my examples. You can even run it against existing programs to have it diagram what they actually do. Using UML::Sequence, you can quickly make proposed diagrams of systems not yet built. With recent help from Dean Arnold, the current version has many nice features and is closer to standards compliance (but, both Dean and I prefer a useful diagram to a compliant one). Therefore, I wrote the original UML::Sequence to make the drawings for me. While the sequence diagram is useful to me, I don’t like on-screen drawing tools. In short, sequence diagrams help with complex call stacks just as data model diagrams help with complex database schema. For complex systems, these diagrams can save a lot of time–like the time you and your fellow programmers spend during initial design, the time spent explaining what’s possible to management, the time you spend remembering how things work when you revisit an old system that needs a new feature, and especially the time it takes a new programmer in your shop to get up to speed. (I’d show you mine for the situations above, but they’re secret.) Sequence diagrams clearly show the time flow of method or function calls between modules. In both of these cases, the right diagram is the sequence diagram. Three months from now, when an odd bug surfaces, it’ll be nearly impossible without the right memory aid. Keeping them in mind is hard enough when I’m deep in the problem. All the account creation code is in the customer care app.” It didn’t take long to find the relevant web screen, where the CSR presses Save to kick off the account creation, but there sure were a lot of layers between there and the final result. He came in to the bat cave and said (in summary), “We want customers to sign up for email accounts without calling customer service. Imagine me handling a recent request from my boss. Someone says, “Perhaps you could draw us a picture.” After a couple of sentences, you see some eyes glazing over. You’re about to begin your third attempt to explain how to process online credit card payments. Imagine yourself in a meeting with management.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |