This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Modeling a real-world application Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Modeling a real-world application" Watch "Modeling a real-world application" New topic
Author

Modeling a real-world application

Edmund Yong
Ranch Hand

Joined: Nov 16, 2003
Posts: 164
In modeling an application, how much is really needed? In my current project, we only have class diagrams, and they only contain entity classes. There are no classes representing the views like JSPs, or classes that represents the business logic. Should we have other things like sequence diagrams as well?


SCJP 1.2, SCWCD 1.4
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
What is the purpose of your models? Whom are they supposed to communicate to?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Edmund Yong
Ranch Hand

Joined: Nov 16, 2003
Posts: 164
To the developers and to the client as well.
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
To the developers and to the client as well

This might be one of the sources of your confusion. In most cases developers and clients have very different needs.

When I produce model diagrams for clients they are mostly sequence diagrams to show the interaction between actions and entities. The implementation hierarchy embodies in a class diagram is neither interesting or useful to them.

For a new developer to the project, on the other hand, a class diagram showing the relationship between classes and interfaces is a much more useful and expressive document.

Can you find out any more about what would be most useful to your clients and developers? Can you ask them which things seem confusing or poorly explained?


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Frank Carver:
For a new developer to the project, on the other hand, a class diagram showing the relationship between classes and interfaces is a much more useful and expressive document.


That matches my experience. Object and/or collaboration diagrams are often also helpful.

Can you find out any more about what would be most useful to your clients and developers? Can you ask them which things seem confusing or poorly explained?


I want to strengthen this point: the best way to find out whether the artifacts are appropriate for their audience is to ask the audience.
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by Frank Carver:
When I produce model diagrams for clients they are mostly sequence diagrams to show the interaction between actions and entities.


And I presume these would deal mainly with the business model which would suppress obfuscating details like JSPs.

Originally posted by Frank Carver:
For a new developer to the project, on the other hand, a class diagram showing the relationship between classes and interfaces is a much more useful and expressive document.


And even there you have to be careful not to get too detailed. The static class diagram should highlight the dependencies and relationships, acting as an overall map so that it is clear which class is responsible for what. Sometimes it is necessary to break the diagram into multiple logical sub views because one massive diagram can be so overwhelming that it is useless. Collaboration and sequence diagrams can help to explain some �interesting� interactions on a large scale. However for detailed information clear and concise code is far more valuable to a developer.


If you can model your objects and scenarios in your head while engaged in writing code, and if those models are consistent with object thinking great! No need to write them down. If you and your colleagues use a visual model on a white board as an aid in talking about scenarios and in clarifying your collective thinking about those scenarios, and you erase the board when you're done meeting, also great!*** If your models are crudely drawn and use only a subset of the syntax defined here (or a completely different syntax that you and your colleagues collectively agree upon), still great. Model when you must, what you must, and only what you must.

*** You can always take a picture with a digital camera first if you are feeling apprehensive about losing your work.

Use whichever syntax (graphical or textual) you prefer, Remember, object philosophy questions the utility of any representation or model beyond its immediate assistance to those involved in making the model. Don't get caught up in trying to make your model "complete", "accurate", or "true".

David West, Object Thinking

And West is only reiterating what Robert C. Martin (of Agile Software Development, Principles, Patterns, and Practices) and his contemporaries have been saying all along: Model only when necessary but no more than necessary. Furthermore it is necessary to know when to let go of your artifacts. See also Model with a Purpose
and Travel Light.

Pages and pages of UML diagrams that might as well have been produced by a reverse-engineering tool are useless. Useful UML diagrams show what�s relevant and suppress what isn't - so blind modeling is a pointless and wasteful effort (unless you want to practice your diagramming/modeling skills and are willing to discard the result).

Is Design Dead?
Code As Documentation
Code as Design aka "the Code is the Design"
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Modeling a real-world application