Architectural manifesto: Designing an RSS reader

原创 2005年05月26日 15:31:00
A working example for beginning software architects

Level: Introductory

Mikko Kontio (
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.

(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.
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
A sequence diagram for a fetching-and-parsing use case

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
A sequence diagram for a browsing use case

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
A class diagram for the example application

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
A diagram of the layers and nodes 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.

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:

The user can read a feed with two clicks.
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.


About the author
Mikko Kontio works as a Technology Manager for the leading-edge Finnish software company, Softera. He holds a Masters degree in Computer Science and is the author and co-author of several books, the latest being Professional Mobile Java with J2ME, published by IT Press. Mikko can be reached at


1 简介 -------  newsticker是一个RSS阅读器,它支持以下几种格式  * RSS 0.91  * RSS 0.92  * RSS 1.0  * RSS 2.0  * Atom 0....
  • lujun9972
  • lujun9972
  • 2015年05月26日 07:33
  • 673


转载于:   由于项目的问题,需要有RSS订阅的概念,以前听说过这个技术,但是却没使用过。今天下午正好没事做,而公司又有这方面...
  • LanSeTianKong12
  • LanSeTianKong12
  • 2016年09月02日 11:13
  • 1124

新的RSS reader

之前用的有道阅读,但是很不用心,很多订阅都收不到。 现在转到
  • robertsong2004
  • robertsong2004
  • 2014年07月11日 16:26
  • 651

About RSS Reader

目前RSS reader只是一个单向流通的工具。以后我想RSS reader应该会变成双向流通的工具。并且我看到MS,最近提出了一个叫SSE的规范,正好也是描述双向信息流的...
  • SimbaRD
  • SimbaRD
  • 2006年02月05日 22:34
  • 499

PhoneGap RSS Reader

这是关于如何使用phoneGap来开发手机上的RSS阅读器的文章,原作者分别写了四个版本。如下所示: 原文链接:
  • zhbhun
  • zhbhun
  • 2012年08月11日 12:42
  • 1360

Google的RSS reader自然是Beta版,自然是AJAX应用(那个列表滚动还是很酷的),自然和gmail帐户连在一块儿。自然不会让俺放弃俺的SharpReader? 原因很简...
  • g9yuayon
  • g9yuayon
  • 2005年10月08日 05:24
  • 1991

OReilly.Designing.Data-Intensive.Applications.2017.3.epub 英文原版 免费下载

下载地址: OReilly.Designing.Data-Intensive.Applications.2017.3.epub
  • jiongyi1
  • jiongyi1
  • 2018年01月01日 11:09
  • 169

RSS Reader完全指南

Bloglines还是抓虾?还是Google Reader?随着近日Bloglines又开始忽悠之旅,许多人又开始考虑放弃它了。真的应该另选高明吗?以下我将给出我的RSS解决方案。RSS成为类似聊天软...
  • pengnan1111
  • pengnan1111
  • 2008年06月10日 10:03
  • 208

Designing Data-Intensive Applications(设计数据密集应用)- O'Reilly 2017 读书笔记

Designing Data-Intensive Applications The Big Ideas Behind Reliable, Scalable, and Maintainable Syst...
  • cteng
  • cteng
  • 2017年04月05日 19:01
  • 3359

读书笔记-Designing Interfaces中文版

“模式是某个对象的结构和行为上的特点”,这是一本关于界面设计模式的书。为什么界面设计中模式很重要?因为 对设计师而言: 模式捕捉了常用的结构,是关于best practice的总结和沉淀模式可以快速...
  • ysydao
  • ysydao
  • 2013年08月15日 09:13
  • 892
您举报文章:Architectural manifesto: Designing an RSS reader