This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
How to draw architecture diagram for an s/w application? what are the pre-requiste for architecture diagram? (what info should i gather to design arch. diagram?) what are the factor that i should keep in mind while designing?
One step in making any diagram or document is to fill in these blanks:
_____ reads _____ to learn _____ so they can _____
If you know that, you're much closer to knowing what goes in the document, if you even need a document instead of a conversation.
For almost all of my diagrams, the first blank is somebody outside the team. Within the team we communicate other ways. (The other common consumer is "I, myself" which indicates a design so complex I can't keep it in my head ... a bad sign for sure.) A variety of external people demand something called an "architecture diagram" but with completely different values in the last two blanks. Some variations:
* Some combination of all the networks, servers, load balancers and such with server names, IP addresses and ports, manufacturer and model, memory and CPU specs, physical locations, protocols, etc.
* All the products used, versions, etc.
* Major software components
* Detailed class diagrams of certain components
* Business architecture - how my system fits into the business processes throughout the company along with other systems.
* Capacity - Number of user seats, concurrent users, transaction rate, throughput and response time expectations.
I have "reference diagrams" for all these (and more) on the team Wiki so we all know where the very latest "golden" version is. Anybody can throw them into new documents or presentations on demand.
So, that was probably no answer at all, was it? Take this away: Fill in those blanks first. Yes, that's the hardest part but without it the rest is quite likely wasted effort.
BTW: Thanks for the link to SurfScranton. That material is aging ... I weelcome any feedback on how it could be better.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Stan James: _____ reads _____ to learn _____ so they can _____
Stan, Do you have some examples for your rule above ?
Usually we do this way. We got project, two person, one Dreamweaver guy, one OOP guy will be sent to client site. They will catch user requirement. When user describes his requirement, Dreamweaver guy will instantly draw its web GUI and enter some mock data. OOP guy will ask some OOP question to clarify, most of time, the objects relationship.
After this, 80% job in design phase is done. We use agile, and write/reuse coding generation tool.
In my experience, draw-web-GUI is very, very important, this is something we could see, touch and modify. And the team could easily switch to another business track.
I have been reading some UML book, sometimes, I feel that those person make a simple question too complicated. I found my way is not in their category.
What is your way to handle user-requirement-capture and design? any comments are welcome.
Joined: Aug 19, 2005
In most cases agile processes de-emphasized GUI layout during requirements acquisition and they will not include GUI details in any requirements artifacts like use cases or user stories. Acquiring requirements is all about discovering the user needs - not how things look and how they are manipulated.
On the other hand users tend to love defining the GUI during requirements aquisition and always ask "show me a screen" - to the point that they forget what they really need. [ December 06, 2006: Message edited by: Peer Reynders ]
Joined: Jan 29, 2003
Another vote with Peer. We had a bad experience with gathering requirements through prototyping. Some GUI cowboys on the team made up the most bizarre things that the customers just loved and we were stuck with a confusing non-standard paradigm for years that didn't really work that well in the field.
We've also had bad experiences from inadequate prototyping. You may not recognize contradictory ideas in text that jump right out when you try to draw the flow through the system. Stick with that "low fidelity" idea, though. Hand made drawings that go into just enough detail to make sure everybody has the same vision.
After this, 80% job in design phase is done. We use agile
What do you mean when you say that you "use agile"?
I'm asking because in my view, the whole notion of a "design phase" is highly incompatible with Agile approaches.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus