Re: Model Driven Architecture

On Sun, 12 Jun 2005 12:02:43 +0200
Per Nyfelt <[email protected]> wrote:

> Hi,
> 
> Here's some feedback:
> 
> 1. It would be easier to follow your thoughts if you provided a Junit
> test or  two instead of "just a bunch of classes".

I guess I could, but the whole idea with my project is to translate the
sematics of a class diagram to classes. So the "bunch of classes" are a
representation of the class diagram and not the other way around.

Rather than describing with code (unit tests) I'll describe the class
diagram for you:

> [ /Human/
>     name:String
>     birth:Date
>     death:Date
>     abstract +getChildren():Set
> ]<|--+----[Man]-- {1} +father +child {0..*} --[Human]
>      +--[Woman]-- {1} +mother +child {0..*} --[Human]

There are Humans. 
They must be Men of Women.
All have a father (Man) and a mother (Woman).
They may have children.

> [Company]- {0..*} +employer | +employee {0..*} -[Human]
>                             |
>                             \--[Employment
>                                   +salary:float
>                                ]-- +depositBankAccount ->[BankAccount]

Companies can have multiple employees.
Humans can have multiple employers.
The employer deposits the salary in a BankAccount.

> [Company]<|--[Bank](accountNumber:String)<#>--- {0..1} -[BankAccount]

The Bank is a Company.
Each Bank have a number of BankAccounts.
BankAccounts are uniqe by their account number.
A BankAccount can't exist without the Bank.


> [BankAccount
>     +accountNumber:String
>     +balance:float
> ]- {0..*} ---[Human]

A BankAccount is owned by a Human,
who can own multiple BankAccounts.

> 2. It does not compile :( (wrong return type in
> BankImpl.getBankAccounts(),  BankAccoutnImpl.ocd is not valid XML
> etc.)

I'm sure it doesn't compile. It's all dry-coded. I want to know if it
looks about right, if I got the genereal idea on how to code Ozone
aware applications.

Did I get the general idea on how to map persistency in the OCD?

> 3. You use "this" a lot. Use of this might get you into problems.
> Consider  self() as an alternative. self() will give you a proxy
> reference back rather  than the "raw" object. 

When might that become a problem?

> 4. If you Maps and Sets contains Ozone Objects it is not too bad but
> are  scalable only up to a certain point (when the number of proxies
> that are  stored in the Set becomes so many that memory is filled up).
> In that case you  need a lazy loading collection. Look at the
> Collections module for this.  Basically it goes like this:

There are no collections in my jar-file, except for the DxXX, and if I
got it all right they are for interal use only? So.. yhe collection
module in CVS? Or what?

> * Normal Objects in java.util collections -> OK for very few,
> serializable and  small objects
> 
> * Ozone Objects in java.util collections -> OK for collections with a
> couple  of hundred or perhaps a couple of thousand items
> 
> * Normal Objects in org.ozoneDB collections -> OK for many,
> serializable and  small objects
> 
> * Ozone Objects in org.ozoneDB collections -> OK for large collections
> with   hundreds of thousands of items
> 
> 5. Human does not extend OzoneRemote but HumanImpl extends
> OzoneObject. Same  thing with Employment, Company and BankAccount. 

So all root interfaces should extend OzoneRemote,
and all root classes should extend OzoneObject?

Thanks

-- 

  karl

> Best regards,
> Per
> 
> Saturday 11 June 2005 13.49 skrev Karl Wettin:
> > Hello list,
> >
> > it's been a year and half since my last try, so I thought it was
> > about time to give it another try: I want to add Ozone support to my
> > MDA-tool Silvertejp. It creates java code based on UML class
> > diagrams. It already support various POJO variants, Hibernate (ORM)
> > and Compass (OSEM).
> >
> > I've made an example diagram that use most of the supported
> > elements,
> >
> > > #load upl/java.upl
> > > #default class stereotype <<bound ozone>>
> > > #default package se.snigel.ozone
> > >
> > > [ /Human/
> > >     name:String
> > >     birth:Date
> > >     death:Date
> > >     abstract +getChildren():Set
> > > ]<|--+----[Man]-- {1} +father +child {0..*} --[Human]
> > >      +--[Woman]-- {1} +mother +child {0..*} --[Human]
> > >
> > > [Company]<|--[Bank](accountNumber:String)<#>--- {0..1}
> > > -[BankAccount]
> > >
> > >
> > > [BankAccount
> > >     +accountNumber:String
> > >     +balance:float
> > > ]- {0..*} ---[Human]
> > >
> > >
> > > [Company]- {0..*} +employer | +employee {0..*} -[Human]
> > >
> > >                             \--[Employment
> > >                                   +salary:float
> > >                                ]-- +depositBankAccount
> > >                                ->[BankAccount]
> >
> > and manually wrote the code that would be created by above diagram:
> >
> > <http://wiki.snigel.net/se_2esnigel_2esilvertejp?action=AttachFile&
> > do=g et&target=human_ozone.tar.gz>
> >
> >
> > It would be great if someone could take a look at that code and tell
> > me if I do something strange. I know for sure that my non
> > Ozone-aware Set:s and Map:s are bad. There is no setter, just
> > getter. What superclass should I extend rather than java.util?
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
> shotput a projector? How fast can you ride your desk chair down the
> office luge track? If you want to score the big prize, get to know the
> little guy.   Play to win an NEC 61" plasma display:
> http://www.necitguy.com/?r=20
> _______________________________________________
> Ozone-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ozone-users
> 


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20