aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Do you model Physical Things or Processes? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Do you model Physical Things or Processes?" Watch "Do you model Physical Things or Processes?" New topic
Author

Do you model Physical Things or Processes?

Tom Tees
Greenhorn

Joined: Oct 22, 2010
Posts: 8
Hi all. My wife and I are trying to building an online business selling things, and I am in charge of building the e-commerce site.

I am fairly new to Object-Oriented Programming and the more I study the more confused I get?!

There seem to be a million ways to approach things, and I really haven't found any good guides. (Most books and tutorials focus on dry examples and at a very granular level. I have yet to find a source that discuss things from an Architect's perspective?!)

Anyhow...

When you are building a system from scratch, do you tend to model Physical Things or instead Business Processes?

For example, here are two different approaches to modeling our e-commerce site...

Physical-oriented approach:
- User
- Address Book (collection of Addresses)
- Address
- Wish List (collection of Products)
- Products
- Catalog (collection of Products)
- Shopping Cart (collection of Products)
- Order (consists of User, Addresses, Shopping Cart Products, OrderDetails, Payment)
- Payment
and so on...

Process-oriented approach:
- User
- RegistrationService
- AuthenticationService
- ShoppingService
- CheckoutService
- ReturnService
- UserProfileService
and so on...

A couple of people have said that the first approach is a bad idea because it just mimics the database. They say, "Model things like you do them in real-life and let the database worry about how it stores things."

Other people seem to feel that having a one-to-one mapping between Physical Things (often Database Tables) and Classes is just fine.

Who knows? Maybe you need both approaches?!

Obviously there are many ways to do things, but I bet there are a couple of "architectural designs" that work the best.

If you were building an e-comemrce site from scratch, what architectural design approach would you take when designing Classes?

Some expert help is definitely needed!

Sincerely,


TomTees

Mike Peters
Ranch Hand

Joined: Oct 10, 2009
Posts: 67

I think you want both.


Mike Peters
Tom Tees
Greenhorn

Joined: Oct 22, 2010
Posts: 8
Mike Peters wrote:I think you want both.


A man of few words.

Care to flesh that out a bit more and ive me some examples of good class choices?

What about some of the things I listed?

(I tend to favor the "processes" or "services" more, maybe because of my procedural programming background.)


TomTees
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
Object-oriented software systems consists of models of data and models of process /workflow / behavior. The concept of an "object" is a design concept layered over the core programming structures which are common in all computing languages. Object-oriented design skills are very complex and it typically will take 2 to 3 years to become a proficient OO designer.

Tom, maybe you can hire a consultant to help you with your business if there are pressing needs. Running a business and writing code for a website are different activities...you only have so much time in a day, so focusing on what matters most makes the most sense in my opinion.
Mike Peters
Ranch Hand

Joined: Oct 10, 2009
Posts: 67

In a pure object oriented sense you don't need things that are called services. I think you should design your model based on the application's context. It is hard to tell what classes are good in your situation because I don't know the exact context for your application.

You define the classes: User, Address Book (collection of Addresses), Address, Wish List (collection of Products), Products, Catalog (collection of Products), Shopping Cart (collection of Products), Order (consists of User, Addresses, Shopping Cart Products, OrderDetails, Payment), Payment.

These classes seems fine (except for the plural form in some cases) for a shopping application, so in my opinion I advice you to stick with that.

The point where services kick is in the technical implementation. For example if you decide to create a multi tier application you need to design how each tier communicates with another tier. Normally a client then uses services to communicate with an application server and an application server uses a persistence interface (e.g. JDBC) to communicate with the data server.

Be very careful though with services when you implement them. If you have a procedural background it is easy to implement a service with procedural code, which you should try not to do. Try to look at a service pure as a communication channel between two object oriented models which represent one model as a whole.

Maybe the Java Pet Store blueprint implementation is a good place to start for you.
Tom Tees
Greenhorn

Joined: Oct 22, 2010
Posts: 8
Jimmy Clark wrote:Object-oriented software systems consists of models of data and models of process /workflow / behavior. The concept of an "object" is a design concept layered over the core programming structures which are common in all computing languages. Object-oriented design skills are very complex and it typically will take 2 to 3 years to become a proficient OO designer.


I appreciate the complexity of OOP, but like most things, I'd like to take a layered approach. I don't need to become a guru overnight, but I would like to get to a point of where my code doesn't look like a train-wreck.


Tom, maybe you can hire a consultant to help you with your business if there are pressing needs. Running a business and writing code for a website are different activities...you only have so much time in a day, so focusing on what matters most makes the most sense in my opinion.


I am unemployed. If I had $$$ to hire a consultant I wouldn't be here! (Come to think of it, if I could get a job in my own country (USA) and make a decent living, I probably wouldn't be trying to break away from Corporate America and start my own business!!)

Hopefully I can get some good advice and guidance here...

Thanks,


TomTees

Tom Tees
Greenhorn

Joined: Oct 22, 2010
Posts: 8
Mike Peters wrote:In a pure object oriented sense you don't need things that are called services. I think you should design your model based on the application's context. It is hard to tell what classes are good in your situation because I don't know the exact context for your application.


Well, I am just trying to build your basic, plain-vanilla E-commerce site. (Read, not Amazon.com at this point!)

Not sure what information you need to help, but just let me know and I will try my best to provide it.

In grossly simple terms, this is what I want/need...

If John Q. Public visits our website, he should be able to...
- Browse Products
- Add Products to a Shopping Cart
- Register (required to Checkout)
- Log-In (required to Checkout)

- Start the Checkout Process...
- Enter Billing and Shipping Addresses
- Choose a Shipping Option
- Enter Payment Details
- Review & Place Order

If I can model that in a respectable OO way I would be titillated!!

Sure, there is a lot more I need to focus on, but *that* is the crux of an E-commerce site. (And if I can get that much designed and built using solid OOP, then the other things I'll need to do won't be much harder.) Also, things like a Catalog can be static HTML in the beginning since we may only have a few doxen things to sell.

I think I have a pretty solid understanding from a "Business Level/Layer" what needs to be done, but writing things out in respectable OOP is another story!

Anyways, I can answer any questions you have for me.


You the classes: User, Address Book (collection of Addresses), Address, Wish List (collection of Products), Products, Catalog (collection of Products), Shopping Cart (collection of Products), Order (consists of User, Addresses, Shopping Cart Products, OrderDetails, Payment), Payment.

These classes seems fine (except for the plural form in some cases) for a shopping application, so in my opinion I advice you to stick with that.


Okay, good.

BTW, can you explain more about the "plural form" thing?


The point where services kick is in the technical implementation. For example if you decide to create a multi tier application you need to design how each tier communicates with another tier. Normally a client then uses services to communicate with an application server and an application server uses a persistence interface (e.g. JDBC) to communicate with the data server.


Well, a few things here...

1.) I'd like help coming up with a platform-independent OOD because I likely won't be doing any fancy Java stuff the first go round.

2.) I used the term "Service" because I picked it up somewhere online and that leads into one of my big areas of uncertainty. See, for me, I see things like "UserRegistration", "Authentication", "Checkout", etc as logical classes. (Textbooks get all caught up on "nouns" and "physical things", but I've also seen things like "behaviors" (e.g. Quackable and Flyable for a Duck) and "processes" (e.g. "Book a Flight", "Make an Appointment", "Schedule a Court Date") that are modeled as classes.


Be very careful though with services when you implement them. If you have a procedural background it is easy to implement a service with procedural code, which you should try not to do. Try to look at a service pure as a communication channel between two object oriented models which represent one model as a whole.


Well, that is one big area that I need help - as you can see above.

For example, "Authentication"/"LogIn" seems like a logical class to me.

LogIn{
-email
-password

-authenticate()
}

Maybe you would pass in a "User" object into the "LogIn" object and it would authenticate the User based on his/her credentials and then change the status of "User" from "LoggedOut" to "LoggedIn".

That doesn't sound too procedural to me, now is it?


Maybe the Java Pet Store blueprint implementation is a good place to start for you.


Possibly, although I'm kind of burned out on reading examples. The reason I came here is to get some direct help on direct problems. (I've read lots of books, but I think I am ready to just jump into a my real-life problem and put away the theory if you follow?!)

Thanks,



TomTees
Mike Peters
Ranch Hand

Joined: Oct 10, 2009
Posts: 67

In grossly simple terms, this is what I want/need...

If John Q. Public visits our website, he should be able to...
- Browse Products
- Add Products to a Shopping Cart
- Register (required to Checkout)
- Log-In (required to Checkout)

- Start the Checkout Process...
- Enter Billing and Shipping Addresses
- Choose a Shipping Option
- Enter Payment Details
- Review & Place Order

If I can model that in a respectable OO way I would be titillated!!

Sure, there is a lot more I need to focus on, but *that* is the crux of an E-commerce site. (And if I can get that much designed and built using solid OOP, then the other things I'll need to do won't be much harder.) Also, things like a Catalog can be static HTML in the beginning since we may only have a few doxen things to sell.


Maybe for your first version you don't need user registration. That will make things a lot easier. You can use the user session to track the contents of the shopping cart and state of a process.

I would model your case something like this (simplified) and implement the views with servlets:


You the classes: User, Address Book (collection of Addresses), Address, Wish List (collection of Products), Products, Catalog (collection of Products), Shopping Cart (collection of Products), Order (consists of User, Addresses, Shopping Cart Products, OrderDetails, Payment), Payment.

These classes seems fine (except for the plural form in some cases) for a shopping application, so in my opinion I advice you to stick with that.


I mean use Address instead of Addresses, Product instead of Products, etc.


For example, "Authentication"/"LogIn" seems like a logical class to me.

LogIn{
-email
-password

-authenticate()
}

Maybe you would pass in a "User" object into the "LogIn" object and it would authenticate the User based on his/her credentials and then change the status of "User" from "LoggedOut" to "LoggedIn".

That doesn't sound too procedural to me, now is it?


That is not procedural indeed.
Tom Tees
Greenhorn

Joined: Oct 22, 2010
Posts: 8
Mike Peters wrote:Maybe for your first version you don't need user registration. That will make things a lot easier. You can use the user session to track the contents of the shopping cart and state of a process.


Good suggestion, but I would definitely like to have a "User" object and "User Registration". In fact, that is the first part I am trying to tackle because it is the basis for nearly any interactive website (e.g. E-commerce, User Group, Email, etc.)


What tool did you use to make that diagram?

What exactly are the "views"?

What are your thoughts on the Class/object examples I mentioned above?

Also, if I had a "User" object and formal "User Registration" how would that change your diagram?


For example, "Authentication"/"LogIn" seems like a logical class to me.

LogIn{
-email
-password

-authenticate()
}

Maybe you would pass in a "User" object into the "LogIn" object and it would authenticate the User based on his/her credentials and then change the status of "User" from "LoggedOut" to "LoggedIn".

That doesn't sound too procedural to me, now is it?


That is not procedural indeed.


So is my example and thought-process proper OOP for the Log-In Process??


TomTees

Mike Peters
Ranch Hand

Joined: Oct 10, 2009
Posts: 67

Good suggestion, but I would definitely like to have a "User" object and "User Registration". In fact, that is the first part I am trying to tackle because it is the basis for nearly any interactive website (e.g. E-commerce, User Group, Email, etc.)


It is pretty advanced to create a secure web site, but assuming you have SSL for a connection you may use a user-id and password as a token. But you will still need the session information to track a specific session. Encrypt or hash the user-id and password to prevent abuse on the client side.

For registration I suggest you create a registration view and for logging in a authentication view. The registration view takes user information and stores it into a data store. The authentication view identifies the specified user-id and password and returns a token representing the user. The token is used in every other view from then on (store it in the session information).

What tool did you use to make that diagram?


I used argouml.

What exactly are the "views"?


A view is an HTML page, JSP page or servlet (depends on the platform you're working on).

What are your thoughts on the Class/object examples I mentioned above?


you don't need to give the user a state. Use it as a token and store it in the session information. If a token is there, then the user is authenticated. that's enough state.

Also, if I had a "User" object and formal "User Registration" how would that change your diagram?




For example, "Authentication"/"LogIn" seems like a logical class to me.

LogIn{
-email
-password

-authenticate()
}

Maybe you would pass in a "User" object into the "LogIn" object and it would authenticate the User based on his/her credentials and then change the status of "User" from "LoggedOut" to "LoggedIn".

That doesn't sound too procedural to me, now is it?

So is my example and thought-process proper OOP for the Log-In Process??


Yes.
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
Many of the sites proposed features exist already. Attempting to rebuild something when it already exists seems like the wrong direction for a business that is just starting out. Check out Amazon.com, Google Checkout, PayPal, etc.

http://www.amazon.com/gp/seller/fba/fulfillment-by-amazon.html

http://checkout.google.com/seller/integrate.html

Getting some financing from a local bank or federal grant may help.

As mentioned OO design is an advanced topic. If your goal is to start a business and keep it going and growing it terms of profits ($$$)...you may need to shift your focus.
Victor Ramen
Ranch Hand

Joined: Jul 14, 2008
Posts: 56
Tom Tees wrote:
When you are building a system from scratch, do you tend to model Physical Things or instead Business Processes?



In a typical enterprise app, Physical Things AND Business Processes are both present. e.g. A RegistrationService might use Address and User objects([physical things) to carry out a registration.
Process = verb and object = noun. and both of them are necessary.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Do you model Physical Things or Processes?