The beauty of modeling
Recently, I have been thinking about and building a lot of models. Many of you know me as a portal guy, but recently I have taken on a new role in the Software Group Industry Solutions development team, working on IBM’s Intelligent Cities initiative. The solution we are currently developing brings together some of the best products and solutions within IBM, and it’s our job to tie them together in a way that enables city executives and department managers to identify and coordinate activates and events across all the specific domains and departments that make up a city domain. As you can imagine, this is quite a task and the only way to wrap your head around the complexity of this type of environment is through the use of modeling.
Why do we use models? I think we use models primarily because they are quicker and cheaper than trying to build the final solution right away. With a model, you can think about the solution and evolve it without coding yourself into a corner, which can often happen in large projects. In 2002 and 2003, I wrote a series of articles on Modeling WebSphere® Portal portlets with UML. At the time, there was very little information in this area and the challenge for many people in the field was to come up with reusable patterns for portlet developers. Fortunately, we were able to leverage experience in the field to develop portal applications. This led to successful attempts to formalize our approach in a reusable way -- which has always been the goal:
- Form a set of reusable patterns, whether using models, design patterns, or even code encapsulated within an API.
- Learn from your experiences, don’t reinvent the wheel, and shorten your development time and effort as much as possible.
The return of client side development
Client side modeling approach
The goal is to extend the models to the browser. This is especially true for UML-type models, many of which provide (on purpose) very simplistic representations from a particular viewpoint of the system. Once I began to treat the browser as another component in the system, the models seemed to fall into place. Not surprisingly, once I was looking for the right thing, I found an article by Jim Conallen on Modeling Web Application Architectures in UML that describes the same approach.
Extending sequence diagrams
With Web 2.0 applications, sequence diagrams can be one of the most important views of the system that you can provide. Web pages that perform a lot of client side processing can be very chatty as the page reaches back to the server for some bit of information. This is a very common pattern that is used to provide a sense of instant reaction to some action performed by the user. For example, filling in a search box might result in continuously updating a part of the screen in an attempt to try and identify what the user is looking for.
Dojo applications that talk to complimentary REST services need to be modeled in some detail so that developers understand what services are necessary, or perhaps what services already exist. Figure 1 illustrates how you might model that type of behavior by extending the sequence to include interaction of the Web page to existing back end services. Traditionally, you might just return the HTML to the user based on a request, but in this case -- except for the initial load -- the Web page itself initiates many of the interactions with server side components and services.
Figure 1. Sequence with client side interaction
For all the models, it is important to make heavy use of stereotypes to ensure that you can identify components of different technologies. In fact, the use of stereotypes is what makes UML so flexible in it’s ability to stay current as technology evolves over the years (or, in this case, decades).
Web pages as classes
Admittedly, these examples are pretty simple, but hopefully they convey the point and provide a starting point when you think about your own modeling requirements. Not all models are UML diagrams, and sometimes visuals such as a wireframe or a Visio diagram can convey more information to the reader then UML. In this case, it can be useful to have the right visual correctly capture the page interaction. Scott Wilson provides some great mashup stencils for Visio diagrams that can add some power to those types of diagrams. Hopefully these thoughts are helpful as you begin to think about how you can model your applications and portlets that focus on client side interactions.
- IBM Smarter Cities
- Modeling WebSphere Portal portlets with UML, Part 3: Portlet services
- Redpaper: Modeling Web Application Architectures with UML
- Mashup stencil [updated], Scott Bradley Wilson
- IBM developerWorks WebSphere