Pet Store in UML

[John Arau]

I've few doubts regarding the class diagrams for J2EE apps.I read a few books and I'm still confused.
This is the diagram I made for petstore demo. (it's temporally in this location) http://reflex.dyndns.info/java/index.html
If someone kindly make some comments about it. (besides the fact that it's cluttered ) and answer me a few questions.
1)Is it ok to write methods and attributes without arguments and types?
2)Some say they made their class diagrams technology independent, I may assume they had to make technology dependent comments, yes?
3)For those who know well the Petstore app, would you make that diagram in a different way ?
4)Just say whatever I'm doing wrong.

Does anyone have the diagrams or code for the PSA (Professional Services Automation) mentioned in Alur's book?

Thanks a lot in advance.
[ May 16, 2005: Message edited by: John Arau ]

[Daniel Amadei]

Petstore is too much complicated! Try to achitect this app as you would architect any other app.

Petstore uses the state-of-art in architecture which can compilcate too much the design.

[John Arau]

Hi Daniel,

I am designing my app in simpler way, nevertheless thank's for your advice.

John

[Joseph Zhou]

Hi John,

Thanks a lot for your great efforts. I looked up the the catelog model a little more and confused(By the PetStore, not your UML). In your UML also the code at /src/components/catalog/src/com/sun/j2ee/blueprints/catalog/model, we know Category 1---1 Item 1---1 Product, and no direct relationship between Category and Product. When I checked the DB schema, I found that was not the case(/src/sql/oracle/oracle.petstoredb.sql):
CREATE TABLE CATEGORY (CATID VARCHAR2(10) NOT NULL);
CREATE TABLE PRODUCT (PRODUCTID VARCHAR2(10) NOT NULL ,CATID VARCHAR2(10) NOT NULL );
CREATE TABLE ITEM (ITEMID VARCHAR2(10) NOT NULL, PRODUCTID VARCHAR2(10) NOT NULL );

How do you understand the inconsistency? Thanks.

[Joseph Zhou]

Does PointbaseCatalogDAO not used by anybody?

[Joseph Zhou]

CatalogHelper uses either CatalogDAO or CatalogEJB to do it's job, but when I look at CatalogEJB, it uses CataLogDAO too. Why we need the ways?

[John Arau]

Hi Joseph.

IMHO,for a very simple reason, because they're only used as Transfer Objects (p. 415,Core J2EE Patterns) for a client that doesn't need their relationships.
Did you notice they're all read-only.That's typical of a transfer object.
In petstore you have CartItem, LineItem and Item, they all look similar but play different roles.
E.g CartItem has a relationship with product and category.

[Joseph Zhou]

Hi John,

Yes, They are TO, but for my personal opinion, if they carry partial info of the entities they represented is OK, but no to change it. from the DB script, you see they do change it(relationship).

[John Arau]

Hi Joseph.

This is what I think, Product, Item and Catalog where created with only one purpose in mind: to carry data to the client tier. This client doesn't use those relations, because the browse catalog operations don't show any products in categories to the user. There's no point in having them there.
Second, since that's a read operation, it's good to forbit the client from changing it, because its not dealing with the true entity. Some TOs (not in petstore) may allow changes.(see Dirty Marker Strategy pag. 397 ).
What about that tables in DB script? I think that only PointbaseCatalogDAO uses them and it's for reading.
[ May 16, 2005: Message edited by: John Arau ]

[John Arau]

Originally posted by Joseph Zhou:
CatalogHelper uses either CatalogDAO or CatalogEJB to do it's job, but when I look at CatalogEJB, it uses CataLogDAO too. Why we need the ways?

Yes it's confusing, what they've done in petstore it's more than the Fast Lane. http://java.sun.com/blueprints/patterns/FastLaneReader.html
They provided two lanes:
One reads via the EJB, so you could deploy that EJB on diferent machines, and all that good stuff (security,TX etc).
The other is in fact the fast lane, it goes directly to the DAO, the fastest way of course.

I've updated the class diagram.
[ May 16, 2005: Message edited by: John Arau ]

[Joseph Zhou]

Hi John,

Thanks a lot for your quick reply.

The reason I raised the question "Does PointbaseCatalogDAO not used by anybody?" was, I searched the whole folder tree, but found nobody use it. I also checked details of GenericCatalogDAO, I found it did the same job, the only difference was it used a complex way and put SQL statements in XML. So, it looks like a duplicated implementation.

I agreed with you, SLSB+DAO is also a fast lane(compared with entity bean). But when you look at the "import com.sun.j2ee.blueprints.servicelocator.ejb.ServiceLocator;" from CatalogHelper.java, it is not supposed to be remote.(currently, the two ServiceLocator in PetStore both can only be local -- new InitialContext(), but the web ServiceLocator potentially could be remote).

Based on DB schema(also the PetStore Design doc -- UI pages), the relationship is Category 1---1..* Product 1---1..* Item, but we see it in TO is: Category 1..*---1 Item 1---1..* Product(my previous description for this relationship is not correct). I can't find a reason to make such a change. Also, we are lucky don't need to maintain the catalog(pre-populated by SQL statements and no change at all), otherwise we can not even create a new product in PetStore using the TO.

Just my 2 cents.









)

[Joseph Zhou]

Sorry, Category 1<--1 Item 1-->1 Product should be correct in TO.

[Joseph Zhou]

Sorry, Category 1<--1 Item 1-->1 Product should be correct in TO.

[Joseph Zhou]

Hi John,

Some ideas about CustomerEJB and associated entity beans:
1.Associations are bidirectional(only from check DB schema).
2.AddressEJB may need add to with ContactInfoEJB.
3."Uses TOs" may not needed.

For the /src/sql/oracle/oracle.petstoredb.sql, I have more concerns:
line 16:
CREATE TABLE AddressEJBTable
(PMPrimaryKey NUMBER(22) NOT NULL ,
city VARCHAR2(255),
country VARCHAR2(255),
state VARCHAR2(255),
streetName1 VARCHAR2(255),
streetName2 VARCHAR2(255),
zipCode VARCHAR2(255),
reverse_address___PMPrimar NUMBER(22));
--reverse_address___PMPrimar should be reverse_contact___PMPrimar

line 38:
CREATE TABLE ContactInfoEJBTable(
PMPrimaryKey NUMBER(22) NOT NULL,
address___PMPrimaryKey NUMBER(22),
email VARCHAR2(255),
familyName VARCHAR2(255),
givenName VARCHAR2(255),
telephone VARCHAR2(255),
reverse_contactInfo___PMPr NUMBER(22)
);
--reverse_contactInfo___PMPr should be reverse_account___PMPr

line 52:
CREATE TABLE CreditCardEJBTable (PMPrimaryKey NUMBER(22)NOT NULL,
cardNumber VARCHAR2(255),
cardType VARCHAR2(255),
expiryDate VARCHAR2(255),
reverse_creditCard___PMPri NUMBER(22));
--reverse_creditCard___PMPri should be reverse_account___PMPri

I verified it with the data inserted afterward, the column naming has no harm for execution, but do misleading, what do you think?

[Anonymous]

Hi John,

I checked there is no userId in ShoppingControllerEJB, also I think the sessionContext may not required. In an alternative way, we'd better to give SFSB stereo type to all three: ShoppingControllerEJB, ShoppingClientfacadeLocalEJB, and ShoppingcartLocalEJB.