"The Intelliun Team developed and demonstrated a very robust B2B trading exchange to be used by Fortune 50 companies that was completed in only four-man days using VE. Some comparable systems have taken more than 10 man-years to design and develop."Doug Brown,
Senior Director U.S. Operations
A Global B2B eSolutions Provider To The Electronic Manufacturing Services Industry |
|
 While developing software applications, the analysis activity focuses on identifying the functional and non-functional requirements, along with all the external entities that interact with the software. The Unified Modeling Language (UML) prescribes a way to organize these functional requirements as use cases, and represent the external entities as actors. Actors can trigger the execution of use cases, or respond to use case requests.
Consequently, in the abstract design activity, use cases are used to identify the collective state and behavior of the system, along with the exact rules and constraints to keep the system in a valid state. Actors, on the other hand, are used to identify the various interfaces to the system, including both client interfaces (e.g. a graphical user interface for human actor), and resource interfaces (e.g. accessing an existing mainframe application).
|
 |
|
 VE adopts an object-oriented approach for capturing and representing the abstract design of a system. Accordingly, the state is captured in terms of objects along with their primitive attributes and inter-relationships. Behavior, however, is captured as processes and operations, while rules and constraints are represented as formulas (i.e. infix expressions). VE uses UML for representing the abstract design artifacts, namely, the class diagram and activity diagram for objects and processes/operations respectively. Interfaces, on the other hand, are captured as portals and resource policies.
A portal is created for every client actor to capture the specific system state and behavior that actor can access accordingly with the use case model. Also, a portal maintains additional information per access device that an actor can use. For example, a portal might have look-and-feel information for a web browser, while it maintains a WSDL for a Web service client.
A resource policy is maintained per resource actor, specifying the type of the external resource, connection descriptors, and mapping information. VE 3.0 provides resource adaptors for EJB, Web services, JNDI, and SQL databases. However, VE also provides an extensible framework for adding new or proprietary resource adaptor implementations.
|
|
 To put the above into an example, the diagram on the right (UML class diagram) shows a simple accounts receivable (AR) module. The AccountReceivable object (singleton) maintains customer objects along with their address information, outstanding balance, and applicable sales tax percentage. Also, it maintains invoice objects along with the appropriate customer, ship to information, and line items. Several rules are specified in the model. For example, in the InvoiceLineItem's totalPrice attribute is always set to quantity times unitPrice. The Invoice's status attribute is initialized to "New", and can only have the following values (Domain): "New", "Validated", "Submitted", and "Closed". Another example of a rule is the On Add rule associated with AccountReceivable's invoices relationship. The rule changes the status of a newly added invoice to "Submitted", and increments the invoice's customer's unpaidBalance by the invoice's grandTotal. |
|
 The diagram on the right (UML activity diagram) shows a simple process for submitting a new invoice. The process is transactional, and it expects an invoice object as a parameter. The process has two activities, the first invokes the validate operation on the passed invoice object, while the second adds the invoice object to the AccountReceivable (singleton) invoices relationship. Since the entire process is transaction, a transaction will be started upon the launch of this process and committed upon the successful completion (no exceptions) of the process. On commit, all changes to persistent objects will automatically be generated to the appropriate external resource (e.g. SQL database) accordingly with the mapping information specified in the applicable resource policy. |
|
|
In VE, with the above two models, you've actually built a fully functional n-tier AR module including a ready to use web browser interface, Web service interface (WSDL and SOAP), and even a PDA browser interface. In addition, by clicking on the database deploy button in the VE/Designer and answering a few questions regarding the target database, VE automatically generates the appropriate database schema, object-relational mapping, and all of the SQL statements necessary to carry all of the functionality specified in the model. Granted it's a simple AR module with limited functionality, still, it allows you to maintain a database of customers, submit invoices and track outstanding balances, and view submitted invoices. This same approach can be easily applied to construct a full AR module, an entire accounting system or even an ERP, CRM, or any business or operational suites of applications.
By completely separating all of the interface related logic from the application logic and abstracting out all of the architecture/technology related constructs, VE creates an environment for expressing a pure and immediately executable form of application logic via objects, processes, and rules. In addition, VE automatically generates the appropriate interface logic, and provides the developer with easy to use tools to customize them (e.g. WYSIWYG editor for changing the look-and-feel of web pages). VE eliminates the need to know anything about HTML, JavaScript, SQL, Java, or the other dozen different technologies involved in building n-tier applications.
|
|
|
|
|
|