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 laid out. There's not that many of them. Wait, I can hear it now:
There is very limited value to this project to just listing all the "things" in the domain, broadly defined, just for the sake of listing them. In fact, I'd argue the sole point would be to prove to some reader of this blog down the road that I in fact know how to do it. For my time and money (both very limited!) I think that would be better proven with the more detailed, iteration-based diagrams and ultimately a complete project.
The initial domain class diagram and entity relationship diagrams to me are like outlines you do before a rough draft--really useful if you're groping in the dark trying to find words but a painful, derailing distraction if you already know enough to string sentences together. In my CSCI-1275 class, our project was to build a system that allowed realtors and buyers to list and view houses--not a subject that I was familiar with at all. In that case, brainstorming use cases and domain objects and how they related was not just helpful but crucial to making sense of what our system had to do.
We didn't know the problems that needed to be solved, until we talked it out and mapped it. We found we had to make decisions--realtors could have multiple listings, but could a listing have multiple realtors? Could a seller or buyer have multiple realtors? Until we laid it out visually, these questions seemed to all have "Maybe?" as the answer. We didn't know enough to start defining class structures or activity flows until those had been completed.
I'm not doing a research paper that needs an outline to organize a bunch of disparate facts I looked up. I'm writing an opinion piece on a topic I've felt passionate about for some time. I don't need to puzzle out what I'm thinking, I just need to organize concepts in the most effective way possible. Don't have to go back to "See Jane run" and build complexity piece by piece in order to say "Jane outran every boy in her class, shouting 'Who wants to run like a girl now?'" do we?
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 laid out. There's not that many of them. Wait, I can hear it now:
But John--then shouldn't you just go through the motions? Throw together something in diagram form just to prove you know how to do it?And to that italicized block quote let me say, "Be patient."
There is very limited value to this project to just listing all the "things" in the domain, broadly defined, just for the sake of listing them. In fact, I'd argue the sole point would be to prove to some reader of this blog down the road that I in fact know how to do it. For my time and money (both very limited!) I think that would be better proven with the more detailed, iteration-based diagrams and ultimately a complete project.
The initial domain class diagram and entity relationship diagrams to me are like outlines you do before a rough draft--really useful if you're groping in the dark trying to find words but a painful, derailing distraction if you already know enough to string sentences together. In my CSCI-1275 class, our project was to build a system that allowed realtors and buyers to list and view houses--not a subject that I was familiar with at all. In that case, brainstorming use cases and domain objects and how they related was not just helpful but crucial to making sense of what our system had to do.
We didn't know the problems that needed to be solved, until we talked it out and mapped it. We found we had to make decisions--realtors could have multiple listings, but could a listing have multiple realtors? Could a seller or buyer have multiple realtors? Until we laid it out visually, these questions seemed to all have "Maybe?" as the answer. We didn't know enough to start defining class structures or activity flows until those had been completed.
I'm not doing a research paper that needs an outline to organize a bunch of disparate facts I looked up. I'm writing an opinion piece on a topic I've felt passionate about for some time. I don't need to puzzle out what I'm thinking, I just need to organize concepts in the most effective way possible. Don't have to go back to "See Jane run" and build complexity piece by piece in order to say "Jane outran every boy in her class, shouting 'Who wants to run like a girl now?'" do we?
Comments
Post a Comment