Object-Oriented Design for WWW Pages

Objective: The purpose of the information is to explain how to apply object-oriented design to the development of World-Wide Web pages and systems.

Status: In progress. I am not an expert on the topic of object-oriented programming, though I have spent time reviewing and reflecting on that means of programming. Considerable motivation for applying object-oriented design to WWW page development is due to the influence of David A. Taylor's book, Business Engineering with Object Technology. The emphasis of the book is that through object modeling, businesses can create software systems that are easier to understand, modify, use, and verify. Through the abstraction that object-oriented design supports, business concerns beyond the computer programmers' intent can be managed through the functioning of the computer model of the business. Abstraction refers to the use of terms and methods that are from the problem-domain rather than the computer-domain, such as using a business practice like GreetCustomer() rather than computer practices like GetName(), LookupTitle(name), BuildGreeting(), and WriteGreetingToFile(). I don't know how much abstraction should be applied to the development of WWW pages; however, having pages that are usable by others with the understandable definition of an object would be neat.

Comment: Seeing these notes again after a year or two of having written them, I see that they do not convey the kind of information one could look for in conversation. I still think that defining WWW files as objects could provide reuse capabilities, though there is not much information here about how to define information files in that way. Maybe with the expanded capability of DHTML, frames, and faster computers the required computing time for integration of the parts (objects) of a site and presentation will be acceptable.

One site related to Object-Oriented Database Management Systems refers to the present document.

• Object modeling works with parts of a project as objects. For example, in a supermarket transaction, the cashier could be modelled as a computer object as well as the store's records, purchased items, and the customer. One benefit of that focus is that thought about the transaction does indeed involve interchanges of those persons and things. So using the straightforward perception of the transaction helps to define the parts of the transaction. Each part has responsibilities and "most closely associated information". An item object includes information about its price. A customer object has access to monies for purchasing requested items. A cashier object can take customer's requests and monies as an agent for the store and notify the store's records. Without object modelling, all of these functions tend to found, defined, and gathered as one group of capabilities. There is less of a system view involved, less abstraction, and thus more particulars to remember and less of an overall sense of what's going on. In fact, in my opinion, it may not be possible for a given person to keep the required particulars in mind enough to be able to combine the functions for expanded functionality or full expression of the system.
• Abstraction allows use (within a computer program) of program functionality (elements, features, and capability) without requiring knowledge of how the functionality is provided. For example, in a control system for a production unit, an alert could be requested without knowing the exact means used to produce the alert (flashing the screen and how to flash the screen, sounding a horn and how to sound a horn). Because a computer program goes into even more particular definitions than the expression of these concepts in words (maybe the parameters of the input for the horn and data constructions and functions for using the data that is required for the process), having access to the alert through the use of one word is an abstraction of (generalized reference to) the actual elements of the alert process.

Eventually, the guidelines and recommendations listed here should be useful, unified, and relevant for WWW development. Right now I'm still gathering information and making it more understandable for myself. The most thorough technical presentation of object-oriented design that I've seen is Ivar Jacobson's Object-Oriented Software Engineering, (1993). His book includes several diagrams that show how his methods work. One purpose of the information is to enable a scope of analysis, design and succeeding maintenance that would otherwise be very difficult to comprehend or complete. Some of the difficulty doesn't fully apply to simpler projects, and much of the difficulty relates to the exact expression required for a programming language. Here are some of the diagrams gathered together into a basic view of the general process.

I read the book, for the most part, during the time of the 1995 Tour de France. Earlier I saw television coverage of two stages of the race in the mountains, and I remember the announcer saying near the end of a race one day, no one gets to this place without feeling pain. While I read the book, the goal of finishing it during my vacation and the basic difficulty in reading it reminded me of the bicycle race. What makes the comment more than just hearing about me is that likely many people are the same. Studying technical subjects that have as their focus overcoming limitations of human concentration and perception may not be pleasant, especially when the information doesn't reflect thoughts that are similar to how we are accustomed to thinking. I hope that I can redeem the time that I spent reading the book, though the memory of it is already fleeting, and show how it can be applied to WWW design. Ivar Jacobson was managing a team of 13 assembly language programmers in 1970 in an object-oriented project, before object-oriented programming was a popular term, and his knowledge and observations are worth consideration.

Here are some beginning notes on the benefits of object-oriented design.

The following guidelines are from Business Engineering with Object Technology, 1995, David A. Taylor. ISBN 0-471-04521-7.

Additional information was included from Dr. Dobb's Journal, A practical Strategy for OO Design, Kanchan Kumar, June 1995, v. 20, Issue 6, pages 34-39 and Communications of the ACM, Creating Products Customers Demand, Anthony F. Hutchings, Steve T. Knox, May 1995, v. 38, n. 5, pages 72-80.

Establish project objective or goal.

major components of the problem

desired behavior/features of the system

undesireable behavior

kind of interface

volume of transactions

performance expectations

sequence of tasks

Use levels of objects

meaningful groups

items do not interact directly with items from another level

Designing a Business Model