New York University

Computer Science Department

Courant Institute of Mathematical Sciences

 

Application Modeling Using XML

 

Course Title: Application Servers                                           Course Number: g22.3033-011

Instructor: Jean-Claude Franchitti                                            Session: 12

 

 

This document focuses on XML and application modeling. Most of the suggested approaches in this document are applicable to various programming or scripting languages for which XML tools are available. Examples of such languages are Java, C++, and Perl.

 

Application modeling technology has evolved over the years until the most prominently used methodologies in the industry merged into a single standard known as the Unified Modeling Language (UML). UML is the result of combined work by three modeling experts referred to as the “three amigos” (i.e., Grady Booch, Ivar Jacobson, and Jim Rumbaugh). UML standardizes modeling language and notation, not a particular method. UML has been adopted as an industry standard modeling language by the OMG. UML provides a set of notations to capture the representation of various application model views. As you will discover throughout the session, the XML family of technologies complements UML and provides a portable representation of application models that brings us a step forward towards model-based computing.

 

The latest XML technologies that relate to application modeling include the XML Metadata Interchange (XMI), which brings together XML, OMG’s Meta Object Facility (MOF), and UML. XMI provides a portable representation of application models that supports the interchange of modeling data between modeling tools. More than focusing on the relationship between XML and modern modeling approaches and technologies such as UML, this session also presents the relationship between XML and model-based computing. As modeling technologies becomes more and more powerful and able to capture represent a broad spectrum of application design aspects, the automated generation of complete application based on models is becoming possible. While traditional modeling technology did not capture implementation detail, and did not specify interoperability semantics, and information interchange formats, modern modeling technology based on XML strives to provide complete application definitions that include operational semantics, constraints, and information exchange formats. It is now clear that XML will play an important role in the next generation of Model Based Architectures (MDAs), which are currently championed via the OMG.

 

In a nutshell, this document covers the following subtopics:

 

·        Understand the "web object model" and its associated "binding" to Java

·           Understand SOAP

·        Understand UML based component modeling and related XML standards

·        Survey XML "model-based" computing applications

 

The first sub-topic presents the “web object model” vision as set forth in 1998 by OBJS, Inc. This vision should be compared to the current vision of web application architectures, including J2EE, CORBA 3, and Web Services. The (dated) vision should also be aligned with OMG’s Model Driven Architecture approach. An example of a SOAP application is briefly presented as part of the first sub-topic. The second sub-topic focuses on UML-based component modeling, and its relationship to XML standards. The section starts with a detailed practical overview of UML-based component modeling, and focuses on the most recent XML technologies used to support UML modeling. The last sub-topic takes a deep look at XML as a vehicle for supporting model-based computing applications, and upcoming generations of application server technologies that will be based on OMG’s MDA.


Sub-Topic 1 – The Web Object Model

 

Sub-Topic 1.1 – Web Object Model Overview

 

Students should refer to the paper by Frank Manola (OBJS, Inc.) at http://www.objs.com/OSA/wom.htm. The paper is a snapshot of a “web object model” vision that goes back to 1998. At that time, it was already established that what was needed to progress towards a “Web Object Model” was:

 

·        A representation language richer than HTML that could better represent “object state”. That new language was to tackle such aspects as the semantic identification of fields, and was to go beyond data presentation capabilities

·        An API that would enable access to object state, so that programs could readily access it

·        The ability to relate object state to pieces of code that would serve as object methods

 

The paper does a very good job at presenting examples that contribute ideas and technology toward providing the components of a Web object model compatible with the above observations. By analyzing the principles underlying the various ideas and technology, the paper actually suggested a first step towards a framework that would extend web applications to encompass the various requirements set forth earlier. You will find that the vision presented is not far from where we are today with modern application server technologies, XML, and Web Services.

 

Sub-Topic 1.2 – A Soap Example

 

The example below is an excerpt of the SOAP tutorial available at http://www.w3schools.com/soap. The example demonstrates the SOAP specification of a simple GetStockPrice request that is being sent to a server. The request has a StockName parameter, and a StockPrice is returned in the response. The SOAP Envelope element is the top element of the XML document representing the SOAP message. The namespace for the functions (m) is defined at an example (http://www.stock.org) address.

 

The SOAP request embedded in an HTTP Request is as follows:

 

<SOAP-ENV:Envelope>

  <SOAP-ENV:Body>

    <xmlns:m="http://www.stock.org/stock" />

    <m:GetStockPrice>

    <StockName>IBM</StockName>

    </m:GetStockPrice>

  </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

 

The SOAP response embedded in an HTTP Response is as follows:

 

<SOAP-ENV:Envelope>

  <SOAP-ENV:Body>

    <xmlns:m="http://www.stock.org/stock" />

    <m:GetStockPriceResponse>

    <Price>34.5</Price>

    </m:GetStockPriceResponse>

  </SOAP-ENV:Body>

</SOAP-ENV:Envelope>


For detailed practical examples of Web Services technologies involving WSDL, UDDI, and SOAP, students are referred to the August/September 2001 issue of XML Magazine (http://www.xmlmag.com).


Sub-Topic 2 – XML and UML Based Component Modeling

 

Sub-Topic 2.1 – Business Architecture Modeling

 

Business architecture modeling helps extract the overall business model of an organization, which includes the set of underlying processes necessary to operate the various functions of the organization. The business model includes the organization, location and process model as described below.

 

Organization model

The organization model provides role definitions and a process/role matrix. Role Definitions are groups of functional capabilities, which must be present in a single person in order for that person to carry out one or more specific business processes. A single person may perform more than one role. The process/role matrix indicates the business roles responsible for executing specific business processes. It is usually built at the Elementary Business Process (EBP) level but may also be completed at higher levels if useful.

 

As an example, the roles to consider in a typical financial instruments trading business model would be as follows.

 

1. Clients: Existing institutional customers presently managed by a salesperson. Clients have full trading privileges only in the instruments for which they are authorized.

 

2. Salespeople and Sales/Traders: Salespeople report to the sales desk manager. Salespeople are responsible for managing client’s needs with regard to a particular product / products or asset class. Salespeople and sales trading desks have trading privileges on behalf of a subset of clients, e.g. the clients covered by a particular sales person or that sales person’s group.  They interact with the various trading desks on behalf of clients in order to:

- Obtain quote requests

- Enter orders

- Discuss market commentaries

- Help resolve issues (trade detail inquiries)

- Change status of client orders

Salespeople also help customers understand research and suggest trade ideas.

           

3. Execution Desk (Traders): Traders report to a trading desk manager. Traders are responsible for making markets in a particular product / products, within an asset class. They also manage the risk associated with a particular trading book/s. Traders are a special type of client (internal clients).  Like clients, they have full trading privileges only in the instruments for which they are authorized. Some trading responsibilities include:

- Provide prices being published to clients

- Provide pricing for quote requests

- Approve / reject / counter-offer orders sent to the trading desk by clients

- Determine axis to be offered to clients

- Offer a market commentary

 

           

4. Support – Back-Office Operations: Often referred to as “back-office personnel, support people ensure the timely processing, settlement and delivery of transactions among other things. Support has access to all windows accessible to clients.  They have no trading privileges but they can modify the status of an order on behalf of a client. Support people staff the following areas:

- Trades processing

- Settlements

- Margin

- Stock loan

- Sales Support

- Others

Assumption: There may need to be a distinction made between back-office and front-office personnel’s functionality.  Support – Front-Office Operations: Typically work along-side Traders and Salespeople. They facilitate telephone calls, process trades and resolve trading and sales/customer issues. Front–Office  personnel would consist of:

- Assistant traders

- Assistant salespeople

 

5. Client Mid-Office: These would be the client’s support staff.

 

6. Administrators: Administrators do not have trading privileges.  Administrators alone have access to administrator windows. Administrators would provide the following support:

- Account set-up

- Account maintenance

- Modify client access

- Modify client trading privileges

 

7. Client Administrators: Administrators do not have trading privileges.  Administrators alone have access to administrator windows. Client administrators can only to modify account holder privileges, within the limits of that client’s trading and access privilege.

 

8. Marketing Desk: Provide marketing support to salespeople.

Interact with traders on behalf of regional salesforce, performing similar functions as a salesperson would. However, they may  have limited client contact.

- Assist in educating the salesforce with regard to financial products.

-         Apprise the salesforce of new issues and other market related information received by the trading

desks and other sources

Assumption: There exist such a desk performing the above listed duties..

 

9. Trading Desk Managers: Supervise traders on individual trading desks. Responsible for the overall profitability of their trading desk.

 

10. Sales Desk Managers: Supervise salespeople on individual salesdesks. Responsible for the overall profitability of their sales desk.

 

11. Upper Management: Key managers that oversee several business units, operations departments and other areas. These would include:

- Division Managers

- Group Managers

- Risk managers

 Assumption: CIO, CFO and CEO level of management may want certain functionality.

 

12. Systems Management: Key technical people responsible for the daily operation of the trading system, including:

- Site Manager

- Systems Maintenance Manager

- Content Manager

- Help Desk

- Others

 

Location Model

The Conceptual Location Model shows how business processes will be distributed geographically. In the location model, location type definitions identify locations in terms of location type and general geographical area. A process/location matrix is also provided to indicate location types at which each process is performed. This matrix is used at the level of elementary business processes (EBPs). In our sample trading business model the location type definitions could be:

·        Boston branch sales office

·        Midwest district service center

·        London regional distribution center

·        New York Headquarters

·        Singapore Headquarters

·        London Headquarters

·        U.S. Sales Offices

·        Asian Sales Offices

·        European Sales Offices

·        Other Sales Offices

·        Clients

·        Inter-Dealer Broker Locations

·        Electronic Communication Networks (ECN’s)

 

Process Model

The business process model can be summarized in business process hierarchies. A  business process hierarchy is a schematic representation of the results of process decomposition. Decomposition is taken down to the level of the elementary business process (EBP).  An EBP is the smallest unit of business activity that:

 

·          is worth examining;

·          is performed by or in support of a single user;

·          may include both manual and automated activities;

·          has user involvement occur at one time;

·          preserves important business distinctions between processes;

·          leaves the Conceptual Entity Model in a consistent state.

 

Business process flow can be captured within a process map. Business process maps show the sequence of selected processes from the Process Hierarchies as they relate to the role that performs them.

 

A high-level business process hierarchy for our sample trading business model is given below:
Trading Business Process Hierarchy

 

 



EBPs can be further decomposed in sub-hierarchies as illustrated below in the case of the Enter Order process of our sample trading business model:

 


Enter Order Business Process 


 

 


 


EBP definitions contain a brief description of what occurs in each process. The definitions, combined with the relevant process flows, provide the basis to move forward into detailed design and support continued development of functional specifications.  They also identify any assumptions made during the creation of the architecture, any rules for manual decisions that need to be made, and cross reference information, where applicable, to match the functional requirements of the application being designed.

The numbering of the EBPs corresponds to the layout on the hierarchies, and is used to cross-reference all of the other work products in the Business, Organization, and Location domains.

 

In the case of our sample trading business model, EBP definitions are as follows:

 

1.      Subscribe Prices

1.1 Receive Prices.  Receive the updated prices from all pricing sources. Show the relevant information required to identify an instrument (e.g. ticker symbol, coupon, maturity, price, yield for bonds). This needs to be as robust and frequent as the Reuters update.  Manage instruments (add, change, delete) through backend systems.

1.2 Create Market Windows

1.2.1 Configure Market Windows.   Set up screens and layout of windows and workspace.  

2.1.2 Enter Search Criteria.  Locate instrument/groups/portfolios for windows.   Will need a request to publish if user is the first one to request this instrument’s price feed.  Check Price Subscription Entitlements.

1.2.2 Select Instrument for Market Windows.  Select and delete instrument/group/portfolios to be represented on the Market Watch window.

1.2.3 Populate Market Windows.  Populate market watch view to show prices to users for their selected instruments. Create market depth view of an instrument. Accessed after selecting an instrument (description) from the market watch window. Allows users to view price sources for a given instrument from multiple sources.

 

2.0 Process Order

2.1 Quote Request. Look up instrument via search functionality starting at asset class, checking view permissions.  Select instrument to move into order/quote request process.  Client uses to access price not generally available or not on their Market Watch (in which case, user could just search, add instrument to their Market Watch.

2.1.1 Select Quote Request Function.  Select a Request for Quote (RFQ) button, menu item, or Market Watch window.

2.1.2 Enter Search Criteria.  Fill in as much info as possible for the search window to narrow the possible options: instrument, group, and portfolio.  Selected results may be added to Market Watch.  Check entitlements for viewing.

2.1.3 Select Instrument to Populate Ticket.  Check trading entitlements. Opportunity to go back to search criteria and get another instrument/group/portfolio to add to ticket.

2.1.4 Review Ticket (RFQ, Order). View pre-populated RFQ or Order Ticket. Default fields are filled in based on Ticket type and asset class.

 

2.1.5 Enter Additional Information on Ticket (RFQ, Order).  Enter quantity, and provide capability to override default settlement and other fields. Enter order types - Fill or Kill, GTC, Day Order.  Enter account number. User has option to enter an order status change such as suspend order. User has option here to cancel or return to select another instrument (e.g. clicked on wrong market price or instrument or wants to add more.)

2.1.6 Submit Ticket (RFQ, Order). Submit RFQ or Order to Trading Desk. If Execution Desk does not respond to RFQ in 30 seconds.

·        Validate ticket and/or entitlement Details – Make sure all relevant information has been entered on the ticket. User can edit and cancel. If info is missing or incorrect, send error message.

·        Send ticket. Send acknowledgement to audit trail or user. Order state = ‘waiting’

·        Route ticket to specific back-end system – The order will be routed to the appropriate back-end system for the given instrument based on order routing criteria.

·        Send acknowledgement – An acknowledgement will be sent once the order has been received by the back-end systems.

 2.1.7. Fill RFQ . Trader provides price, and any other required information, such as quantity, settlement for Quote Request and sends back to User.

2.2 Enter Order

2.2.1 Enter Order From Menu.  Presumes price is missing and user must populate this in the Order Ticket.

2.2.1.1. Select Enter Order Function.  Access menu item.

See EBPs 2.1.2. through 2.1.6.

2.2.2 Enter Order from Market Windows

 

2.2.2.1 Select Instrument from Market Watch. Choose the instrument for which an order is to be entered.   This should open the Market Depth window and display multiple prices, and price sources.

2.2.2.2 Select Price of Instrument.  Click on the desired price. If the offer price is selected, a buy order ticket will be displayed. Should the bid price be selected, a sell order ticket will appear.

See EBPs 2.1.4. through 2.1.6

2.2.3 Respond to filled RFQ

2.2.3.1 Select RFQ.  Select from Order queue or from asynchronous pop-up window? Client can retrieve RFQ’s sent to the Execution Desk in order to cancel or modify the order.  User has 5 seconds to respond once RFQ is received back with price.  If time limit ends up being more than 5 seconds, may want to have Order queue functionality.

See EBP 2.1.4

2.2.3.2 Transform RFQ into Order.  Continue order with information received back from Trading Desk within the specified time limit. If RFQ times out, user can still resubmit as order, but cannot expect it to be filled at that price.

See EBP 2.1.6

2.3 Execute Trade

2.3.1 Review Client Order Ticket.  Trader reviews information on order ticket received from Client. Trader will decide if and how he will fill this order ticket.  Order status changes to ‘confirm’ to note that Execution Desk has received it, and order queue reflects this.

2.3.2 Fill Order. Trading Desk person accepts or denies order.   This part is manual.  To provide process speed, parts of this should be automated based on some criteria (e.g. price limits, quantity limits). If order is approved, update order status (approved) and send return message that order is approved.  If order is denied, updates order status (denied) and return message with denial, alternate price and/or quantities (can’t fill).  Provide Alternate Price and/or Quantities.

2.3.2.1. Completely Fill Order.  The user is notified by the status update of their order on their order queue that their order has been filled.

2.3.2.2 Partially Fill Order.   System will send updates to order until completely filled or balance rejected/cancelled.  User may change or cancel the unfilled portion of the order.

2.3.3 Confirm Fills.  After receiving acknowledgement that order was filled, user will confirm fill.

2.4 Change/Cancel RFQ, Order.   Change, Cancel, Change status (suspend).  Depending on instrument type, user may need to cancel and add and order instead of change.  Based on SEC regulations.  Change and cancel orders may only be done if current Order State is ‘pending’.

2.4.1 Select Order from Order Blotter.  Status must be pending or partially filled

See EBP 2.2.3.1 and 2.1.4

2.4.2. Cancel

2.4.2.1 Cancel Order.  Cancel directly in order blotter or optionally review ticket then cancel from ticket itself.

2.4.2.2 Cancel RFQ

2.4.3 Modify Information on Ticket (RFQ, Order).  Change information on previously submitted ticket

See EBP 2.1.6

2.5 Process Unfilled Orders

2.5.1 Reject Order.  A message will be sent to the user that their order cannot be filled.  User may change order.

2.5.2 Terminate Order, End of Day.  At the end of the business day, users will be advised that all day orders that have not been filled are considered dead. Order will have an ‘expired’ status. If the user wishes to re-enter their order, they may do so, on the next business day.

 

3.0 Perform Management Functions

3.1 Set up Entitlements & Security 

3.1.1 Provide Client Security Access

3.1.2 Determine Entitlements. Based on view and business functions allowed to do, role, asset class , account.

3.1.3 Administer Entitlements. Set up user on system, which drives their views and allows them to perform functions.

3.2 Provide Management Reporting.  Periodic reporting, reconcile trades at end of day.

3.3 Perform Queries.  Ad hoc or static on line queries. For trading/sales managers to get an overview of the business being done.

3.4 Manage Content.  User news and other ‘push’ information, personalization.

3.5 Manage Site

3.6 Configure User Preferences.  Provide user set up functionality to configure content and layout of views such as market watch and depth, Order queue and trade history. Access to data is based on user entitlements.

3.7 Maintain Accounts, Customers and Instruments.  Add, change, and delete.

 

4.0  Maintain Systems

4.1 Perform Backup and Recovery

4.2 Monitor Systems. Monitor routing and workflow, audit trail.

4.3 Do Performance Tuning

4.4 Perform System Administration.  Archiving to support deletion of data and maintenance of databases.

4.5 Provide Help Desk.  Customer Support such as hot line, problems, issues, etc.

 

Process Map Diagrams show the sequence of selected processes from the Process Hierarchies as they relate to the role that performs them. Only significant processes of special business interest appear in the following Process Maps. While any process appearing on a Process Map should also appear on the Business Process Hierarchy, the reverse is not true. Process Flow Diagrams may show:

·        Business events that initiate a process

·        Business results from completing a process

·        Processes

·        Process flow, also called process sequence

·        Process flow breaks

·        Iteration, optionality, and exclusivity

·        Supporting comments.

 

In the case of our sample trading business model, a process map diagram for the Enter Order is as follows:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 


Sub-Topic 2.2 – Process Design and Process Decomposition

While process design and decomposition was illustrated in the previous section, this sub-topic focuses on the interrelationship of the Elementary Business Processes to the Derived Logical Processes (DLPs) that link the business processes to a new software application.  DLPs are not considered a further decomposition of the Business Process Hierarchy.

An Elementary Business Process is a unit of business activity, executable by one person at one time and in one place.  They are depicted as elementary steps/tasks in the Process Hierarchies.  The EBP’s that support the user requirements, combined with EBP’s that support the general and system management processes, comprise a majority of the Functional Specifications.

Derived logical processes (DLPs) describe what the computer system will do to automate a business process. DLPs provide shorthand for enumerating required system capabilities.  In the Development Phase,  specifications will be written to describe the DLP in enough detail for it to be developed.

 

An EBP/DLP matrix is usually developed concurrently with the Logical Process Hierarchy to connect the systems to the business by mapping the derived logical processes to the elementary business processes they support or automate. One EBP may use several DLPs, and several EBPs may reuse one DLP.  This supports validation linking from Architecture Phase user requirements to Development Phase functional specifications and design specifications. A sample EBP/DLP matrix for our trading business model is shown below:

 

 

EBP no.

EBP name

DLP name

Implementation

1.

Subscribe Prices

 

 

1.1

Receive Prices

Add price

Change price

 

1.2

Create Market Windows

 

 

1.2.1

Configure Market Windows

Add Workspace

Change Workspace

Delete Workspace

Save Workspace

Add Window

Change Window

Delete Window

Save Window?

 

2.1.3

Enter Search Criteria

Find instrument

Check entitlements

 

1.2.2

Select Instruments for Market Windows

Add price subscription

Delete price subscription

Find price

Find User Preferences

 

 

 

 


Sub-Topic 2.3 – Business Model Execution Engines

 

The ideal software development environment would be one where the business model could be provided as an input to a “business model execution engine” that would take care of converting the business model into an executable software application. In that process, the execution engine would select the best combination of frameworks and reusable components based on the requirements set forth by the business model. The environment could also provide business model engineering tools that would semi-automate the process of gathering business requirements via a graphical user interface. The business requirements would then be compiled into a business model that could be provided as an input to our hypothetical “business model execution engine”. Although the current state of software environments is not as advanced, today’s technology is clearly moving in that direction. Today’s data modeling CASE tools automate the generation of logical database design from a conceptual database design. The proposed environment would be an extension of the capabilities provided in these case tools, where the tool would be able to encompass other models than the data model such as the process, event, and persistence models. Technology has clearly made a step in that direction with the advent of Enterprise Java Beans (EJB) application servers, which can automate the management of messaging, transaction, persistence and so on. Some tools (such as the mapping tools provided by Persistence Software Inc.) are dedicated to the generation of object-relational mappings. Clearly, the level of automation provided in today’s technology is still limited.

 

Sub-Topic 2.4 – Frameworks and Reusable Components

 

Most of today’s application architectures are being modeled using Object Oriented Analysis and Design techniques. The architecture object model is comprised of sub-models focused on the application, application infrastructure, and technology infrastructure. The application architecture object model combines information from the business model, data model, and content model. The business model includes the organization, location, and process models. The organization model captures the functional roles of the different types of business users. The location model identifies how business processes will be distributed geographically. The process model sets forth a set of business rules tailored to the application’s functional requirements. The data model formalizes the application’s underlying business entities and their inter-relationships. The content model focuses on the interface of the application, and encompasses navigation, presentation, and the underlying publishing mechanisms. The content model closely follows the look and feel and navigation guidelines imposed by the corporation implementing the application. The architecture object model for the application infrastructure is subsumed in a layered framework (i.e., an assembly of design patterns) that drives the grouping of application components into logical packages that provide added operational functionality. These logical packages enable the mapping of the application components onto the application infrastructure. The design of the application infrastructure framework is influenced by the business constraints imposed on the overall system design. Finally, the technology infrastructure model is subsumed in one or more instances of physical architectures that map the aforementioned logical packages onto the underlying hardware and operating system platform. The technology infrastructure model takes into account the company’s operating standards and constraints. The physical architectures implement the technology infrastructure model and satisfy the operational requirements of the application, and application infrastructure implementations. Altogether, the application, application infrastructure, and technology infrastructure models capture the preliminary analysis and design information required to move on to detailed design, and implementation of the first release of the application.

 

As mentioned in the above, the resulting system is architected in three layers as depicted in Figure 2.1. The top layer hosts the application suite, which implements the various business functions.  The middle layer hosts the application infrastructure, which provides operational support for the application suite. Finally, the bottom layer hosts the technology infrastructure, which includes hardware and operating system software. The architecture offers a global vision of the application. It describes the strategic capability choices that determine the application’s overall software quality from a business and technical standpoint. The application's software "quality" results from meeting specific business and technical constraints. Business constraints include the support for business specific requirements (e.g., guaranteed delivery of order and order status messages in our sample trading business model). Technical constraints include accuracy, correctness, performance/latency, scalability, extensibility / adaptability, continuity / availability / reliability / robustness, security, testability, and usability. These capability choices, which provide a measure of the application's overall software quality, directly result from an attempt at fulfilling business and technical requirements. Such requirements are usually collected by various workstreams during the vision and strategy phase. At that stage, typical workstreams focus on customer facing interviews, competitive analysis, and a detailed analysis of current state technology and business processes. It is important to note that the assessment of an application’s required architectural capabilities is currently based on a limited set of requirements. Other design factors that will drive the implementation of a good application architecture are simplicity, elegance, intelligibility, well-defined levels of abstraction, and a clear separation between the interface and the implementation of each level.

 

 

 

 

 

 

 

 


 


Figure 2.1 The Three-Layer Architecture

 

Within the context of object-oriented analysis and design, modeling is often used as a synonym of analysis and it decomposes systems into collaborating objects. The Unified Modeling Language (UML) defines several models for representing systems: the class, state, use case, interaction, implementation, and deployment models. The class model captures the static structure. The state model expresses the dynamic behavior of objects. The use case model describes the requirements of the user. The interaction model represents the scenarios and messages flows. The implementation model shows the work units. The deployment model provides details that pertain to process allocation. Models are browsed and manipulated by users by means of graphical representations, which are projections of the elements contained in one or more models. Many different perspectives can be constructed for a base model - each can show all or part of the model, and each has one or more corresponding diagram. UML defines nine different types of diagrams: class, sequence, collaboration, object, statechart, activity, use case, component, and deployment diagrams. Class diagrams represent the static structure in terms of classes and relationships as model elements. Sequence diagrams are a temporal representation of objects and their interactions; they involve actors, objects, and messages. Collaboration diagrams are a spatial representation of actors, objects, links, and messages. Object diagrams represent objects and their relationships, and correspond to simplified collaboration diagrams that do not represent message broadcasts; they use classes, objects, and links. Statechart diagrams represent the behavior of a class in terms of states and transitions. Activity diagrams represent the behavior of an operation as a set of activities; they involve transitions, and actors. Use case diagrams represent the functions of a system from the user's point of view; they rely on actors, and use cases. Component diagrams represent the physical components of an application, and deployment diagrams use nodes and links to represent the deployment of components on particular pieces of hardware.

 

From an architecture standpoint, putting a well-adapted architecture in place is the key to successful development. Software architecture are often characterized using the following formula:

 

Software Architecture = Elements + Patterns + Motivations

 

In this equation, elements correspond to UML model elements such as classes, and objects. Patterns refer to recurring combinations of objects and classes. Patterns can be grouped in larger representations called frameworks. Frameworks are truly reusable infrastructures dedicated to the implementation of targeted applications. In the case of our sample trading application, we could envision an application infrastructure web framework to support the various application layers. Finally, the "Motivations" variable set forth in the above equation correspond to the driving forces behind the architecture implementation. In the case of our sample trading application, we would identify a set of business, and technical constraints on the application as well as a set of guidelines for designing a "good" application architecture.

 

As an architecture is being designed, there is more than one way to represent a system. Multiple perspectives are required. Moreover, in order to satisfy many parties, each UML diagram type only gives a partial image of a system. As a result, the architectural model, which describes the architectural vision, must be well adapted to the representation of various constraints that the architect must take into account. A possible architectural model is the "4 + 1 view model", which relies on a combination of logical, implementation, process, deployment, and use case views as illustrated in Figure 2.2. The logical view describes the static and dynamic aspects of the system in terms of classes and objects. It involves a combination of class, object, sequence, collaboration, statechart, and activity diagrams. The implementation view relies on component diagrams, and is concerned with the organization of modules within the development environment. The process view represents the decomposition, in terms of execution flows (processes, threads, tasks, etc.), the synchronization between flows, and the allocation of objects and classes within the various flows. It relies on sequence, collaboration, statechart, activity, and component diagrams. The deployment view describes the various hardware resources and deployment of software within these resources. The deployment view uses component and deployment diagrams. Finally, the use case view constitutes the glue that unifies the four previous views. Use cases motivate and justify the architectural choices. They facilitate the identification of critical interfaces, they force designers to focus on the concrete problems, and they demonstrate and validate the other architectural views. The use case view involves use case, object, sequence, collaboration, statechart, and activity diagrams.

 


 


Figure 2.2 The "4 + 1" Architectural View Model

 

Sub-topic 1.4 fully illustrates our sample trading application architecture. The documentation is limited to the "core" functionality, which excludes the details of the presentation layer. The proposed application architecture documentation includes:

 

·        A textual description of the features of the architecture (i.e., the views) and the key system requirements.

·        The compromises reached and the alternatives explored.

·        A high-level representation of the logical view.

·        Scenarios specific to the architecture.

·        Description of key mechanisms.

 

As the actual sample trading application is too complex to be understood, designed or implemented in one shot, it is better to implement it iteratively. Each iteration can focus on functionality increments. The object-oriented approach provides a comfortable framework to develop in an evolutionary fashion  using such an iterative approach. We therefore suggest an iterative and incremental project lifecycle for our sample trading application, and we will use UML to model the system as it provides a comprehensive notation for the full lifecycle of object-oriented development.

 

Sub-Topic 2.5 – Process/Entity Matrix

 

Meshing business processes and data entities can be done in various ways. When using the object model approach (i.e., UML, or EER data model), business processes can be represented as the methods of classes, which are used to represent the typical entities. If the data model of the language used to implement the conceptual database design is not as expressive as an object model (e.g., E-R data model), it may be necessary to use process/entity matrices to associate relevant business processes to the entities they act upon. A simple alternative to a process/entity matrix is that of a Logical Process Hierarchy. A Logical Process Hierarchy is a structure for organizing DLPs using object-based principles.  It starts with the Logical Entity Model and identifies business objects to correspond to the major data entities.  Each DLP/object that is used by an EBP, is noted here. The Logical Process Hierarchy is used as a reference tool to identify development components and to promote reusability.

 

A Logical Process Hierarchy for our sample trading application is illustrated below:

 

Sub-Topic 2.6 – Conceptual Database Design

 

This section illustrates the database design steps for our sample trading application. It first shows how to derive a logical data model from a traditional E-R data model. It then relates the mapping of the resulting logical data model to the object model of the overall trading application.

 

Logical Data Model for the Sample Trading Application

 

This logical data model has been constructed based on data requirements derived from sample functional requirements.  The mapping of entities to the functional requirements that they support is listed as part of the data dictionary.  Where possible, the model has been validated by business people from the appropriate subject areas, but as requirements are still being defined, some areas will need revision as these requirements are completed.  It is also important to note that the primary intent of this model is to present the logical entities and their relationships.  The attributes listed as belonging to these entities are just samples of what may be required and will have to be modified and expanded upon as business requirements are completed.

 

The logical data model is broken up into five subject areas based on the functions the entities contained in each support.  These subject areas are:  Orders and Quote Requests, Price Subscriptions, User Preferences, Privileges, and Instruments.  A description of the purpose of each subject area follows, and a definition of each entity can be found in the data dictionary.  Entities that appear in gray are not required for phase one.

 

The Entity-Relationship (ER) diagrams for the five subject areas, and the associated data dictionary are illustrated below:

 

Orders and Quote Requests

 

The model below supports both quote requests and orders.  Quote requests will contain most of the same information as an order, so logically they can be stored within the same entity.  Since an order or quote request can consist of orders/requests for multiple instruments, two entities are used to represent this.  The order entity links all of the individual lines together and describes their dependencies, while the order line consists of all of the details needed for an order or quote request for a single instrument.  The execution entity contains the results of a trade whether that is a fill or partial fill, while the quote entity contains responses to price requests.  Each change in the status of an order or quote request, including rejections and cancellations, is maintained in the order status entity.

 


 
Price Subscription

A user can define price subscriptions in two ways.  An individual instrument can be assigned to a market window, or a group of instruments may be assigned.  These groups or lists can be user defined and do not imply that the instruments have anything in common; rather, it allows the instruments to be more easily manipulated as a group.  The assignment of instruments to windows defines a subscription.  Included in gray are some entities that will support parametric prices in a later phase.  These entities allow for the fact that there can be many prices for an instrument if different conditions or parameters are applied, such as conditions for delivery or settlement.  Entitlements to view prices are controlled through their assignment to price groups and price tiers. 


User Preferences

This model defines four sets of user preferences.  The first, through the user entity, identifies the user and specifies a collection of default settings that apply throughout the trading application.  The next is the set of default settings that depends on the asset class that the user is working with.  The default order parameters entity allows the user to specify default values that will be used unless overridden when placing an order or making a quote request.  Finally, there are the entities that represent the configuration of the user’s work area.  A user can create multiple workspaces, each containing a set of windows (order queue market watch, market depth).  Each of these windows can in turn be configured to display a selected set of columns and their positions, sort orders, and filters.         


Privileges

The proposed data model would need revision as business requirements in this area become better defined.  There are three main groups of privileges:  price entitlements, trading permissions, and administrative privileges.  In this model, all three groups are represented through the privileges entity.  This entity associates an action, such as ‘place order’, with a target object, such as ‘product X’.  Access will be controlled to objects such as price tiers, price groups, order books, accounts, and products.  These privileges can be assigned directly to a user, or can be assigned first to roles for easier administration.  Users can then be assigned to these roles.  In addition there is a set of roles and privileges that are associated with a client (firm).  Client users must then be assigned a subset of the privileges and roles available to the client.  It is also possible that where a client is a subsidiary of another client, the subsidiary can inherit the privileges of its parent.  Alternately, it can be given its own set of privileges.

 

 



Instruments

The instrument model is needed to support searching for instruments as well as for identifying an instrument to a back end system in an order. This model will need to evolve as new  requirements are being added. A couple of different instrument groupings are represented here.  The first is through product and asset class.  These are used in determining defaults and for controlling access within the application.  They also support classifying and searching for instruments.  The other grouping method allows a hierarchy of groups that can be defined either by the company developing the trading application or by the users themselves.  These custom groups are not used to classify instruments or imply any similarities between instruments in the group; rather, they are used to allow users to easy find and manipulate commonly used sets of instruments.  A structure also exists for representing multiple identifiers by which an instrument may be known.


                 

 

 


Data Principles for the Sample Trading Application

 

·        All data that needs to be persisted will be stored within a database.

·        The logical model needs to conform to naming and abbreviation conventions.

·        The application needs to maintain audit logs for auditing, reporting, and recovery purposes.

·        All persistent data must be backed up regularly.

·        Lost sessions and failed messages can be reconstructed from persistent data.

·        Access to data within the application will be controlled according to the company’s security standards for data stores.

Data Assumptions for the Sample Trading Application

 

·        Database replication:

ü               For locations that handle same client base, databases may need to be shared and or synchronized.

ü               Databases for servers that are in different countries will not replicate each other’s data.

·        The back end system is responsible for mapping a trading account to an account within the back end system.

·        The trading application will receive instrument data from back end systems and maintain a version locally.

·        Backends will maintain client credit data.

·        The following estimations are given:



Item

Quantity

Update Rate

Users

10K

100/day

Accounts

5K

10/day

Firms

5K

10/day

Entitlements

500K

5K/day

Price requests

50K/day

2/second

Orders

20K/day

1/second

Peak Hour

15% of daily global volume

 

Avg. price subscriptions/user

30

 

Price update rate

 

1/second/product

Total price update rate

 

300K/sec

 

Price update size

50 bytes = ~500 bits (no compression)

 

Total price update data volume

 

150 Mbits/second

 

Client distribution:  North America 40%, Europe 40%, Asia 20%

 

Constraints for the Sample Trading Application

 

·        Due to the high volume up price updates, price data will need to be stored in an in-memory database.

·        Similarly, the high number of references to entitlements means that a copy of these entitlements needs to be stored in an in-memory database, while a permanent copy is persisted in a relational database.

·        If Tibco products are used, we may need to use a Sybase database as DB2 is not fully supported.

·        The system must be fault tolerant.

·        Currently, some business requirements are still being developed.  As a result, data requirement in the following areas are incomplete:

·        Entitlements

·        Instruments

·        Attribute level information for most entities, including orders, price requests, executions, and quotes.

 

Sub-Topic 2.7 – Object Model for the Sample Trading Application

 

As mentioned earlier, the architectural model chosen for the sample trading application is the "4 + 1 view model", which relies on a combination of logical, implementation, process, deployment, and use case views. The logical, use case and process views are handled as part of the application modeling phase. The implementation view is addressed as part of the application infrastructure modeling phase, and the deployment view is addressed as part of the technology infrastructure modeling phase.

 

Use Case View

 

The use case view constitutes the glue that unifies the logical, process, implementation, and deployment views. Use cases motivate and justify the architectural choices. The process model and associated process maps described earlier give a conceptual representation of the use case view of the sample trading application object model. In the UML notation, the use case view involves use case, object, sequence, collaboration, statechart, and activity diagrams. These diagrams should be developed incrementally as needed as part of the detailed design.

 

Logical View

 

The logical view describes the static and dynamic aspects of the system in terms of classes and objects. The logical view overlaps the class and state models, as the class model is focused on the static structure, and the state model focuses on the dynamic behavior of objects. In the UML notation, the logical view involves a combination of class, object, sequence, collaboration, statechart, and activity diagrams.

 

The UML notation supports model elements and visual elements (a.k.a., diagram). The visual elements provide textual or graphical projections that facilitate the manipulation and representation of model elements. Classes and objects are examples of common model elements used to represent abstractions of a system being modeled. Packages are common model elements that provide a general mechanism for partitioning models and grouping model elements. The sample trading application architecture can be expressed as a hierarchy of inter-dependent packages. The package hierarchy is follows:

 

Enterprise Applications Suite

Channels

Web Portal

Web Interface

Web View

Web Controller

Enterprise Services

Trading Enterprise Services

Business Controller

Client Interface

Client Handler

Component Manager

Business Object Model

Infrastructure

Services

Common Facilities

Domain Specific Facilities

 

The following class diagram illustrates some of the classes would populate the above packages. More diagrams would need to be developed incrementally as part of the detailed design.

 

Business Object Model

 

 

Component Manager Package

Process View

 

The process view details execution flows (processes, threads, tasks, etc.), synchronization between flows, and allocation of objects and classes within the various flows. The process view overlaps the state model and the interaction model, as the state model focuses on the dynamic behavior of objects, and the interaction model focuses on scenarios and message flows. The process model and associated process maps described earlier give a very high-level conceptual representation of process view of the sample trading application object model. In the UML notation, the process view relies on sequence, collaboration, statechart, activity, and component diagrams. These diagrams should be developed incrementally as needed as part of the detailed design, which would take place early on in the detailed design phase. The detailed design phase would also focus on the specification of events, exits, errors, and detailed sequence diagrams including preconditions, triggers, and responses. At this stage of the analysis and design phase, we would focused on the interaction model and would develop a high-level message specification, and a preliminary message hierarchy. We would also put together a conceptual representation of message flows within the system. Additional work products would need to be developed incrementally as part of the detailed design phase.

Application Model Implementation View

 

The implementation view is concerned with the organization of modules within the development environment. In the UML notation, the implementation view relies on component diagrams. These diagrams will be developed as part of the detailed design. At this stage of the Analysis and Design Phase, a Logical Architecture Diagram would be provided. It would act as a conceptual illustration of the implementation view that would serve as a starting point for the detailed design of the architecture implementation view. The diagram would illustrates the proposed logical components of the sample trading  application, and their mapping to an application framework that would meet the business and technical constraints imposed on the overall application design.

 

Deployment View

 

The deployment view describes the various hardware resources and deployment of software within these resources. In the UML notation, the deployment view uses component and deployment diagrams. These diagrams would be developed as part of the detailed design. A Physical Architecture Diagram would provide a conceptual illustration of the deployment view that would act a starting point for the detailed design of the  architecture deployment view.

 

Sub-Topic 2.8 – XML Support for UML Modeling

 

OMG is championing a Model Driven Architecture (MDA) that relies on the use of generic tools to generate platform-specific software components from platform independent metamodels. To support its MDA, OMG has adopted several metadata standards including the Meta Object Facility (MOF, http://cgi.omg.org/cgi-bin/doc?ad/99-09-05) and XML Metadata Interchange (XMI, http://cgi.omg.org/cgi-bin/doc?ad/9910-02, http://cgi.omg.org/cgi-bin/doc?ad/99-10-03, and www.oasis-open.org/cover/xml.html). XMI integrates XML with MOF and UML.  The MOF is the meta-metamodel that can be used to describe the whole software development architecture as well as the MOF  itself. Additionally, the MOF contains a set of rules that specify the interoperability semantics and information interchange format for any of its metamodels. Among these rules, the MOF to IDL (Interface Definition Language) transformation rules can be applied to any metamodel to produce a well-defined API. This API can be used to manipulate instance data corresponding to the respective metamodel. This API also provides introspection (a.k.a. reflection) - the ability to discover information contained in the respective metamodel. In addition to the API, the MOF rules also define the DTD corresponding to the metamodel. Any instance data of a metamodel can be represented by an XML Metadata Interchange (XMI) stream that conforms to the corresponding DTD. This results in the MDA development approach suggested in Figure 2.3 below:


 

 


Figure 2.3 MDA Development Approach

 

The MOF Core is a subset of UML (http://cgi.omg.org/cgi-bin/doc?ad/99-06-08)  that is sufficient to model metadata (i.e., classes, associations, subtyping, etc.). Normative Java interfaces to the MOF are being defined as part of JSR-40 - the Java Community Process (JCP) Metadata API Specification.

 

To use the MDA paradigm, you would first describe a software system using a MOF-compliant modeling language such as UML. You would then refine the resulting design other models that further describe implementation and runtime semantics. The aforementioned MOF rules would then be applied to the initial model to define interoperability semantics and interchange format. Based on this paradigm, the MDA architecture provides a framework that supports the full description of software systems.

 

To illustrate the use of MOF, you can consider the very simple MOF model of a relational database illustrated in Figure 2.4 below. In that example, the metadata corresponds to the table, and column constructs that make up a relational database. Note that the  Table and Column constructs set forth as the basic constructs of the relational database model may in turn be used to specify an actual database schema.


 


Figure 2.4 A MOF Metamodel Expressing a Simplified Relational Database Model

 

The corresponding MOF Core elements used to describe the relational database model are MOF::Class and MOF::Association as shown in Figure 2.5.

 


 

 


Figure 2.5 MOF Elements Used to Express the Relational Database Metamodel

 

The MOF core is technology neutral, and any of the MOF Core’s constructs may be mapped to CORBA IDL, Java, XML, or any other technology. In fact OMG has adopted the XML Metadata Interchange standard to encompass the rules for generating an XML DTD from a MOF metamodel. Figure 2.6 below illustrates further how instances of MOF::Class and MOF::Associations would be mapped to DTD elements in a typical MOF to XML mapping.

 


 Figure 2.6 MOF to XML Mapping

 


The following is a listing of a corresponding simplified XMI DTD generated using the IBM's AlphaWorks XMI Toolkit (http://www.alphaworks.ibm.com/tech/xmitoolkit ).

 

<!ELEMENT Table.column (Column)* >
<!ELEMENT Table.name (#PCDATA | XMI.reference)* >
<!ELEMENT Table (Table.name?, XMI.extension*, Table.column*)? >
<!ATTLIST Table
%XMI.element.att;
%XMI.link.att;
>

<!ELEMENT Column.name (#PCDATA | XMI.reference)* >
<!ELEMENT Column.type (#PCDATA | XMI.reference)* >
<!ELEMENT Column (Column.name?, Column.type?, XMI.extension*)? >
<!ATTLIST Column
%XMI.element.att;
%XMI.link.att;
>

<!ELEMENT RDB ((Table | Column)*) >
<!ATTLIST RDB
%XMI.element.att;
%XMI.link.att;

>

 

Note that, in the model represented in Figure 2.4, both the Table and Column relational database elements use a name:string attribute. As an alternative, the model could abstract that attribute into a supertype named ModelElement. This would lead to the refined model illustrated in Figure 2.7.

Figure 2.7 A Refined Relational Database Model

 

The following illustrates how XMI may use ENTITY declarations in the generated DTD to handle the representation of subtyping relationships in a more compact form. XMI DTD generators may be told to use alternate rule sets to generate DTDs. One of the rule set controls the generation of ENTITY declarations.

 

<!-- ========= RDB:ModelElement ========= -->
<!ELEMENT RDB:ModelElement.name (#PCDATA|XMI.reference)*>
<!ENTITY % RDB:ModelElementFeatures 'XMI.extension | RDB:ModelElement.name'>
<!ENTITY % RDB:ModelElementAtts '%XMI.element.att; %XMI.link.att;
name CDATA #IMPLIED'>
<!ELEMENT RDB:ModelElement (%RDB:ModelElementFeatures;)*>
<!ATTLIST RDB:ModelElement %RDB:ModelElementAtts;>

<!-- ========= RDB:Table ========= -->
<!ENTITY % RDB:TableFeatures '%RDB:ModelElementFeatures;'>
<!ENTITY % RDB:TableAtts '%RDB:ModelElementAtts;'>
<!ELEMENT RDB:Table (%RDB:TableFeatures;)*>
<!ATTLIST RDB:Table %RDB:TableAtts;>

<!-- ========= RDB:Column ========= -->
<!ELEMENT RDB:Column.type (#PCDATA|XMI.reference)*>
<!ENTITY % RDB:ColumnFeatures '%RDB:ModelElementFeatures; | RDB:Column.type'>
<!ENTITY % RDB:ColumnAtts '%RDB:ModelElementAtts;
type CDATA #IMPLIED'>
<!ELEMENT RDB:Column (%RDB:ColumnFeatures;)*>
<!ATTLIST RDB:Column %RDB:ColumnAtts;>

 

Very complex models can be represented in XMI form. In fact, the OMG started standardizing several XMI DTDs for the technologies and tools which are the basis of its Object Management Architecture (OMA). OMG’s OMA is a basic framework for organizing reusable components on top of a CORBA-enabled distributed architecture. OMA’s are based on OMG’s CORBAServices and CORBAFacilities reusable component categories. The XMI DTDs corresponding to OMA services or facilities can be generated from a corresponding MOF-compliant metamodel. For example, UML has a MOF-compliant metamodel and a corresponding XMI DTD as shown (simplified) in Figure 2.8.

 

 

Figure 2.8 A Simplified Representation of the UML XMI DTD

 

Similarly, the CORBA Component Model (CCM) includes a metamodel of the new version of CORBA IDL, and a packaging and deployment descriptor metamodel. The CORBA IDL metamodel is used to represent CORBA object models that may be mapped to CORBA IDL. The packaging and deployment descriptor metamodel is used to generate an XMI DTD that defines the structure of XML documents that contain deployment descriptors. CCM components are deployed with descriptors that are expressed in XML documents that comply with that structure. The EJB Component Model also has an associated MOF metamodel.

 

The Common Warehouse Metamodel (CWM), which has been adopted by the OMG (see specifications at http://cgi.omg.org/cgi-bin/doc?ad/00-01-01 and
http://cgi.omg.org/cgi-bin/doc?ad/00-01-02), also follows the MOF architecture. CWM is as a standard metamodel for relational, record-oriented and hierarchical databases and for other aspects of data warehousing. As a result, XMI DTDs, generated from that metamodel, may be used to exchange warehouse models.

 

 

 

 

 

 


Sub-Topic 3 – XML and Model Based Computing

 

Sub-Topic 3.1 –  Developing Applications Using XMI

 

The OMG MDA described in the previous sub-topic is organized in various layers as illustrated in Figure 3.1 below. The MOF technology is expressive enough to represent complex software systems, and OMG has used it to provide concise models of most of the OMG’s OMA supporting CORBAServices, and CORBAFacilities. Corresponding models describe technologies, services and business models such as UML, CCM, the Common Warehouse Model (CWM), the EJB model, etc. As the various technologies and services are used by tools and applications, the MDA ensures a precise definition of a whole application implementation.

 

 

Figure 3.1 The Various Layers of OMG’s MDA

 

As application models and their implementation details are being captured, the intermediate technology layer provides the necessary implementation details. For example, you may have an application whose business logic is captured in a UML model. MDA handles the application model as an instance of the UML metamodel. As the application is being targeted toward a specific  implementation environments, its implementation details are being provided by the respective technology metamodels (e.g., EJB or CCM metamodels). The application may also reuse available components, including services or facilities available in the target environment. Again, the corresponding  information may be captured using the respective technology metamodels. Based on this approach, OMG’s MDA can capture both the business logic and implementation details of a  complex software application.

 

In the case of the Relational Database Metamodel described in Sub-topic 2.8, the MDA development approach  would be used to produce an API based on the MOF to IDL transformation rules. The corresponding interfaces shown below, provide methods to get (name()) and set (set_name()) the name of a table as well as methods to add modify and delete columns from a table. These generated interfaces can be used by programs to manipulate the instance data of the relational database metamodel.

 

interface Table : TableClass

{

string name ()

raises (Reflective::MofError);

void set_name (in string new_value)

raises (Reflective::MofError);

ColumnSet column ()

raises (Reflective::MofError);

void set_column (in ColumnSet new_value)

raises (Reflective::MofError);

void add_column (in SimpleRDB::Column new_element)

raises (Reflective::MofError);

void modify_column (

in SimpleRDB::Column old_element,

in SimpleRDB::Column new_element)

raises (Reflective::NotFound, Reflective::MofError);

void remove_column (in SimpleRDB::Column old_element)

raises (Reflective::NotFound);

}; // end of interface Table

 

The instance data associated to the relational database metamodel can be represented by an XML Metadata Interchange (XMI) stream that conforms to the corresponding MOF DTD listed in sub-topic 2.8. As an example, the XMI stream could represents a simple table named “PERSON”, consisting of two columns. One column would correspond to the “name" of type "String" used to store the name of a person, and the second column would correspond to the socialSecurityNumber" of type "CHAR(9)" used to store a person's social security number as a nine-character string. The corresponding XMI stream is illustrated below:

 

<?xml version="1.0" encoding="UTF-8" ?>

<XMI xmi.version='1.1'>

<XMI.header>

<XMI.metamodel xmi.name='SimpleRDB' xmi.version='1.0'/>

</XMI.header>

<XMI.content>

<RDB:Table name='PERSON'>

<RDB:Table.column>

<RDB:Column name='name' type='String'\>

<RDB:Column name='socialSecurityNumber' type='CHAR(9)'\>

<RDB:Table.column>

</RDB:Table>

</XMI.content>

</XMI>

 

Sub-Topic 3.2 –  Using XMI with Instance Data


It is important to realize that, in the overall MDA approach, XMI can be used to handle metadata exchange as well as to exchange instance data. As an example, the UML model shown in Figure 3.2 is not a metamodel, Instead, it is an example of a model expressed via the UML metamodel. In this case, instances of classes which are part of the model constitute real user objects, and not models. As any other MOF model, the application model is platform-independent (i.e., it is not specific to CORBA, EJB, XML or any other target platform or support technology.

 

 

Figure 3.2 Expressing Application Models via the UML Metamodel

 

As the MOF Core is very close to UML, MOF’s XMI to DTD transformation rules can be applied directly to a UML model representing a user application. Assuming the UML model is that of a bank application, the result produced by feeding the model into an XMI DTD generator is that of producing  a DTD that spells out how to encode the state of instances of banking entities (e.g., Accounts, and Customers) in an XMI stream. The corresponding DTD shown below can be used as a reference for exchanging instance data.

 

<!-------------------- Customer ----------------------------->
<!ELEMENT Bank.Customer.SocialSecurityNum (#PCDATA | XMI.reference)*>
<!ELEMENT Bank.Customer.name (#PCDATA | XMI.reference)* >
<!ELEMENT Bank.Customer.Address (#PCDATA | XMI.reference)* >

<!ELEMENT Bank.Customer.account (Bank.Account |
Bank.SavingsAccount |
Bank.CheckingAccount |
Bank.PrefferedChecking |
Bank.RegularChecking)*
>
<!ELEMENT Bank.Customer
(Bank.Customer.SocialSecurityNum?, Bank.Customer.name?,
Bank.Customer.Address?,
XMI.extension*,
Bank.Customer.account*)?
>
<!ATTLIST Bank.Customer
%XMI.element.att;
%XMI.link.att;
>

<!---------------------- Account ---------------------------->
<!ELEMENT Bank.Account.number (#PCDATA | XMI.reference)* >

<!ELEMENT Bank.Account.balance (#PCDATA | XMI.reference)* >

<!ELEMENT Bank.Account.customer (Bank.Customer)? >

<!ELEMENT Bank.Account (Bank.Account.number?,
Bank.Account.balance?,

XMI.extension*,
= Bank.Account.customer?)?

>
<!ATTLIST Bank.Account
%XMI.element.att;
%XMI.link.att;
>

 

Sub-Topic 3.3 –  Information Modeling with XML

 

There are at least three information modeling approaches to pick from today. These include XML,  Object-Role Modeling (ORM), and Unified Modeling Language (UML). UML and ORM are obviously modeling technologies, which share concepts such as an object-centric methodology and conceptual modeling. However, ORM is a tool for designing databases, not application classes. XML is more than a data and document markup language, it is a solution for content modeling and creating standards for content. The various types of modeling techniques offered via UML, XML, and ORM cater respectively to object modeling, content modeling, and data modeling. To build Web applications, you might use two or three modeling techniques. For example, the design of distributed applications may be based on UML for middle-tier components and ORM for  database design.

 

First generations of modeling tools and technologies centered on process (e.g., system-level flow charts) and data modeling (e.g., Natural Language Information Analysis Method (NIAM), and data flow diagrams (DFD)). Data modeling is the process of creating models when designing databases. This process is based on a progression from conceptual modeling to logical modeling that leads to the specification of a physical schema. Most data-modeling products support entity-relationship diagrams (ERD), object-role modeling (ORM), and Integration Definition for Information Modeling (IDEF1X) models. More recent modeling technologies, such as UML, support object-oriented analysis and design (OOAD).

 

UML is an object-oriented methodology that standardizes modeling language and notation, not a particular method. UML supports several different views of a system -- class diagrams, behavior diagrams, use-case diagrams, and implementation diagrams. Use-case diagrams let UML users define how actors participate in an interaction with the system. UML users can capture a system's dynamic behavior by using activity diagrams, collaboration diagrams, sequence diagrams, and state diagrams. To document the lower-level details of a system, UML users can develop component diagrams and deployment diagrams. The UML is also extensible and supports the addition of new modeling concepts via the use of stereotypes and patterns. UML is a powerful solution for application object modeling, but developers doing real-time and database applications find that it does not address all of their needs. For those purposes, developers often turn to data modeling and ORM. An example of a mainstream tool that supports ORM (As well as UML) is Visio Enterprise’s VisioModeler. The following chart represents an ORM conceptual model for a memo-style document. This ORM model can be used to generate a database schema for storing documents.


 

 


Figure 3.3 A Sample ORM Model

 

While developers today can use object models, database models, and standard components, XML DTDs are gaining momentum as the content model for standard inputs and outputs. XML, in general, may be used for both data and object modeling. XML supports the modeling of widely disparate types of content that range from book-oriented document types to commercial transactions. XML is an enabling technology for business-to-business integration, data interchange, e-commerce, and the creation of application-specific vocabularies. Database developers are particularly interested in XML as a building block for creating middle-tier servers that integrate data from disparate databases. XML is also used for purposes such as exchanging data warehouse metadata and UML models. Organizations such as IBM, Oracle, Rational, Sybase, and Unisys are promoting XML, UML, and the Meta Object Facility (MOF) as solutions for collaborative MDA development using an open information interchange model. While a visual designer thinks of XML in terms of client-side issues such as presentation and style sheets, a database developer is mostly concerned with middle-tier data integration and schemas. To effectively use XML, a database developer needs to understand XML document structures and be able to store, parse, and manipulate such documents. Additionally database designers need to be able to generate XML output from database queries.

 

The XML document shown below is the counterpart to the ORM model shown in Figure 3.3:

 

<?xml version="1.0"?>

<MESGMEMO STATUS="PUBLIC">

<DATESENT>27 March 1999</DATESENT>

<RECIPIENT>To Whom it May Concern</RECIPIENT>

<SENDER>XYZ</SENDER>

<TOPIC>Recommended Reading List: Web Farming for the Data Warehouse</TOPIC>

<SECTION>

<P>

Web Farming for the Data Warehouse (Morgan Kaufmann) is a compendium of information that is best-described as systematically making intelligent use of the Web.

...

</P>

<P>

The book contains a wealth of information about content-providers, protocols, standards, tools, discovery services, knowledge management, Web agents, and data mining software. 

...

</P>

</SECTION>

<CLOSE>XYZ</CLOSE>

</MESGMEMO>

 

Several initiatives are related to W3C’s recent XML Schema recommendation that provides an integrated set of document structuring and data typing capabilities. These initiatives include the Resource Description Framework (RDF), the Document Content Description (DCD), and XML-Data. RDF provides the ability to describe Web resources. An RDF schema is similar to a database schema. It defines types and document semantics, which makes it possible to do type checking of XML documents. DCD enables the definition of rules that describe the content and structure of XML documents. DCDs supplement DTD semantics by describing constraints in XML and defining document elements as types. DCD constraints include subclassing and inheritance, data types, and SQL-style constraints (key fields, unique values, referential integrity). XML-Data is an XML vocabulary for defining and documenting object classes. It can be used to define the characteristics of syntactic classes, or for conceptual schemas that are similar to relational schemas. XML-Data schemas include element type declarations. They support subtypes, groups (ordered sequences of elements), defaults, aliases, class hierarchies, multipart keys, and one-to-many relations. We refer students to the W3C Metadata project at http://www.w3.org/Metadata/Activity for additional information on W3C’s work in the area of metadata handling.

 

XML schemas facilitates the development and use of tools for querying XML data stores. Although XPATH provides sophisticated pattern-matching functions available via XSLT, it doesn't provide create, update, and delete operations that are analogous to SQL queries. That particular functionality is part of XML Query, which was covered in an ealier session of this course.

 

In summary, database developers are likely to be involved with XML for several reasons:

 

1.      Develop applications that query databases and format the query results as XML documents.

2.      Develop databases and write code to support business-to-business integration or other forms of electronic data interchange (EDI).

3.      Store XML documents in a database.

 

Database developers are well supported by current database products when it comes to using XML capabilities for persistent applications. Oracle, IBM, and Microsoft fully support XML in their application server and database server offerings. Oracle has built-in support for XML into products such as Oracle Application Server and Oracle 8i (O8i), an object-relational DBMS capable of storing rich data types. O8i includes an XML parser, an Internet File System (iFS) that provides automatic parsing of XML documents, and Java classes that support XML. Oracle's parser supports the Document Object Model and the event-based SAX interface. Oracle's interMedia text search engine provides section searching of XML documents. XML support has been further integrated into Oracle9i’s application server and database.

 

IBM provides an XML toolkit for its WebSphere (application server) studio product and its DB2 Universal Database (UDB) is XML-enabled. IBM has developed an XML Extender for DB2 UDB and has added features for storing and querying XML documents. It can store XML documents as a single column, or decompose the document and treat it as a collection of fields that are standard or user-defined types (UDTs). IBM revised the DB2 text search engine so it understands the structure of an XML document, thereby providing capabilities such as section searches. By storing XML elements and attributes as SQL types, DB2 users are able to index documents for more powerful search optimizations. IBM also added functions to extract XML elements, attributes, or entire documents, to reconstruct decomposed documents, and to link to XML documents stored in external files.

 

Microsoft Office 2000 saves files as native HTML and includes embedded XML within Office documents. Internet Explorer can read XML tags embedded in a Web page and perform semantic validation using DTDs. Microsoft implements the W3C DOM over a Component Object Model (COM) component. Developers can use the XML COM component for client- or server-side programming. The XML component calls the XML parser to check a file for validity, builds the document tree in memory, and then builds the object model over the tree. This programmatic interface enables VBScript, JScript, ActiveX Data Objects (ADO), and Active Server Pages (ASP) to operate with XML. A script can, for example, create an XML data source object (XMLDSO) and then use DOM objects to walk an XML tree. ADO has been extended to work with XML as shaped or hierarchical recordsets. Users can bind data islands to Web pages and then use XML objects or ADO methods to navigate through the data.