Oil Demand Structural Model

In a previous post, I used UML to model commodity futures trading in order to obtain a better understanding of the recent rise and fall of oil price.

In this post I shift my focus to demand for crude oil. I use the OPEC World Oil Outlook 2007 as my source.

OPEC uses an econometric model called World Energy Model to predict trends in crude oil supply and demand. While I am not interested in the complete econometric model per se, I found their fundamental demand structure quite instructive and have proceeded to model that in UML. I hope this model will provide you with additional useful examples of how UML can be applied to real-world situations.

OPEC recognizes that worldwide demand for oil (and oil products) can be classified under five important sectors, as depicted in the class diagram to the left. OPEC then proceeds to project oil demand for each of these sectors into the future upto the year 2030.

Sectoral Oil Demand

The Demand class underpins this whole model. It encapsulates demand for the years 2005, 2010, 2020, and 2030.

The OPEC World Oil Outlook tabulates demand in million barrels of oil equivalent / day. Why oil equivalent? Because most of the demand is not directly for crude oil but for products that are derived from crude oil.

Total World Oil Demand is modeled as a specialization of demand and as an aggregate of:

• Transportation demand
• Industrial demand
• Residential / commercial / agriculture demand
• Electricity generation demand
• Marine bunker demand

Each of the above encapsulates demand for a particular usage sector and hence each of these is modeled as a  specialization of a Sectoral Demand class which in turn specializes the Demand class.

In one case (i.e. transportation demand) there is two additional levels of aggregation to provider for further breakdown of that sector’s demand.

Now, we can introduce a geographic classification into the model by making the Sectoral Demand class an aggregate of various geographic demands (i.e. specializations of Geographic Oil Demand class) as shown in the next class diagram. 

Geographic Oil Demand

There are three broad geographic regions:

• OECD (Organization for Economic Cooperation and Development)
• Developing Countries
• Transition Economies

These regions are further split into sub-regions. I show some of these sub-regions, which I feel are of special interest, as Notes on these classes. All the geographic demand classes are also specializations of the Demand class. This is notated by displaying the parent class name on the top right corner of each child class. 

Bottom line is, all the classes in our class model are specializations of the Demand class.

Based on this model, the World Oil Outlook 2007 proceeds to present sectoral and geographic demand using numerous tables. Question is, is it possible for a UML diagram to faithfully represent the information presented in these tables?

The answer is “yes”. It is possible to model this tabular data using composite structure diagrams.

Recollect from my earlier posts that composite structure diagrams depict objects (i.e. instances of classes). Hence, it follows that it should be possible to show specific values for attributes of these instances. This is the key to understanding the following diagrams.

For illustration purposes, I focus my attention on the transportation demand.

Consider the following table (extracted from the OPEC World Energy Outlook 2007), which depicts the worldwide demand for oil arising from the road transportation sector.

Road Transportation Demand

Click here to see the same information represented using a composite structure diagram.

Here is a table that depicts non-road transport demand (mostly air transport demand) from around the world.

Non-Road Transportation Demand

Click here to see the same information represented using a composite structure diagram.

Here is a table that cumulates the above two and depicts the total transportation demand for oil around the world.

Transportation Demand

Click here to see the same information represented using a composite structure diagram.

Finally, here is a composite structure diagram that summarizes the total transportation demand in terms of road and non-road demand. The OPEC World Oil Outlook 2007 does not present a corresponding table with this information.

Transportation Demand Summary

Are these UML diagrams in any way superior to the tabular representation? I do not claim they are. I do not recommend replacing all the tables in the OPEC World Oil Outlook 2007 with composite structure diagrams!

On the other hand, if you are developing a software system which stores demand data in a database and allows users to drill down to a specific sector and geography to view its demand (maybe using a tree structure), then the class diagrams I have presented here constitute a meaningful object-oriented information design. The composite structure diagrams complement the class diagrams by showing clearly what some of these classes will look like when they are instantiated with actual data. Therein lies their value.

Aside: Domain Model vs. Programming Model

This model is good for representing the domain clearly but from a programmer’s perspective it has too much redundancy, i.e. there are so many Demand sub-classes which pretty much look the same (except for the relationships). Also, when it comes to implementing the rollup function (which rolls-up demand up the aggregation hierarchy), this model is somewhat cumbersome.

Hence, a programmer would most likely go in for a vastly simplified model as shown below.

Simplified Demand Model

This is wonderful for programming but from the perspective of understanding the domain, this is just plain awful!

What have we gained by this model?

• There are just four classes to worry about.
• Each rollup function can be a recursive function that simply follows an aggregation chain all the way down. Only three rollup functions need be programmed. All other sub-classes get it by inheritance.

What have we lost due to this simplification?

• This model has relaxed the type constraints enforced by the earlier model. In the earlier model, each sector and each geography had its own class with very specific aggregation relationships whereas in this simplified model that specificity is gone. Hence, in this simplified model nothing constrains one from adding North America Demand into, say, Transition Economies Demand! 
• The rollup functions cannot be recursive functions that simply follow an aggregation chain. Each rollup function (on each sub-class) has to be separately programmed to specifically follow appropriate aggregation end points.

What does this simplified model illustrate?

Domain modeling and modeling for programming are two different activities and might result in two vastly different models both of which are sound and complete.

In other words, what is good for the goose may not be good for the gander!

If you are tired of all this UML stuff and are looking for some interesting dope on world oil demand, here goes:

• Cars consume five times more oil than planes and twelve times more oil than ships!
• North America is sucking the world dry (but you know that already, right?)
• Developing countries are increasing their rate of sucking and will catch up with OECD by 2025
• As for Transition economies, oh well who cares about them anyway?

If you are interested in a concise picture of oil supply and consumption, check out this Financial Times web page. It is really cool and informative. India ranks #4 in consumption (no wonder FIIs are fleeing Indian since oil price started going up; also explains why Dr. Manmohan Singh is battling to increase civilian nuclear capability) and #5 in refining capacity (more power to Mukesh Ambani pls)!