in black and white
Main menu
Home About us Share a book
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

Model driven architecture applying MDA to Enterprise computing - Frankel D.

Frankel D. Model driven architecture applying MDA to Enterprise computing - Wiley & sons , 2003. - 355 p.
ISBN: 0-471-31920-1
Download (direct link): modeldrivenarchitecture2003.pdf
Previous << 1 .. 107 108 109 110 111 112 < 113 > 114 115 116 117 118 119 .. 123 >> Next

Although the transition to MDA is inevitable, the length of time the transition will take is not preordained. We could stumble badly and set MDA back quite a bit by overselling it at this early juncture or, paradoxically, by failing to grasp its potential and properly preparing the groundwork for it. The consequences of a serious setback could be painful for the enterprise software industry. One way to alleviate software production pressure is to cut back on plans for new software initiatives. We're already seeing some of that.
So we have our work cut out for us. Let's get on with it.
Sample Transaction Metamodel
Figure A.1 is a reproduction of the abstract syntax of the simple example metamodel from Chapter 5. This appendix informally describes the semantics of the metamodel classes.
The ancestor of all classes in the metamodel. All classes thus inherit the name attribute from ModelElement.
An abstract class representing a transaction definition (specification) rather than a runtime transaction.
An abstract class representing the definition of a transaction that has full ACID properties. ACID transactions are initiated in the enterprise tier.
298 Appendix A
Figure A.1 Sample metamodel.
A pairing of two ACIDTxs:
1. An executor ACIDTx that executes a unit of work.
2. Either a reverser or compensator ACIDTx that can undo the work after the executor has been committed.
Reversal differs from compensation in that it results in the change to the persistent store originally executed being no longer visible to the persistent store other than (possibly) in an audit trail. Compensation does not touch the results of the original execution but enters a compensating record into the persistent store.
For example, if an erroneous charge to a customer is reversed, the customer would not see the charge on their invoice. If the charge is merely compensated for, then the erroneous charge would show on the invoice along with another line item that reverses the charge (that is, a credit). Reversal is not always possible, in which case compensation is required.
Sample Transaction Metamodel 299
A BusinessTxUnit is a key construct for composing complex business transactions from several ACID transactions. A BusinessTxUnit is not fully ACID itself because it isn't visible to the transaction monitors of today.
A BusinessTxUnit is an abstract type completely partitioned into two concrete, disjoint subtypes: ReversableUnit and CompensatableUnit. A ReversableUnit includes the specification of an ACIDTx that reverses the work of the executor. A CompensatableUnit includes the specification of an ACIDTx that compensates for the executor's work. Note that the same ACIDTx could play the executor role in one BusinessTxUnit and the reverser or compensator role in another.
The fact that a BusinessTxUnit is abstract and that its subtypes constitute a complete partition reflects the rule that the ACIDTx referenced by the BusinessTxUnit must be undoable; a BusinessTxUnit that does not have a reversal or compensation ACIDTx is an oxymoron.
A BusinessTxUnit that can compensate for the work committed by its executor ACIDTx. (See the definition of BusinessTxUnit for an explanation of compensation.)
A BusinessTxUnit that can reverse the work committed by its executor ACIDTx. (See the definition of BusinessTxUnit for an explanation of reversal.)
A transaction whose scope encompasses more than one ACID transaction. Such a transaction isn't fully ACID because it isn't visible to the transaction monitors of today. A BusinessTx can sometimes run for many seconds, minutes, or even hours, in which case locking the resources it updates for its full duration, as required for ACID transactions, would be untenable.
A BusinessTx is typically initiated in the workspace tier. A BusinessTx groups a set of one or more BusinessTxUnits, where each BusinessTxUnit references an executor ACIDTx and a reversing or compensating ACIDTx.
Options Trading
The example in Chapter 8 is a currency options trading system. If you're not familiar with options trading, here are a few basic concepts that will help you understand the example.1
Basic Concepts
The basic concepts are organized tutorially rather than alphabetically. If you read them in the order presented, you'll find that the concepts build upon previously defined concepts.
Underlying good Monetary currency, equity shares, commodities, or anything else for which an open trading market exists.
Call option The owner of a call option has the right to purchase a specified underlying good at a certain price called the strike price. In the case of our examples the good is a foreign currency.
Put option The owner of a put option has the right to sell a good at a certain price, which is also called the strike price.
Expiration date An option is a time-limited contract. The contract is null and void once the expiration date has passed.
Previous << 1 .. 107 108 109 110 111 112 < 113 > 114 115 116 117 118 119 .. 123 >> Next