CODEWITHSUNDEEP
uml
Delmonte
Delmonte

Reputation: 411

Need advice on how to document programs

I know basic stuff about UML: - Use Case - Activity Diagram - Class Diagram - Sequence diagram

All of them seem great to me. I can have a general "vision" or "understanding" of a system or application. But just "general".

Think about this example: a programmer has to deal with an application for the first time. All UML documents that I mentioned will help him to have a general understanding of the system. But one day his boss says to him: "There is a problem with the "payroll process", check it."

The programmer will have to talk with the user and try to understand in which form the user has found the problem. It was Form_Payr.1.2.aspx, when clickling button "Ok". Then programmer will return to his seat and have to review what is going on in Form_Payr.1.2.aspx, what classes and methods are invoked from its vb code, if process is executed in the Business Layer or in stored procedures at database, and finally get what is the problem. The programmer does all of these tasks only with IDE and debugging.

My question are: - Is there any UML document or diagram that will map what programs (vb or aspx) call what clasess or methods, and what processes they run, so it would be easier or faster to do maintenance.

Upvotes: 1

Views: 169

Answers (2)

sfinnie
sfinnie

Reputation: 9952

  • Is there any UML document or diagram that will map what programs (vb or aspx) call what clasess or methods, and what processes they run, so it would be easier or faster to do maintenance.

Yes - you've already mentioned the most relevant diagrams (Sequence / Activity). The problem isn't the diagram, it's ensuring the diagram is consistent with the code.

  • Is there any best practice about how [to] document this kind of maps?

At the level of detail you're referring to it's effectively impossible to manually create diagrams that reflect the code. It's just too much effort to maintain both. You basically have two choices:

  1. Create manual diagrams at a higher level of abstraction. These can give a flavour of how the system works but won't help with the detail. You'll still need a process for actively maintaining them or they will become stale and worthless. Because of the overhead (time & discipline) manual diagrams tend to work well for documenting fundamental patterns in your solution; e.g. key architectural mechanisms or domain concepts. These tend not to change so often and provide a valuable overview of the system.
  2. Ensure the code and diagrams are automatically kept in sync. Practically this means generating one from the other. Both are possible.

There are basically two approaches to option (2). Model-Driven Development generally advocates generating code from models. It can (and does) work but it's a paradigm you have to buy in to. If you're more comfortable writing code then there are tools that will generate diagrams from the code, e.g. Enterprise Architect. I believe Visual Studio also supports this although haven't used it.

hth.

Upvotes: 1

Marcel Offermans
Marcel Offermans

Reputation: 3323

I am not sure that any amount of UML diagrams will really help a developer track down a bug. That's what debuggers and IDEs are for. The diagrams and maps you mention would obviously document what should happen, while the problem might be that something else happens. That could be at any point in time. It could even be hard to reproduce because it's a race condition somewhere. My advice, invest in a good IDE, debugger and profiler and encourage your developers to master them.

Upvotes: 1

Related Questions