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 ER Diagram and Class Design 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 "ER Diagram and Class Design" Watch "ER Diagram and Class Design" New topic
Author

ER Diagram and Class Design

Bull Et
Greenhorn

Joined: Nov 18, 2002
Posts: 1
The conceptual model developed in the Analysis phase requires that you identify concepts in the problem domain and record them in a relationship with other concepts. This seems to be very similar to the ERD modelling approach, and thus suggests to me that there is some overlap because the ERD and Conceptual model seem to produce the same results.
My layman's approach to ood is such that I would want to take my proposed data structure (ER diagram) and for each table in that structure, design a class responsible for dealing with that table. Is this too simplistic an approach? Will I be missing the boat further downline?
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
before I answer, may I respectfully suggest that you use either your real name, or at least a more realistic one.
Now, what you may be missing be equating Entity-Relationship modelling with Object-Oriented modelling is that in ER models there is not really any concept of behaviour. In OO modelling, the behaviour of the objects is the most important thing to model. You should ask yourself questions like "what services does this concept provide to others?" rather than "what data does this concept hold?"
Consider a simple "user" record in a database, it might have a userid, full name, password and email address.
The ER approach would lead to a class which just has all those fields and makes them accessible to other objects, either as public members or using "getter" and/or "setter" methods.
But think about it for a moment. Realistically what is another piece of code ever going to do with a password except compare it with something the user has entered? A more sensible OO approach might be to provide a method such as boolean checkPassword(String input) instead of String getPassword()
Now that sensitive password never needs to be passed to other objects. Once you think in terns of this interface, the "user" object doesn't actually need to hold the password at all - it can compare the input string directly to the result of a database query, or validate the password in any other way you fancy (for example trying to open a remote connection using it).
I hope you can see what I'm getting at. OO modelling is all about behaviour and services, not just about data.


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

Joined: Jul 11, 2001
Posts: 14112
So, ER modeling most probably even shouldn't be part of your analysis at all. In the analysis you should concentrate on the desired behaviour of the system - how the accompanied data gets stored most probably should be thought of as an implementation detail.
Even when designing the system, you should start by thinking about the interactions between your objects. Only when you start to think about persistence (which shouldn't be to early), ER diagrams could come into consideration (if you really need a database at all).
Also notice that there doesn't need to be a one-to-one relationship between classes and database tables. Your persistence layer should (evolve to) be flexible enough to effectively decouple the database design from the class design.


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
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Some articles on OR-mapping:
http://c2.com/cgi/wiki?ObjectRelationalMapping
http://www.ambysoft.com/mappingObjects.html
http://www.ambysoft.com/persistenceLayer.html
Ryan Greenwood
Greenhorn

Joined: Sep 16, 2002
Posts: 6
Thanks for the links Ilja. Frank, thanks for the advice, I am Bull Et but logging on from another machine, I couldn't remember my password (and couldn't re-find it) so I simply re-registered. Just a note though. The comment on ERD and conceptual models were never meant to be associated as part of the ooad process in tandem. This was merely an observation that when one identifies concepts in the problem domain and comes up with say, Invoice, InvoiceLine etc. the process of concept identification produces very similar results. I guess the question should be as follows: At which point does one say 'This concept does not warrant a class eg. User as per Franks example, and should it simply be part of a procedural process' ?
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
Thanks for using a more realistic name
One of the points I was trying to address in my first reply is that when designing for an OO system, you have probably "got the wrong end of the stick" if you start with thinking about data or ER models.
If you start by thinking about behaviour, then chosing which concepts to deal with as objects can become a much simpler decision. If a concept has no behaviour or responsibilities, it's probably not a very suitable candidate to be an object.
As an aside, have you considered Test Driven Design (TDD)? I've found that it can really help cut through this sort of "design fog" and lead to really elegant and effective designs which you might never have thought of when trying to do design in the absence of code.
In Test Driven Design, you design your system in lots of tiny little steps, with every step you experiment a little, learn more about the system and the requirements, and base each design decision on what you have learned so far.
Choose a tiny piece of desired functionality and write an "executable test case" for it. I write my tests for my Java software in Java using JUnit, for example. The key is that all your tests can be quickly and simply run by the machine. You are going to need to run your tests hundreds or even thousands of times before your design is complete, so the simpler and quicker they are, the better.
Writing your test code is the first step in designing your solution - it makes you think in real, practical, terms about how other objects and processes will invoke your new functionality. If you've ever met software with cumbersome. overcomplicated APIs, you'll appreciate this step!
Then, before you have written any "real" code, run all the tests you have written so far. Everything should pass except the test you have just written. This is the second part of the design process. It's an experiment to discover whether any code actually needs to be written. If your new test passes, you dont need to write any new code for this feature, it already works! I've seen far too may bloated designs full of un-needed code, which could have been greatly simplified by making use of someting as easy as this.
If this initial "reality check" fails, it's time to design another experiment. If you've been good, and chosen a really tiny bit of new functionality, you should be able to quickly come up with a simple implementation. It's probably not the best implementation, but that's not important at the moment. This is more of a "prototype" to see if you understand the requirement enough to implement any solution at all. Tweak this until all your tests pass.
So, all your tests pass. Now, the real design work for your new feature can begin. You've done your experiments and discovered that (a) you can make a workable API for the new functionality, (b) some code actually needs to be written and (c) you understand the problem enough to make a "prototype" which works.
Study your "prototype" code in the context of the rest of the system. Refactor and improve it (in tiny steps, remember), making sure to rerun your whole test suite after every little change. Don't be afraid to change other parts of the system as you go, if you see a chance to simplify something. You have already written a complete "regression" test suite for all the features you have implemented so far. Your tests will tell you straight away if you break anything.
When you can't think of anything else which can be improved, your design for this small step of functionality is complete. As a bonus, so is the coding and testing!
Make sure your code is checked in to some sort of source-code repository, and move on to consider the next tiny piece of functionality.
Skilled practitioners of TDD can run through this whole cycle many times a day, and achieve astonishing productivity of robust, well-designed, fully-tested code. It's an incredible feeling when you begin to realise that the code you are designing is going somewhere better, simpler, and more elegant than you originally thought of.
The "trick" of all this is to consider program design like science, and base your designs on observation and experiment rather than just pulling guesses out of thin air. This post turned out longer than I expected. I hope it helped!
Tom Hughes
Ranch Hand

Joined: Feb 09, 2002
Posts: 86
It helped me !!
thanks,
T.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
There is a nice example of how you can use the code to drive its design (and how the result may differ from an "up front design") at the ObjectMentor Website: http://www.objectmentor.com/resources/articles/xpepisode.htm
I am currently reading the book this article is from ("Agile Software Development: Principles, Patterns and Practices"), which is full of design principles accompanied by extensive case studies. Might be worth a look...
Ryan Greenwood
Greenhorn

Joined: Sep 16, 2002
Posts: 6
Frank I hear what you say and I like the concept. Can you give me some idea of a time scale related to size of project when using TTD based on your experiences?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Hi Ryan,
I don't think the timescale of TDD is connected to the project size at all. The test-implement-refactor cycle typically shouldn't take longer than a couple of minutes (if it does, either your test was to big, or you didn't refactor enough earlier). Of course, it needs some practice to go in such tiny increments...
Did that answer your question?
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
In my experience, the only major factor which varies with the size of the project is the effort needed to slice off small enough pieces of work to get started.
It all really depends on how much of the problem is understood, and whether enough is known to choose a small bit of real value to start with. Once the process is rolling, it can be done in parallel with more tradional approaches to analysis. Each new user story or other item of problem domain knowledge can be queued up to be added as a new test case.
Unfortunately, with most of the large projects I've worked on, designers/developers have not been allowed near it until a large amount of somewhat speculative analysis work has already been done. This can be a real problem, and lead to delays in design and implementation.
 
 
subject: ER Diagram and Class Design