<?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="-1xE2ZW3MjNAJ7jkaZNbkww" name="visual_modeling,_1fM3AC9_EduW5uTjiIcspQ" guid="-1xE2ZW3MjNAJ7jkaZNbkww" changeDate="2006-11-21T11:21:26.000-0800" version="1.0.0">
  <mainDescription>&lt;h3>&#xD;
    Introduction&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Using visual modeling techniques to design software can help break down complex problems into a series of smaller,&#xD;
    easier to manage tasks. Sharing pictures rather than written documents or source code also helps the understanding and&#xD;
    communication of difficult concepts. Adopting standard modeling notations such as the UML increases this capability by&#xD;
    helping to make diagrams precise and unambiguous.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The degree of formality used when producing and disseminating models should vary according to your needs. Small,&#xD;
    collaborative teams modeling around whiteboards and capturing the results on a sheet of paper or with digital cameras&#xD;
    can yield good results. This can also help the team focus on producing software with the help of models; rather than&#xD;
    becoming sidetracked into over-engineering both the models and the solution. Modeling tools provide additional value to&#xD;
    projects, especially for more complex systems. Their specifics of use are outside the scope of this guideline, however.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This guideline does not describe a formal sequential progression through prescriptive design steps. Whether some or all&#xD;
    of these techniques are needed, or how long is spent on them will vary depending on real-world issues such as the&#xD;
    complexity of the requirements; the experience of the designer; and the way the team works.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This guideline uses a simplified scenario (Login) to help keep the focus on understanding the techniques rather than&#xD;
    the specific requirements. In the real-world, it is doubtful that much time would be spent modeling a simple problem.&#xD;
    Here is the use case diagram, for reference;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img height=&quot;142&quot; alt=&quot;User Login Use Case Model&quot; src=&quot;resources/user_login_ucm.jpg&quot; width=&quot;472&quot; />&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Identify elements&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Render the identified design elements as classes in a UML diagram.&amp;nbsp; Apply appropriate stereotypes and optionally&#xD;
    render the class using an icon specific to the stereotype to characterize the intent of the class in the design.&amp;nbsp;&#xD;
    Name and briefly describe the classes in a few sentences. Do not spend too much time working on associations, as these&#xD;
    will be developed through working on collaborations in the next step.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Classes can be drawn as a basic UML rectangle or with a specific symbol associated with a particular stereotype.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The resulting class diagram should be conceptually similar to this one:&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img height=&quot;228&quot; alt=&quot;Identify Elements - Initial Class Model&quot; src=&quot;resources/identify_elements_bce.jpg&quot;&#xD;
    width=&quot;290&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    For this example, the &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html&quot;&#xD;
    guid=&quot;_uF-QYEAhEdq_UJTvM1DM2Q&quot;>Entity-Control-Boundary Pattern&lt;/a> has been used to derive two classes (LoginUI and&#xD;
    LoginController). In addition, two design elements already identified in the architecture (SecuritySystemInterface and&#xD;
    User) have also been incorporated.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Determine how elements collaborate to realize the scenario&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    When determining collaboration, two kinds of diagrams are useful.&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        A dynamic object diagram, showing how the design elements collaborate to realize the requirements.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        A static class diagram, showing the classes involved in realizing the requirements.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Remember to also update any other impacted diagrams as appropriate, based on modifications or additions to the design.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Create a number of dynamic object diagrams that walk through how a set of objects collaborate to perform the behavior&#xD;
    of the scenarios.&amp;nbsp; Even if just one scenario is being designed, this might take multiple diagrams to render it in&#xD;
    smaller, understandable chunks or from multiple contexts.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img style=&quot;WIDTH: 776px; HEIGHT: 355px&quot; height=&quot;355&quot; alt=&quot;User Login Sequence Diagram&quot;&#xD;
    src=&quot;resources/user_login_seq.jpg&quot; width=&quot;776&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The above sequence diagram shows the user credentials being passed through to the security system for authentication.&#xD;
    Steps in the use case scenario are transformed into messages between the participating objects. The messages in this&#xD;
    example are not yet fully formed (there are no parameters or return values), so they are prefixed with &quot;//&quot; to show&#xD;
    that more work is needed.&amp;nbsp; A sequence diagram was used in this example, but a communication diagram could have&#xD;
    been used.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It&amp;nbsp;can be&amp;nbsp;useful to create one or more static class diagrams that show the classes in the design that support&#xD;
    the realization.&amp;nbsp; These class diagrams are often called View of Participating Classes diagrams, they provide a&#xD;
    focused view on the overall design by only showing the classes, relationships, operations, and attributes relevant to&#xD;
    the collaboration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img height=&quot;469&quot; alt=&quot;Login VOPC&quot; src=&quot;resources/login_vopc.jpg&quot; width=&quot;448&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This diagram shows the operations and relationships that were identified by drawing the sequence diagram. The&#xD;
    relationships in this example&amp;nbsp;have not been refined yet, so they are just shown as simple associations. Remember&#xD;
    to examine the diagram to verify that the design can support the behavior in the sequence diagram.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Working at this level of detail in the model during the early stages of design can be helpful. It keeps the diagrams&#xD;
    relatively simple and easy to understand. It makes them easier to draw in a workshop and easier to change during&#xD;
    discussion. It is often easier to add the detail once there is agreement on the fundamentals.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Refine design decisions&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Once the fundamentals of the design are relatively stable, you can begin to add detail to the design. Some of this can&#xD;
    be performed in code or in the model. If modeling is chosen, then refine attributes, responsibilities and&#xD;
    relationships.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Describe responsibilities&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Class responsibilities are either actions to be performed by an object or knowledge maintained and provided to other&#xD;
    objects. Each class will typically have several responsibilities; each responsibility will evolve into one or more&#xD;
    operations during design.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Responsibilities are derived from messages on interaction diagrams or from non-functional requirements that a class has&#xD;
    to support. Document a responsibility by giving it a name, and optionally a brief description (what it does).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    These operations can be left as self-evident from their context, they can be given textual descriptions of the&#xD;
    algorithm required to perform the behavior, or they could spawn off another whole pass of this technique where a set of&#xD;
    classes that collaborate together to perform the internals of the operation are identified, etc.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Describe attributes and associations&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    A class may have to store simple data information, like: string, integer, and the like. For such simple type of&#xD;
    information, attributes are defined for classes. For a more complex or &quot;behavioral&quot; attribute, consider creating an&#xD;
    extra class and establish an association to it.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    To perform their responsibilities, classes may depend on other classes to supply needed behavior. These other classes&#xD;
    might be ones already identified in this design session, they might be existing classes pulled from the architecture,&#xD;
    or the need for new classes might be conceived. Associations in a class diagram can be used to represent inter-class&#xD;
    relationships.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img height=&quot;439&quot; alt=&quot;Login VOPC (Refined)&quot; src=&quot;resources/login_vopc_refined.jpg&quot; width=&quot;557&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This diagram shows a number of refinements. The LoginUI class has been replaced by LoginForm. The User class has been&#xD;
    renamed UserCredentials and is created by the LoginForm class rather than LoginController. It is then used as a&#xD;
    parameter for subsequent messages rather than passing the individual attributes. The SecuritySystemInterface class has&#xD;
    been refined into two elements, ISystemSecurity, which provides a simple façade for interaction with the rests of the&#xD;
    design; and SecuritySystemProxy, which handles interaction with the external security system.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Design internals&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The classes in the design are likely to need to be distributed amongst different packages and subsystems or components.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img height=&quot;304&quot; alt=&quot;User Login - Design Packages&quot; src=&quot;resources/dv_packaging.jpg&quot; width=&quot;571&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In this example, the LoginForm, LoginController and UserCredentials elements have been placed in a package called&#xD;
    LocalSecurity. The SecuritySystemProxy is a part of a subsystem called SecuritySystemAdapter which realizes the&#xD;
    ISecuritySystem interface. The SecuritySystemAdapter wraps the legacy SecuritySystem, expressed here as a component&#xD;
    offering a validateUser interface.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Each of these packaged elements can be distributed amongst the team for further development work.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Conclusion&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    This guideline walked through the techniques in a concrete manner started with a scenario of a use case through to&#xD;
    distributing the classes identified into a set of packages. This example demonstrates a technique for designing&#xD;
    visually, but it should be considered as just one conceptual pass of design.&amp;nbsp; One could as easily apply this&#xD;
    technique when defining the internals of how the SecuritySystemProxy class will collaborate with a set of classes to&#xD;
    validate the credentials.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    When applying this guideline, work in small chunks and keep in mind the goal of delivering software to the users that&#xD;
    provides value. To deliver high-quality software requires consideration of how the pieces will work together to deliver&#xD;
    that value. But as soon as key decisions have been made and the decisions have been communicated to the appropriate&#xD;
    team members, the team should move on to implementing the source code to verify the design and deliver the value.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
