RE: FN-FORUM: normalisation for classes???

date posted 26th November 2007 00:00

Ben Johnson (Neogic) F wrote:
> Stepping back slightly, is the purpose here to create UML =
documentation
for
> a client after-the-fact, or to aid the design process? If it's the =
former,
> then use an automated diagramming tool. If it's the latter, then =
you're
> using UML back-to-front: database tables / code classes are the end
product,
> not the starting point!=20
=20
James wrote:
> The aim of the class diagram is to try and help me establish what I =
need=20
> to code before i start coding, so yes I'm using it as a design tool, =
is=20
> this not right?

Nope - the database structure is just as much an implementation decision =
as
your code classes. You should 'model' the problem area first, identify =
real
world tangible objects/concepts (e.g., Customer, Account, Transaction) =
and
have a class for each. Here's some reading on why there usually isn't a
direct mapping between database structure and your Class Diagram:

Why Data Models Shouldn't Drive Object Models (And V.V.)
http://www.agiledata.org/essays/drivingForces.html

The following page is a good guide to techniques for identifying what is =
a
class, what is a relationship and what are properties. It's written from =
the
perspective of Entity Relationship Modelling (ER Diagrams), so the names =
are
slightly different (entity =3D class, association =3D relationship, =
attribute =3D
property), but the recommendations are still good (ignore the very last
section though, "Recording Information in Design Document"):

Identifying Data Objects and Relationships=20
=20
http://www.utexas.edu/its-archive/windows/database/datamodeling/dm/object=
s.h
tml

As you move closer to implementation, you also add more =
solution-specific UI
objects, such as CustomerAccountScreen (this is perhaps the main =
difference
between ER Diagrams and Class Diagrams). In a web application, a UI =
object
would typically be implemented as a page, which receives input from the
browser, sends messages to other object and outputs mark-up.

Including 'end-point' objects like this helps you to trace how the =
objects
will collaborate to satisfy each Use Case (user task). You can use a UML
Sequence Diagram to do this. Don't forget that Agile Modelling =
principles
state that you can adapt the level of detail in your UML diagrams to =
suit
your needs, so feel free to use very simple Sequence Diagrams - they are
usually a means to an end, unless the client requires them in standard
format.

Once you are confident you have all the objects you need, the document =
will
help mapping classes, properties and relationships to elements in the
database (tables, etc):

Mapping Objects to Relational Databases: O/R Mapping In Detail
http://www.agiledata.org/essays/mappingObjects.html

It's a bit of a read, but I found it very useful for concrete strategies =
for
mapping an object model to a database structure. Note that there are =
other
ways that data may be stored (e.g., Session variables, XML files, =
cookies,
etc), which is one of the many reasons classes won't map directly to
database tables.


Hope that helps, let me know any other questions. Note I'm no expert on =
UML
modelling (ER Diagrams, Data Flow Diagrams, et al were still dominant =
when I
studied at Uni '98-02!), so comments from the group are welcome.

Cheers, Ben

--
Ben Johnson, Neogic Web Solutions
// design . development . managed hosting

w | http://www.neogic.com
t | +44 (0)1242 808 262
e | [EMAIL REMOVED]