Question

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.

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

Answer 1

• 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.