- Introduction
- Designing the E-Portal
- Let's Build an E-Portal!
- Conclusion
Designing the E-Portal
Before starting to develop the e-portal, of course, it's essential to design it.
Different people have different ways of designing e-business sites, but I like to recognize that in building such a site I am in effect building an online application and the back-end applications architecture that supports it. The back-end applications architecture contains both function (objects) and data (database), and all good methodologies emphasize the need to separate the three architectural types of functionality clearly from one another. I tend to use Web UML (see Note) for the front-end design and the back-end objects, but I find that the more traditional ERDs (entity relationship diagrams) still work better for designing the database, as UML is not as well-suited to database design.
NOTE
For details on using Web UML, see Jim Conallen's book Building Web Applications with UML, Second Edition (Addison-Wesley, 2002, ISBN 0-201-73038-3).
Figure 1 shows my (highly simplified) sequence diagram of the Registration use case.
)
Figure 1 Registration use case for portal.
From the use case diagram, it's clear which objects are needed (User, in this case). Note that this could be written as a Java bean or as a CORBA/COM object (written in any language). It's also obvious which pages are needed (the Registration and Portal pages). Note that these can be written as JSPs (Java Server Pages), ASPs (Active Server Pages), or even CGI pages. The use case also makes it clear that documents and external links will be required on the page.
Because the use case is highly simplified, it doesn't indicate what happens if the registration doesn't succeed, not does it deal with links that link to functionality within the e-portal itself that would involve another use case of its own. It simply makes it clear that once a user is registered, they immediately gain access to the e-portal page and can start to use it.
I believe that use case diagrams are not useful when designing conceptual infrastructures needed to support the front-end functionality. For these infrastructures, I prefer to use ERDs. For example, when designing the newsfeed architecture of an e-portal, the database design might look like that on the left side of Figure 2. In this scenario, the user doesn't have a choice of which newsfeeds are shown, how many/which categories are shown, or how many articles can be viewed within that newsfeed. All is predefined and non-configurable.
On the right side of Figure 2 is a far more flexible newsfeed architecture (though highly denormalized). In this scenario, any user may select one or many newsfeeds (for example, a Yahoo! International newsfeed, a Yahoo! Local newsfeed, and a Reuters Financial newsfeed). Because the user can select feeds from a number of categories, the database needs to record the user's selections for that particular newsfeed. Similarly, the user has the ability to select the number of articles to be displayed in each of the newsfeed categories in this scenario.
)
Figure 2 Data modeling approaches for newsfeed articles.
Similarly, in designing the database for localization of an e-portal, it's possible to make the design either rigid or flexible. On the left side of Figure 3, each user has a predetermined choice of languages and character sets in which any pages can be displayed. On the right side, the user can select the language and character set in which all pages will be displayed. In the right-hand scenario, the user's access to pages is determined by the user's security group/class, whereas in the left-hand scenario access to the page is determined by whether the page is available in the language and character set only. In both cases, the left-hand design is primarily hierarchical, whereas the right-hand design is primarily relational.
)
Figure 3 Flexible modeling provides more flexible localization
functionality.