UML Weekend Crash Course⢠- To Parent Directory
UML Weekend Crash Course⢠- To Parent Directory UML Weekend Crash Course⢠- To Parent Directory
Session 28—Analysis and Architectural Design of a Web Application 293 servlet turned inside out; instead of having HTML in your Java, you have Java in your HTML. So simply switching from servlets to JSPs isn’t enough to successfully separate your HTML view from your Java model and controller. Thus, there must be another way to get the Java code out of the JSP pages. A simple solution to this problem would be to move any large chunks of Java code from your JSP page into regular Java classes and have your JSP page contain method calls to the methods in those classes. This would remove a very large quantity of Java code from the JSP, but the JSP page would still have Java syntax method calls in it. JavaBeans represent a refinement of this solution. For this purpose, a JavaBean is just a regular Java class with private attributes and public get/set methods for accessing the attributes. Figure 28-4 shows a UML Class diagram of a simple JavaBean for tracking a customer order. Creating a JavaBean is as simple as it sounds; with proper encapsulation, you will probably meet the requirements of JavaBeans without even trying. OrderBean - item: String - quantity: int - costPerItem: double + setItem (i: String): void + getItem (): String + setQuantity (q : int): void + getQuantity () : int + setCostPerItem (c : double) : void + getCostPerItem () : double + getTotalCost () : double + submitOrder () : boolean Figure 28-4 UML Class diagram, JavaBean JSP has special markup tags that can be used to call the get and set methods of the JavaBean. Thus, the Java syntax method calls can be replaced with markup tags. For example, the Java syntax and the JSP tag syntax shown here are equivalent method calls, but it may be easier for a content developer to use the JSP tag syntax. Java Syntax: JSP Tag Syntax: Typically, the code that you move from the JSP pages into JavaBeans will include your application data, database access code, and business services. What is left in your JSP is largely the Web content, which is the view of that data. Thus, by using JavaBeans, you can separate your view from your model and take the first step towards an MVC Web architecture. Note This section addresses JavaBeans, not Enterprise JavaBeans (EJB). EJB is a far-more-involved technology and is beyond the scope of this book.
294 Sunday Afternoon MVC pattern in the case study The case study requirements specify that users must be able to query their appointments and contacts from both traditional wired Web clients and wireless Web clients such as cell phones. For the wired Web clients, customers will access the system via Web browsers such as Internet Explorer or Netscape Navigator and the system will generate HTML for those Web browsers to display. Wireless devices such as cell phones usually have extremely limited display capabilities, very limited input devices such as keypads, limited network bandwidth, and unreliable network availability. As a result of these limitations, they have their own browsers, protocol, and markup languages for their special requirements. In North America, most wireless Web clients have a micro Web browser that communicates via the WAP protocol and interprets Wireless Markup Language (WML). WML looks very similar to HTML, but it is more compact and more limited to meet the needs of the restricted wireless devices. Because most of the case study wireless users have devices that use WML, the architects decide to use that for the wireless interface. The system requires two views for interfaces to the querying parts of the application: an HTML view for traditional wired Web clients and a WML view for wireless Web clients. In addition, the layout and flow of those views are different because wireless Web clients must be carefully designed to be easily usable on limited devices. On the other hand, the fundamental business logic and data business services are the same for both interfaces. The Model View Controller design pattern principles make this a very simple problem to resolve. Because your JSPs are the view of the system, there are two sets of JSPs: one with HTML content, and one with WML content. Both sets of JSPs talk to the same JavaBeans for the business logic and data manipulation. This is shown in the UML Component diagram in Figure 28-5. Traditional Wired Web Browser Model JavaBeans Wireless Web Browser View JSP pages with WML content JSP pages with HTML content Figure 28-5 UML Component diagram, two views with MVC design The next thing to consider is whether the system requires any special software or hardware configuration to communicate with the wireless Web clients. Wireless Web clients communicate using the WAP protocol instead of the HTTP protocol. Because traditional Web servers are designed to communicate using the HTTP protocol, you might reasonably think that the system would need another Web server that uses a WAP protocol. In fact, it can still use a regular HTTP Web server. The wireless network providers have systems called WAP
- Page 266 and 267: Session 23—Applying the Extended
- Page 268 and 269: SESSION 24 Modeling the Development
- Page 270 and 271: Session 24—Modeling the Developme
- Page 272 and 273: Session 24—Modeling the Developme
- Page 274 and 275: Session 24—Modeling the Developme
- Page 276 and 277: Session 24—Modeling the Developme
- Page 278 and 279: SESSION 25 Modeling the Static View
- Page 280 and 281: Session 25—Modeling the Static Vi
- Page 282 and 283: Session 25—Modeling the Static Vi
- Page 284 and 285: Session 25—Modeling the Static Vi
- Page 286 and 287: SESSION 26 Modeling the Static View
- Page 288 and 289: Session 26—Modeling the Static Vi
- Page 290 and 291: Session 26—Modeling the Static Vi
- Page 292 and 293: Session 26—Modeling the Static Vi
- Page 294 and 295: Session 26—Modeling the Static Vi
- Page 296 and 297: PART # V Sunday Morning Part Review
- Page 299 and 300: PART VI Sunday Afternoon Session 27
- Page 301 and 302: 278 Sunday Afternoon design, and mo
- Page 303 and 304: 280 Sunday Afternoon :User :Web Br
- Page 305 and 306: 282 Sunday Afternoon studied Java p
- Page 307 and 308: 284 Sunday Afternoon and time. A JS
- Page 310 and 311: SESSION 28 Analysis and Architectur
- Page 312 and 313: Session 28—Analysis and Architect
- Page 314 and 315: Session 28—Analysis and Architect
- Page 318 and 319: Session 28—Analysis and Architect
- Page 320 and 321: SESSION 29 Design of a Web Applicat
- Page 322 and 323: Session 29—Design of a Web Applic
- Page 324 and 325: Session 29—Design of a Web Applic
- Page 326 and 327: Session 29—Design of a Web Applic
- Page 328 and 329: Session 29—Design of a Web Applic
- Page 330 and 331: SESSION 30 UML Modeling Tools Sessi
- Page 332 and 333: Session 30—UML Modeling Tools 309
- Page 334 and 335: Session 30—UML Modeling Tools 311
- Page 336 and 337: Session 30—UML Modeling Tools 313
- Page 338 and 339: PART VI # Sunday Afternoon Part Rev
- Page 340 and 341: APPENDIX A Answers to Part Reviews
- Page 342 and 343: Answers to Part Reviews 319 20. I a
- Page 344 and 345: Answers to Part Reviews 321 26. It
- Page 346 and 347: Answers to Part Reviews 323 22. Dra
- Page 348 and 349: Answers to Part Reviews 325 Sunday
- Page 350 and 351: Answers to Part Reviews 327 It maps
- Page 352 and 353: APPENDIX B What’s on the CD-ROM T
- Page 354 and 355: What’s on the CD-ROM 331 Trial So
- Page 356 and 357: Glossary abstract class A class th
- Page 358 and 359: Glossary 335 automatic transition A
- Page 360 and 361: Glossary 337 decomposition Separati
- Page 362 and 363: Glossary 339 link A relationship b
- Page 364 and 365: Glossary 341 overloading Used to de
Session 28—Analysis and Architectural Design of a Web Application 293<br />
servlet turned inside out; instead of having HTML in your Java, you have Java in your<br />
HTML. So simply switching from servlets to JSPs isn’t enough to successfully separate your<br />
HTML view from your Java model and controller. Thus, there must be another way to get the<br />
Java code out of the JSP pages.<br />
A simple solution to this problem would be to move any large chunks of Java code from<br />
your JSP page into regular Java classes and have your JSP page contain method calls to the<br />
methods in those classes. This would remove a very large quantity of Java code from the<br />
JSP, but the JSP page would still have Java syntax method calls in it. JavaBeans represent a<br />
refinement of this solution. For this purpose, a JavaBean is just a regular Java class with<br />
private attributes and public get/set methods for accessing the attributes. Figure 28-4<br />
shows a <strong>UML</strong> Class diagram of a simple JavaBean for tracking a customer order. Creating a<br />
JavaBean is as simple as it sounds; with proper encapsulation, you will probably meet the<br />
requirements of JavaBeans without even trying.<br />
OrderBean<br />
- item: String<br />
- quantity: int<br />
- costPerItem: double<br />
+ setItem (i: String): void<br />
+ getItem (): String<br />
+ setQuantity (q : int): void<br />
+ getQuantity () : int<br />
+ setCostPerItem (c : double) : void<br />
+ getCostPerItem () : double<br />
+ get<strong>To</strong>talCost () : double<br />
+ submitOrder () : boolean<br />
Figure 28-4 <strong>UML</strong> Class diagram, JavaBean<br />
JSP has special markup tags that can be used to call the get and set methods of the<br />
JavaBean. Thus, the Java syntax method calls can be replaced with markup tags. For example,<br />
the Java syntax and the JSP tag syntax shown here are equivalent method calls, but it<br />
may be easier for a content developer to use the JSP tag syntax.<br />
Java Syntax: <br />
JSP Tag Syntax: <br />
Typically, the code that you move from the JSP pages into JavaBeans will include your<br />
application data, database access code, and business services. What is left in your JSP is<br />
largely the Web content, which is the view of that data. Thus, by using JavaBeans, you can<br />
separate your view from your model and take the first step towards an MVC Web architecture.<br />
Note<br />
This section addresses JavaBeans, not Enterprise JavaBeans (EJB). EJB is a<br />
far-more-involved technology and is beyond the scope of this book.