Architectural manifesto: Designing an RSS reader

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

Level: Introductory

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
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.

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

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 mikko.kontio@softera.fi.

Designing_an_FPGA-Based_RFID_Reader

  • 2013年04月14日 18:30
  • 179KB
  • 下载

PhoneGap RSS Reader

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

An Architectural Approach To Level Design 2014

  • 2017年04月05日 11:40
  • 16.55MB
  • 下载

Native Rss Reader 的资料

转:http://hi.baidu.com/mikyliang/blog/item/11d420d3135832013af3cf19.html RSS文档的构成 2007-05-04 14:58 ...

An Architectural Approach to Level Design my

  • 2016年07月20日 06:57
  • 16.42MB
  • 下载

Google Reader关闭,RSS订阅将用什么?

今天熟练的打开chrome浏览器,习惯的点击google reader之后,映入眼前最大的新闻就是一篇A second spring of cleaning的文章,其中谷歌宣布关闭包括Google R...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Architectural manifesto: Designing an RSS reader
举报原因:
原因补充:

(最多只允许输入30个字)