• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Modeling a real-world application

 
Ranch Hand
Posts: 229
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is the purpose of your models? Whom are they supposed to communicate to?
 
Edmund Yong
Ranch Hand
Posts: 229
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To the developers and to the client as well.
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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"
 
reply
    Bookmark Topic Watch Topic
  • New Topic