CODEWITHSUNDEEP
.netumllogicdocument
Ray
Ray

Reputation: 1442

How to properly document logic flow of an application?

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.

Upvotes: 2

Views: 6623

Answers (3)

Ted Johnson
Ted Johnson

Reputation: 4343

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:

  • Information Flow
  • Functional Decomposition
  • Solution Stack/Technical Placement
  • Component/Structural/Class
  • Behavior - Sequence, Communication, Process Flow
  • Detailed Logical Flow (if, then, for, methods, etc?)
  • General Overview/One pager
  • Business Logic/Usage/Interaction
  • Network/Topology

In documentation it is critical to also understand what the objective is.

  1. Share with a business partner?
  2. Share with a leader, technical?
  3. Is it an introductory or high level view?
  4. Who is your audience?

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.

Upvotes: 3

paparazzo
paparazzo

Reputation: 45096

Microsoft has some conventions and tools for inline documentation. http://msdn.microsoft.com/en-us/library/b2s063f7(v=VS.100).aspx But this does not really deal with flow. Rather how to add comments that roll up.

Upvotes: 1

Matt Cashatt
Matt Cashatt

Reputation: 24218

You are describing a software or solution stack. Start here:

http://en.wikipedia.org/wiki/Solution_stack

If you need to be more specific in your documentation, then select each method in your solution and then "View Call Hierarchy". This will show which calls are made from each method and you can document that. You can also make use of VS's "Object Browser".

Upvotes: 2

Related Questions