File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Architecture Diagram Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Architecture Diagram" Watch "Architecture Diagram" New topic
Author

Architecture Diagram

S Thanigaivel
Ranch Hand

Joined: Oct 06, 2005
Posts: 60
Hi,

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?

Thanks,
Thanigaivel
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
You may find something of interest in

http://www.surfscranton.com/architecture/ArchitectureHome.htm

http://www.ratio.co.uk/W13.html

as mentioned in suitable architecture pattern

Also have a look at
Agile Architectural Modeling
Agile Enterprise Architecture
Architecture and Architecture Modeling Techniques
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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
Edward Chen
Ranch Hand

Joined: Dec 23, 2003
Posts: 798
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.

Thanks.
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
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.

Usually Low Fidelity User Interface Prototypes are used to drive out requirements - not to define the GUI specifications.

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 ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Edward Chen:

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
 
Consider Paul's rocket mass heater.
 
subject: Architecture Diagram