Voyages of a Software Dev Intern Thru The Early Years

As mentioned in the previous post , I kinda adore the sequence diagram. For me, it's the single piece that really allows one to translate the idea of a program into code. It's not exactly where the rubber meets the road, but more like the rim the tire is mounted on. Let's segue away from that odd analogy to the diagram in question. Lookit that. The simplicity. The beauty. Setting aside the fact I'm still not 100% on entity framework and have serious questions about how to implement it, I know what's going on here. I can see what gets input by the user, how it gets passed to the controller, where it goes from there, and at what point the entity gets converted to a domain model (is that a service function, or an interactor function? Hm...) and then a view model. I could sit down and write out almost everything based just on this png file right here. The trick is keeping the sequence, or unit, simple. Otherwise, you can't really break it apart and see it ...

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. I...

I mentioned it earlier at some point, but I'm not following the traditional method of system analysis and design as taught in my class. I'm skipping quite a few steps, and really what I'm planning to end up with is a little disjointed. However, I have some reasons for that--namely that in a situation like this, I feel going whole hog on the discovery phase is redundant. For instance, domain model and entity relationship model. If a student had come to me and described the problem and asked for a solution? Yes. Absolutely. I would need to sketch this out--what things am I working with? Which things are going to live in the database? Does a course have a grade like a planet has a moon, or is a course and a grade more like Mars and Uranus? These are important questions that need answered before you can get into the meat and potatoes. But...I already did that. Months ago. Before I knew what a domain class model even was, but I have the relationships and the entities all l...