学步园

Mikko Kontio (mikko.kontio@softera.fi)
Technology Manager, Softera
18 May 2005

Put all that architecture design theory into practice this month, as Mikko walks you through the design of an RSS reader -- from setting requirements to evaluating results.

Really Simple Syndication, or RSS, is a format for syndicating news and the content of news-like sites. An RSS reader is an application that lets you read RSS feeds from any device that supports MIDP (Mobile Information Device Profile), including a mobile phone. In this month's Architectural manifesto, I'll use the example of an RSS reader to put the theory I've talked about for the past several months into practice, by walking you through the architectural design of an RSS reader.

Every step of designing the RSS reader has been discussed in a previous column, so they should be familiar to you if you've been following along. I'll start by establishing the application's functional requirements and quality attributes. Next, I'll amplify these requirements with several use case models; in this case, sequence diagrams. Next, I'll use the 4+1 view model to better understand the proposed application from multiple angles. Finally, I'll return to the quality attributes, this time using them to gauge how well the application design lives up to its original specification.

See Resources for links to previous columns if you need to brush up on any of the above concepts before you begin.

The example application
The example RSS reader application is quite simple: it fetches a given RSS file from a given URL (the Web address of the RSS file), parses it, and lets you browse its items. Because URLs are long and writing them with a mobile phone is difficult and error prone, the application has a list of feed URLs. You can select frequently used feeds from that list and also add interesting ones to the list, either manually or using a Web-based search. It is also possible to update and remove feeds from the list.

Note that the example system is a client/server application consisting, architecturally speaking, of two application layers: one mobile and one Web server.

Requirements specification
Most application designs start with a requirements specification, which consists of functional requirements and quality attributes, as well as any design constraints. Because I've discussed the details of writing a requirements specification in a previous column (see Resources), here I'll simply list the functional requirements of the system.

On the client, side the system must:

• Store a list of the feed URLs (called My List)
• Fetch a feed and display its items
• Update and remove the feed URLs on the list
• Add feed URLs manually
• Perform a Web-based search for feed URLs and add selected ones to the list

On the server side, the system must:

• Allow user registration
• Allow the mobile application to check user registration from a single point of entry
• Allow the client application to fetch feed URLs from a feed service

Quality attributes
Quality attributes are next. As I explained in a previous column, the trick to defining quality attributes is to focus on making them concrete, measurable, and actionable.

Because the example system is quite simple, it doesn't have many quality attributes; the most important ones are usability and performance.

Usability

(1)The client application must be very simple to use. The user must be able to read an RSS feed with two clicks/menu choices from the main menu; (2) the application should always inform the user of time-consuming operations by displaying a message on the screen.

Performance

The client application must start in less than two seconds.

Design constraints
As part of setting the requirements, it's important to consider the system's design constraints, which may be set by the type of system you're developing or by stakeholders in the system, such as the client. The example application has two major design constraints:

• The client application must be implemented on MIDP 1.0.
• Development must not cost much or take too long.

The 4+1 views
The 4+1 views -- logical, process, implementation, data, and use case -- allow architects to examine different parts of an architecture separately, thus easing the complexity of the overall viewing. I'll start with the "plus-one" use case view, which often encompasses the other views, and then look at select facets of the application more closely.

Two use cases
For the purpose of the example, I'll focus just on the two most important use cases:

• Fetching and parsing an RSS feed
• Browsing feed categories

Fetching and parsing an RSS feed is the most important use case for the application because it is the most often-used function (see Figure 1). First, the main class (the MIDlet class) gets the URL of the feed from the MyList class and then calls the HttpConnection's fetch() method. This method makes an HTTP connection to the given URL and fetches the feed from the Web server.

The feed is an XML document and the MainMIDlet uses the XMLParser to parse the document and to create a Feed, a class that contains all the document's titles and descriptions.

Figure 1 shows the use case diagram for fetching and parsing an RSS feed.

Figure 1. Fetching and parsing an RSS feed

The use case for browsing categories consists of several phases of action. First, the user gets a list of categories (such as News, Sports, Science, and so on), then chooses one and gets to see all the feeds in that particular category. From these the user can select feeds to add to his or her personal feed list (called My List).

Figure 2 shows how the mobile application fetches all the categories from the feed service. The MainMIDlet uses the same HttpConnection as before, but calls a different method, getCategories(). The HttpConnection makes a connection to the feed service and gets the categories. These categories are put into a List, which is shown to the user. The user selects one of the categories and initiates a commandAction() call to the MainMIDlet. The commandAction calls the getFeed(String) and passes on the selected category. Now the HttpConnection gets a list of feeds in that category. The feed names are put into a List again and shown to the user.

Figure 2. Fetching all the categories from the feed service

Now let's look at the most significant facets of the application in more detail.

The logical view
The logical view shows the significant packages, classes, and components of the system. For simplicity I'll consider only the main classes of the system, which are shown in Figure 3.

Figure 3. The main classes of the system

The MainMIDlet class is inherited from the MIDlet class. It inherits all the necessary methods for the application from MIDlet. The MainMIDlet class essentially controls everything in the application.

The MyList class contains all the necessary functions for retrieving and fetching feed data saved by the user. The data is saved in the MIDP platform's RMS (record management system) storage.

The HttpConnection class encapsulates the functions for making HTTP connections. The fetch() method fetches the contents of an RSS feed, the getCategories() method fetches the categories from the feed service, and the getFeeds() method fetches all the feeds in a given category.

The XMLParser is a third-party parser with a small memory footprint (it needs to be fast!). The XMLParser parses the XML document and creates a Feed.

The FeedService is shown here as a class, but in real life it is a complete Web application. The requirements for the Web application are quite similar to any CMS (content management system) or groupware with a registration feature. I have plenty of options when choosing the feed service for my application, many of them open source (see Resources).

Likewise, I have many options when it comes to handling the categories. In this case, I would choose PHP scripts: a fast, easy, and affordable solution.

The process view
The process view shows the system's processes and how they communicate, which can be helpful in determining how the system will use its resources and how you can best use your development time. For example, most of the RSS reader application's network traffic is directed to different Web servers that offer RSS feeds. This means the Category service won't get much traffic, but it must be able to handle many requests. Fortunately, the Web server will take care of request handling so all I have to do is to make sure the scripts are simple and fast. The process view also confirms that the processes on the server don't interact, giving me one thing less to worry about.

The implementation view
The implementation, or physical, view describes how the application is installed and how it executes in a network of computers. This view takes into account non-functional requirements like availability, reliability, performance, and scalability.

Figure 4 shows the layers and nodes of the system. Note that the RSS reader is run on the mobile devices, which connect to the Web server. Basically the system has two layers: the client layer and the server layer.

Figure 4. The implementation view of the system

The data view
The data, or development, view can be used to study the placement of data in the system and is also a good way to view the layers of a system in a layered architecture. In this case, the system has two layers, each storing relatively little data. The mobile application layer stores the details of the feeds, and the Web application layer stores categories and feed URLs. Here are the specifics of data storage for the example application:

Mobile application layer

The mobile application stores the data on the My List. This requires one RMS record store with fields for the feed title and feed URL.

Web server application layer

The Web server application stores the categories and the feed URLs. All the categories are stored in one XML file and each of the categories has its own file, so the server application doesn't need a database for categories.

Having studied the views, I'm pretty satisfied with my application: I think it's sound. The final design step is to run through my quality attributes again, and see how well my proposed design fills the initial requirements.

Evaluation
I had three basic quality attributes and some design constraints thrown in for good measure. Here's my evaluation of how the proposed design meets these requirements:

Usability

The user can read a feed with two clicks.

Performance

The start-up of the application requires only the necessary initiations and no extra operations, so the application starts in less than two seconds.

Design constraints

The client application is implemented on MIDP 1.0 and the Web server design is light enough that implementing it won't take long.

Looks like the design has met its goals -- which means I'm happy!

In conclusion
While quite simple, the RSS reader example served to demonstrate the real-life application of all the architectural design theory you've learned about over the past several months. I started with a list of the system's functional requirements, quality requirements, and design constraints. I then developed two use cases to describe the most important functions of the system, and used a series of views to study how those use cases would be implemented and would interact at different levels of the system. Finally, I evaluated the proposed system design in terms of how well it met my quality requirements and design constraints.

Of course, the architectural design and documentation of a system are half the game when it comes to building an application. But following the procedure here ensures a sound design that has been methodically studied and evaluated before any code has been written.

Tune in next month, when I'll show you how to document large architectures.

Resources

• Have a look at the RSS Reader application on which this month's working example is based!

• Learn more about J2ME's record management system while also building an example mobile application for order placement, with Naveen Balani's tutorial "Build smart J2ME mobile applications" (developerWorks, April 2005).
• Get an overview of the architectural design process (developerWorks, October 2004).
• Brush up on the essentials of writing a requirements specification (developerWorks, December 2004).
• Learn how to write quality attributes that are concrete, measurable, and actionable (developerWorks, December 2004).
• Use the 4+1 view model to study and document your software architecture (developerWorks, December 2004).
• Visit Mikko's blog, where he writes frequently about architectural design.
• Get involved in the developerWorks community by participating in developerWorks blogs.
• Don't miss a single installment of the Architectural manifesto column! See the column series page for a complete listing of previous installments in this series.
• The Wireless zone specializes in articles covering various Web-based solutions.
• The Developer Bookstore presents a comprehensive listing of technical books, including hundreds of Web-related titles.