<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_14BegtnmEdmO6L4XMImrsA" name="building_web_applications_with_the_uml,4.559124609104376E-305" guid="_14BegtnmEdmO6L4XMImrsA" changeDate="2005-06-21T10:21:21.380-0700" version="7.1.0">
  <mainDescription>&lt;a id=&quot;Top&quot; name=&quot;Top&quot;>&lt;/a> &#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;References&quot; name=&quot;References&quot;>References&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The following books and documents are references for these guidelines:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;i>Building Web Applications with UML,&lt;/i> by Jim Conallen [&lt;a class=&quot;elementLinkWithUserText&quot;&#xD;
        href=&quot;./../../../core.base_rup/customcategories/references_56F06DFD.html&quot; guid=&quot;7.755968586980351E-308&quot;>CONA99&lt;/a>]&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The&amp;nbsp;&lt;a class=&quot;elementLinkWithType&quot;&#xD;
        href=&quot;./../../../core.base_rup/guidances/whitepapers/modeling_web_application_architectures_with_uml_54011136.html&quot;&#xD;
        guid=&quot;_TACPgEWgEdqT6eCCQuiftQ&quot;>Whitepaper: Modeling Web Application Architectures with UML&lt;/a>&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Elaborate on Use-Case Analysis&quot; name=&quot;Elaborate on Use-Case Analysis&quot;>Elaborate on Use-Case Analysis&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The thing that is different compared to what you find in &lt;a class=&quot;elementLinkWithType&quot;&#xD;
    href=&quot;./../../../core.base_rup/tasks/use_case_analysis_A6990185.html&quot; guid=&quot;{28014615-A62F-452D-B821-30C7CAB0EC44}&quot;>Task:&#xD;
    Use-Case Analysis&lt;/a> is that the boundary classes are more focused and singular in purpose. Objects of these classes&#xD;
    have a short life, and any client state (in web pages) needs to be managed explicitly by specific mechanisms. For&#xD;
    example, Microsoft Active Server Pages use &quot;cookies&quot; as an index into a map of the state of all the currently active&#xD;
    clients.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Also, when you read the specification of a use case, the following applies:&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Any mention of a web page translates to a boundary class.&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Any mention of a hyperlink translates to an association from a boundary class to another boundary class or&#xD;
        controller class.&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Verbs or descriptions of processes tend to map to controller classes.&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Nouns map to entity classes.&amp;nbsp;&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    The boundary class, through which communication is initiated, talks to a controller class. The controller class&#xD;
    typically will not respond back through the same instance of this boundary class.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Using Interaction Diagrams&quot; name=&quot;Using Interaction Diagrams&quot;>Using Interaction Diagrams&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    As use-case analysis is going on, the scenarios can be described with sequence diagrams. This helps validate the&#xD;
    existence of analysis objects against a scenario of a use case. If analysis objects are discovered not to participate&#xD;
    in any of your scenarios, they are suspect and need to be reevaluated. The risk here is that if you go too deep in&#xD;
    detail, the diagrams become large and unmanageable. To avoid this, concentrate on short discrete scenarios, and only&#xD;
    include boundary and principal controller and entity objects.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Remember that in web applications boundary objects have a short lifespan. A boundary class may however be instantiated&#xD;
    several times during the execution of a scenario, meaning that there are several boundary objects instantiated from the&#xD;
    same class in the diagram.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The actor in an analysis level sequence diagram interacts with a boundary object. A navigate message is sent from the&#xD;
    actor to the boundary object.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Creating Initial Design Classes&quot; name=&quot;Creating Initial Design Classes&quot;>Creating Initial Design Classes&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;h4>&#xD;
    Initial Boundary Class Designs&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    A boundary class can be mapped to a client page class.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If the boundary class involves inputting information, you would typically associate it with a form (or web form)&#xD;
    through aggregation. A form can be modeled as a nested class of the client page, since its entire lifecycle is governed&#xD;
    by the client page. Forms always have a submit relationship to a server page, which processes the form's values,&#xD;
    ultimately leading to a new returned client page.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If the user interface requires some dynamic behavior on the client, the easiest way this can be accomplished is through&#xD;
    the use of dynamic HTML on the client. In the design model, this usually appears as operations on the client page.&#xD;
    Operations on the client page map directly to java script functions. Attributes of a java page map directly to page&#xD;
    scoped variables of the page. Dynamic HTML event handlers are captured as tagged values.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If the user interface has very sophisticated behavior, you would consider associating an applet with the boundary&#xD;
    class, using an aggregation.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If your architecture is based on a distributed object system (such as RMI, IIOP, or DCOM), then the client page may&#xD;
    reference interfaces to components that communicate directly with the server using RMI, IIOP, or DCOM, circumventing&#xD;
    HTTP. These types of relationships are usually stereotyped &amp;lt;&amp;lt;rmi&amp;gt;&amp;gt;, &amp;lt;&amp;lt;iiop&amp;gt;&amp;gt;, or&#xD;
    &amp;lt;&amp;lt;dcom&amp;gt;&amp;gt; to indicate to the designer any areas where network traffic will happen, thus being candidate&#xD;
    bottlenecks.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Initial Entity Class Designs&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    In designing a web application, the only thing different about entity classes is, if the object resides within the&#xD;
    scope of the client page, the entity object will map to a java script object.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Initial Controller Class Designs&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Control classes map to server pages. Controllers express and coordinate the business logic, and coordinate other&#xD;
    logics. They typically reside on the server. Many controller objects are responsible for building client pages&#xD;
    (essentially, they stream HTML as their principal output). Controller objects can interact with server-side resources,&#xD;
    such as databases, middle tier components, transaction monitors, and so forth.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Controller classes typically map to server-side scripted web pages (active server pages, java server pages).&#xD;
&lt;/p>&lt;br />&#xD;
&lt;br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
