.net – What UML diagrams do you create for ASP.NET applications?

asp.netnetuml

I work in a mid size company as a Senior dev and work on developing projects that are fairly large size (> 1 year at a minimum). Most of the architects here feel that creating UML diagrams does not justify the time involved (although we always have a ERD and some informal flowchart kinda diagram for all projects)

I am looking to create UML diagrams atleast for the projects that I work on. Based on my quick research, it appears that there are the following:

  1. For Creating a Logical model – Object Role Model (ORM
  2. For Creating a physical model – Component, Class, Sequence, Activity
  3. For the database model – ERD

Questions:

  1. What UML diagrams do you create in your company?
  2. Does MS Visio have the capability to create all of the diagrams above?
  3. Are UML diagrams chosen based on the type of the application being
    developed?

Best Answer

#1 What UML diagrams do you create in your company?

We use the entire set of diagrams defined by UML. We make particularly heavy use of use case diagrams, class diagrams, sequence diagrams, and state machine diagrams.

#2 Does MS Visio have the capability to create all of the diagrams above?

It does, but we generally do not use Visio for this as there are many tools out there far more suited to the job. Personally, I favor tools that allow me to create diagrams very quickly, without much muss and fuss. Tools that enforce slavish adherence to the UML spec (or, even worse, a tool vendor's interpretation of the spec) annoy me. One of the tools I have found particularly useful is Pacestar's UML Diagrammer.

#3 Are UML diagrams chosen based on the type of the application being developed?

UML can be used to describe aspects of any application. The nature of the application, though, will impact the type and number of diagrams that you choose to employ.

Most of the architects here feel that creating UML diagrams does not justify the time involved

UML diagrams need not take much time to create. The key is to avoid diminishing returns by developing models that are 'just good enough' to satisfy your needs. As I intimated above, I focus my modeling efforts on capturing salient aspects of the system rather than on strict adherence to the UML spec. Further, I do not hesitate to use non-UML diagrams (or simply text) to model aspects of the system if by doing so I can better communicate the system aspects of interest.