Application Diagram

Pauldohert

Something in here
Local time
Today, 06:28
Joined
Apr 6, 2004
Messages
2,101
Can anyone point me in the right direction to produce an application diagram.

Sort of a map of an app, what data it hold in laymans terms rathers than table and field definitions. What forms do what, and how the whole application fits together.

Thanks for any assistance you can offer.
 
This is DEFINITELY a case of putting the cart before the horse.

You should have had a design diagram and supporting documents for the project before you wrote the first line of code (or pseudo-code).

There are some commercial products that can take database schemas and product pretty pictures. But in the final analysis, they cannot read your mind and probably won't correctly decipher your abbreviations.

The way to produce this document is to find several key items:

1. Wood-encased manual marking devices with rubber mark removers and a tip renewal tool with conically arranged rotating grinder-blades.
2. Rectangular flat surface with attached illumination sources
3. Pounded, rolled, or otherwise flattened, bleached fibrous markable substrate with imprinted rectangular reticulation pattern

Or Pencil & Sharpener, Drawing Board with good lighting, and Quadrille-ruled Paper if you aren't into GovSpeak.

Which leads to the philosophical question: Where did the guy who invented drawing boards go back to when the first attempt failed?
 
ROFLMAO. But oh so true.
 
The_Doc_Man said:
Which leads to the philosophical question: Where did the guy who invented drawing boards go back to when the first attempt failed?

He went back to
1. A wood-encased manual chipping device powered by a heavy blunt striking instrument and a tip renewal tool which may have been broken off from the cave's superstructure.

2. A not so rectangular tablet made of granite, marble, slate or similar substance placed upon any handy spot that did not cause pain.


Oh sorry, ;)
Try a google search for what you are looking for
 
Seriously, Paul, your question about "what data it hold in layman's terms" can ONLY be answered by the designer. Unless you used layman's terms for the field names? The same is true for "what form does what" and "how the whole application fits together." These are NOT technical questions. They are marketing questions. Access doesn't have a marketing-tool extension unless you happened to have built one into the app itself.

There is a basic principle at work. NO database can give you back data that you didn't put into it in the first place. It can only show you what is there. If any kind of relationships exist, you can use Access to EXPLORE the data using "what-if" type queries. Like, what do I see if I join Field A in Table 1 with Field B in Table 2. Does anything match up? That sort of "what-if" query.

So if your table's descriptive data doesn't include that kind of information, NO tool exists anywhere on this planet that will do any better at producing your required documentation than that complex processing tool behind your eyes and between your ears. And your question tells me that you FULLY exploited one of the greatest strengths of Access - its use as a Rapid Application Development (RAD) tool. The problem with RAD tools is keeping the design up when the implementation races ahead of you. Which I think must have happened in your case.

All I can say is: Been there. Done that. Paid way too much for the souvenir T-shirt.
 
Total Access Analyzer by FMS INC. (www.fmsinc.com) creates numerous reports regarding the objects in your database. It includes what it calls an Application Diagram and a Data Diagram. These present outlines of application objects and data objects respectively. You can download a sample that shows the structure of the northwind.mdb to see if it suits your needs.
 
Thanks Pat I will look into Total Access Analyzer.

Docman - I love the condesecending assumptions you have made. The irony being you have offered a solution largely based on wrong assumption. I am sure you could lecture me on how a solution based largely on a wrong assumption is worth little fully documented or not.

I could as you suggest just use my Brain to come up with what I require, I was hoping to use the superior knowledge of others and their experience, standing on the shoulders of giants as it were.

Thanks again Pat.
 
Paul, if I'm wrong, I'm wrong. It happens. I won't even be so arrogant as to add "sometimes." It happens more than "sometimes."

But I will say this: I answered the question as I read it, not necessarily as you originally meant it. I only have the inferences available through reading. Face-to-face, I might have come up with a different answer after a brief discussion. It is a pitfall common in this forum. Besides which, as everyone knows, us government workers are ALWAYS jumping to confusions.
 
No worries Docman - you have offered me useful advice in the past. The document is for senior management to use as a way of quickly establishing what application tools they have available to them, and how it all fits together. Something technical or remotely verbose they wont read, pretty pictures they may like.

Basically I need something to inform those who haven't the time or inclination to be informed properly.

Its a dirty job and someones got to do it. You are correct what I need is a marketing tool of existing applications and how managers could/should implement them.
 
Oh, Geez... it's for senior management. God help you!

(By any chance do any of them have pointy tufts of black hair surrounding an otherwise "chrome dome"?)
 

Users who are viewing this thread

Back
Top Bottom