<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore"
    xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-1HWHN5iFc1KJiC7WdlvipA"
    name="build_object_models,_ZffcIDmiEdy8N6BRpa8ByQ" guid="-1HWHN5iFc1KJiC7WdlvipA"
    authors="Jerome Boyer" changeDate="2008-01-28T21:30:45.875-0800" version="1.0.0">
  <mainDescription>&lt;p class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0in&quot;>&#xD;
    &lt;span style=&quot;mso-bidi-language: HE&quot;>Depending of the technology used there is different approach to this task. The&#xD;
    domain object model at the enterprise level will represent a complex data model a rule architect does not want to&#xD;
    expose as-is to the rule engine and the rule authoring environment. Navigating a complex graph of objects will bring&#xD;
    unnecessary complexity for the rule writer. So we recommend to always try to use a view of the enterprise domain object&#xD;
    model. For example in Financial Industry the business domain&amp;nbsp;data model defined in MISMO (&lt;a&#xD;    
    href=&quot;http://www.mismo.org/&quot;    >&lt;font color=&quot;#005DA0&quot;>www.mismo.org&lt;/font>&lt;/a>), brings a lot of value for an enterprise&#xD;
    willing to define a common ontology for their data models. But exposing the MISMO model as it is within a BRMS rule&#xD;
    authoring IDE will put too much complexity. As the Architect is responsible to design decision service reusable cross&#xD;
    application, it may make sense to consider view of this object model in the context of the service.&lt;/span>&#xD;
&lt;/p>&#xD;
&lt;p class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0in&quot;>&#xD;
    &lt;span style=&quot;mso-bidi-language: HE&quot;>For the application the view can be defined in two entities:&lt;/span>&#xD;
&lt;/p>&#xD;
&lt;ul style=&quot;MARGIN-TOP: 0in&quot; type=&quot;disc&quot;>&#xD;
    &lt;li class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0in; mso-list: l0 level1 lfo1; tab-stops: list .5in&quot;>&#xD;
        &lt;span style=&quot;mso-bidi-language: HE&quot;>the Domain Object Model using java or xml schema as the underling&#xD;
        technology&lt;/span>&#xD;
    &lt;/li>&#xD;
    &lt;li class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0in; mso-list: l0 level1 lfo1; tab-stops: list .5in&quot;>&#xD;
        &lt;span style=&quot;mso-bidi-language: HE&quot;>or out of the box object view, like ILOG-Business Object Model element. The BOM&#xD;
        is mandatory to write rule on, but it&amp;nbsp;can be created from an existing java model or XSD or created&#xD;
        top-down.&lt;/span>&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0in&quot;>&#xD;
    &lt;span style=&quot;mso-bidi-language: HE&quot;>If the model does not exist in the application, or at the enterprise level we still&#xD;
    recommend to develop the domain model, using an UML designer and code generation tools.&lt;/span>&#xD;
&lt;/p>&lt;br class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0in&quot; />&#xD;
&lt;br />&#xD;
&lt;p class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0in&quot;>&#xD;
    &lt;span style=&quot;mso-bidi-font-weight: bold; mso-bidi-font-style: italic&quot;>It is also important to consider designing a java&#xD;
    model or XSD schema which is closed to the business concepts used by the rule but built as a view of the domain object&#xD;
    model (We called that the Rule Business Object Pattern or RBO): in the example of standard object model like MISMO or&#xD;
    ACORD, it makes sense to do not expose all the class definition, attributes and enumerated to avoid exposing a complex&#xD;
    rule language to the business user. This view will be instantiated by the application business logic in the context of&#xD;
    preparing the data for the rule services&lt;/span>&#xD;
&lt;/p>&lt;br class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0in&quot; />&#xD;
&lt;br />&#xD;
&lt;p class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0in&quot;>&#xD;
    When designing a Domain Object model one of the challenges is to determine what should be an entity and what should be&#xD;
    an attribute of the entity.&lt;span style=&quot;mso-spacerun: yes&quot;>&amp;nbsp;&lt;/span> This is why knowledge engineers like the&#xD;
    Enterprise Ontology as a start point for developing these concepts.&lt;span style=&quot;mso-spacerun: yes&quot;>&amp;nbsp;&lt;/span> The&#xD;
    Enterprise Ontology describes the major entities and concepts that apply to all enterprises and it provides a very good&#xD;
    starting point for the establishment of static object models and data models.&#xD;
&lt;/p>&#xD;
&lt;p class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0in&quot;>&#xD;
    The difference between a class and an entity type is that classes have both data and behaviors whereas entity types&#xD;
    just have data. A normal entity depicts one concept.&#xD;
&lt;/p>&#xD;
&lt;p class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0in&quot;>&#xD;
    Use multiple different UML class diagram to represent entities and their relations. Then enhance them to have a&#xD;
    complete class diagram from which you should be able to generate java code or XSD.&#xD;
&lt;/p>&lt;br class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0in&quot; />&#xD;
&lt;br />&#xD;
&lt;p class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0in&quot;>&#xD;
    Capture Meta data about each entity: business name, business definition, super type or subtype, number of occurrences,&#xD;
    primary key, and alternate keys.&#xD;
&lt;/p>&lt;br class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0in&quot; />&#xD;
&lt;br />&#xD;
&lt;p class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0in&quot;>&#xD;
    &lt;span style=&quot;mso-bidi-language: HE&quot;>It is possible to consider designing a Domain Model using Interface, and then apply&#xD;
    different type of implementation according to different execution pattern or platforms. For example we can design&#xD;
    a;&lt;/span>&#xD;
&lt;/p>&#xD;
&lt;ul style=&quot;MARGIN-TOP: 0in&quot; type=&quot;disc&quot;>&#xD;
    &lt;li class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0in; mso-list: l1 level1 lfo2; tab-stops: list .5in&quot;>&#xD;
        &lt;a id=&quot;1030902&quot; name=&quot;1030902&quot;>&lt;span style=&quot;mso-bidi-language: HE&quot;>Staged deployment with different execution&#xD;
        classes&lt;/span>&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0in; mso-list: l1 level1 lfo2; tab-stops: list .5in&quot;>&#xD;
        &lt;a id=&quot;1030906&quot; name=&quot;1030906&quot;>&lt;span style=&quot;mso-bidi-language: HE&quot;>Dynamic model (XML based or dynamic classes)&#xD;
        versus static model&lt;/span>&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li class=&quot;MsoNormal&quot; style=&quot;MARGIN: 3pt 0in; mso-list: l1 level1 lfo2; tab-stops: list .5in&quot;>&#xD;
        &lt;a id=&quot;1030907&quot; name=&quot;1030907&quot;>&lt;span style=&quot;mso-bidi-language: HE&quot;>Production/test models (active objects versus&#xD;
        mock objects)&lt;/span>&lt;/a>&#xD;
    &lt;/li>&#xD;
&lt;/ul>&lt;a id=&quot;XE_object_model__build&quot; name=&quot;XE_object_model__build&quot;>&lt;/a></mainDescription>
  <purpose>This&amp;nbsp;task focuses on the creation of the domain object model used by the rule engine.</purpose>
</org.eclipse.epf.uma:TaskDescription>