which layer in a web app do i fit in uml class diagram only model or model + controller both

[Ayan mallick]

I am new to UML. Now in a web project i want to apply UML class diagram then should i include controller layer also in the UML class diagram or only model layer classes should be there . I am using spring web MVC framework, even if i include controller layer also in the uml class diagram then how to represent spring library specific classes(i. e the hierarchy of spring specific controller classes).

one more thing is when i will draw UML class diagram it will be only one for whole model layer or for every requirement or use case i draw one because if i draw single UML class diagram it's becoming messy as i have too many classes in model layer.

also how many diagram should be fine. Initially i find 1. use case diagram 2. activity / sequence diagram 3. UML class diagram this three are good to go.

please advice.

[Roberto Perillo]

Howdy, Ayan!

Well, the value of UML diagrams is that they communicate design choices, or even situations. This means that you should create only the diagrams necessary to communicate things to other people. If you're going to create a sequence diagram, but you are not going to discuss it with nobody, then it isn't necessary.

You can create as many class diagrams as necessary, each diagram with a group of classes that make sense to take part on the same diagram. All layers of your application can have one or more class diagrams.

To represent classes of other libraries or frameworks, what I usually do is, I add a stereotype, identifying the library that owns a class. For example, if I wanted to represent the ApplicationContext interface, I would add an interface named ApplicationContext with the stereotype <<org.springframework>>.

One thing that I do all the time at work is create class diagrams on a whiteboard with some classes (sometimes 5 classes, sometimes with 20 classes, it depends) and discuss what will be done with the other members of my team. Thus, we use it as a tool to discuss design.

[Junilu Lacar]

Roberto Perillo wrote:One thing that I do all the time at work is create class diagrams on a whiteboard with some classes (sometimes 5 classes, sometimes with 20 classes, it depends) and discuss what will be done with the other members of my team. Thus, we use it as a tool to discuss design.

Exactly along the lines I was thinking. There's a new book in the works at O'Reilly, "User Story Mapping" by Jeff Patton and it has made my list of "must read" books despite it still being in the rough cuts phase. There's a section in the book where Jeff explains that user stories got their name from how they are used, not what should be written. That is, user stories are useful because they remind us of conversations that we had or should have. Jeff explains this further with an example. He shows a picture of his kids at a beach. If you and I were to look at it, that's all we see. But when Jeff looks at it, he remembers his trip to Hawaii, the hour-long drive out to a remote area, the long trek through lava fields and his kids complaining about the walk, the wonderful day they spent at the beach, and the sea turtles that came up on the beach to bask in the sun.

Along the same lines and to Robert's point, a UML diagram is only a tool that you and your team can use to have conversations about the system's design, and to document the important parts of those conversations so you don't forget them. If you were part of the discussion, you'll remember those details when you look at the diagram again sometime in the future. Anyone else who did not participate in the discussions will not be able to fill in those details, unless they're psychic or something.