01.01.2015 Views

UML Weekend Crash Course™ - To Parent Directory

UML Weekend Crash Course™ - To Parent Directory

UML Weekend Crash Course™ - To Parent Directory

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

294<br />

Sunday Afternoon<br />

MVC pattern in the case study<br />

The case study requirements specify that users must be able to query their appointments<br />

and contacts from both traditional wired Web clients and wireless Web clients such as cell<br />

phones. For the wired Web clients, customers will access the system via Web browsers such<br />

as Internet Explorer or Netscape Navigator and the system will generate HTML for those Web<br />

browsers to display.<br />

Wireless devices such as cell phones usually have extremely limited display capabilities,<br />

very limited input devices such as keypads, limited network bandwidth, and unreliable network<br />

availability. As a result of these limitations, they have their own browsers, protocol,<br />

and markup languages for their special requirements. In North America, most wireless Web<br />

clients have a micro Web browser that communicates via the WAP protocol and interprets<br />

Wireless Markup Language (WML). WML looks very similar to HTML, but it is more compact<br />

and more limited to meet the needs of the restricted wireless devices. Because most of the<br />

case study wireless users have devices that use WML, the architects decide to use that for<br />

the wireless interface.<br />

The system requires two views for interfaces to the querying parts of the application: an<br />

HTML view for traditional wired Web clients and a WML view for wireless Web clients. In<br />

addition, the layout and flow of those views are different because wireless Web clients must<br />

be carefully designed to be easily usable on limited devices. On the other hand, the fundamental<br />

business logic and data business services are the same for both interfaces. The Model<br />

View Controller design pattern principles make this a very simple problem to resolve.<br />

Because your JSPs are the view of the system, there are two sets of JSPs: one with HTML<br />

content, and one with WML content. Both sets of JSPs talk to the same JavaBeans for the<br />

business logic and data manipulation. This is shown in the <strong>UML</strong> Component diagram in<br />

Figure 28-5.<br />

Traditional<br />

Wired Web<br />

Browser<br />

Model<br />

JavaBeans<br />

Wireless Web<br />

Browser<br />

View<br />

JSP pages<br />

with WML<br />

content<br />

JSP pages<br />

with HTML<br />

content<br />

Figure 28-5 <strong>UML</strong> Component diagram, two views with MVC design<br />

The next thing to consider is whether the system requires any special software or hardware<br />

configuration to communicate with the wireless Web clients. Wireless Web clients communicate<br />

using the WAP protocol instead of the HTTP protocol. Because traditional Web<br />

servers are designed to communicate using the HTTP protocol, you might reasonably think<br />

that the system would need another Web server that uses a WAP protocol. In fact, it can<br />

still use a regular HTTP Web server. The wireless network providers have systems called WAP

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!