I’ve been asked to go through an existing ASP.NET application and “Document the logic flow” of the application. Being a student, and having never done this before, I am wondering what sort of information people would typically include in such a document?
The explanation I was given for what was wanted was vague, and I assume that the primary objective here is for me to understand how the application works.
The appliction has multiple layers, which look roughly like so:
UI Layer -> Presentation Layer -> Controller Layer -> Data Access Layer
Each layer has logic that accomplish various tasks, so I will need to traverse each layer section by section.
Any suggestions? Vague I know, but I’d be glad to clarify if required.
Here are the different perspectives that are common. You should clarify sooner rather than later what they are looking for. You could also sound more pro-active by starting with a proposal, say, the component and behavior perspectives.
Types (These terms are Google/wiki friendly:
In documentation it is critical to also understand what the objective is.
You must understand how the competing readers needs interact, Brevity vs Non-technical vs Complete vs Accurate vs Aspect
For example: it would be impossible to have a Complete, Non-technical, Network Diagram, as Port numbers and firewalls would be lost on them. Or a Brief, complete, Process Flow would also be difficult.
Summary: So a good default answer is 1. Create a summary description, if your audience does not even know the system. One paragraph for the business function and one for the application structure/components. 2. Do a component diagram, include the packages and utility libraries, etc. 3. Create a method/class level sequence or flow diagram of the major path of execution. Then go back to the requester and ask what they are looking for and show them what you have so far. Assuming the requester is a technical leader of some kind. Without more details this recommendation is rough at best.