2chung/SA/B2BIPS.doc · Web viewThe compelling benefits that B2B marketplaces offer for buyers, suppliers and market makers are driving their rapid adoption. Marketplaces are the

PROJECT NUMBER 1

B2B INVOICE PROCESSING SYSTEM ARCHITECTURE

Andrew SchmidtJoon Ho

Robin F. Delcambre

Project #1 :B2B Invoice Processing System Architecture Oct. 3 2000

October 2000CS6362 Software Architecture and Design

B2B-IPSTM System Page

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------B2B Electronic Commerce SystemUniversity of Texas at Dallas---------------------------------------------------------------------------------------------------------------------------------------------------------------------

The B2B-IPSTM System Architecture---------------------------------------------------------------------------------------------------------------------------------------------------------------------

Project #1 :B2B Invoice Processing System Architecture - Oct. 3 2000-------------------------------------------------------------------------------------------------------------------------------------------------------------------------"The important decisions in design are not what to put in but what to leave out". – Attributed toTony Hoare by Per Brinch Hansen

1


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Table of Contents-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

INTRODUCTION 3

THE TIME IS RIGHT FOR B2B 3OUR MODEL OF B2B MARKET PLACE 4

PROCESS ARCHITECTURE 5

METHODOLOGY 5PROCESS ARCHITECTURAL DESIGN 6

REQUIREMENT SPECIFICATION 7

BRIEF DESCRIPTION 7

ARCHITECTURAL DESIGN ALTERNATIVES 8

PIPE-AND-FILTER ARCHITECTURE 8OBJECT-ORIENTED ARCHITECTURE 12IMPLICIT INVOCATION 18

TRADE-OFF ANALYSIS 23

INDIVIDUAL ANALYSIS 23OVERALL ANALYSIS 28

SELECTED ARCHITECTURAL DESIGN 29

DECISION POINTS 30


2


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

IntroductionThe Time is Right for B2B-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The Internet has finally arrived for the business-to-business market. The infrastructure has been built,companies are interested, and the economic environment is robust. Technology is changing from a cost of doing business to a way of doing business. Several reasons why this is the right time for an internet based B2B market implementation are discussed below:

Infrastructure ReadyCompanies have built their Web infrastructure around de facto standards and have adequate security

to interact with a public network. As recently as 1996, the top ten sites on the Web were university sites, according to Media Metrix, and included no e-commerce sites. Today, all top 15 sites offer community services and commerce. The number of Web site addresses (URLs) increased by 137% in 1999.

Speed and SimplicityThe simplicity of Internet standards and technologies ushered in the “fast food” era of application

development and away from agrarian development (grow the application in your back yard for three years). There’s no time for nine months of analysis. Internet standards facilitate speed, since applications are more uniform in appearance and centralized in administration and execution. It’s easier than ever before to change applications as business needs dictate.

Well-financed Start-ups; Strong EconomyThe strength in the economy allows companies to take risks they might not otherwise consider.

Venture capitalists poured a record $48 billion into start-ups last year (compared with $16 billion in the prior year) and two-thirds of that was Internet-related. Additionally, the public market is willing to aggressively finance early-stage companies and let them evolve in the public eye.

(Source : Morgan Stanley, Collaborative Commerce – April 2000)

Online markets, also known as B2B marketplaces, are commerce sites on the public Internet that allow large communities of buyers and suppliers to meet and trade with each other. They present ideal structures for commercial exchange, achieving new levels of market efficiency by tightening and automating the relationship between supplier and buyer. They allow participants to access various mechanisms to buy and sell almost anything, from services to direct materials.

The extreme flexibility of these marketplaces, which may be customized to serve the full supply chain of virtual any industry, will establish them as the pillars of the new B2B eCommerce economy. Gartner Group predicts 7,500 to 10,000 B2B marketplaces to emerge by 2002, while Giga and IDC project that B2B marketplaces and exchanges will allow companies to save between $180 billion and $480 billion in transaction costs and related expenses by 2003.

The compelling benefits that B2B marketplaces offer for buyers, suppliers and market makers are driving their rapid adoption. Marketplaces are the latest and most significant weapons to reshape B2B commercerelationships, and will soon affect all businesses in one way or another.

The rapid adoption of B2B marketplaces will shape the future of global business. Marketplaces will multiply and leverage each other for specialist capabilities. In the years to come, marketplaces of all descriptions and focus industries will proliferate on the worldwide stage, integrating into progressively deeper layers of the global business ecosystem. For companies seeking to establish a place of advantage in the economy, equipping for competition over B2B marketplaces is essential.


3


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

IntroductionOur Model of B2B market place-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

For every order-matching event, there are 15-20 other transactions associated with that order. Here, a B2B transaction represents the intersection of two trading chains. The buyer is procuring product to incorporate into products resold to the buyer’s customers. Conversely, the seller’s goods are dependent on material and products from other suppliers. The growing branches of this complex tree create challenges of coordination and optimization to get the right product to the right place at the right time. The Web provides a convenient, ubiquitous platform to see and coordinate the entire chain of commerce and will create a step function in efficiency and possibilities. Finally we can get a picture of the chain of commerce.

Fig. 1 Chain of the Commerce & B2B as an Intersection of Demand & Supply Chain

Among various B2B eCommerce systems, an Invoice Processing system is a critical part of many types of businesses – e.g. Internet-based purchasing of automobile parts, telecommunication equipments, films, software/objects, oil, airplanes, etc.

Our team is to build a software architecture for an invoice processing system to be used as part of a B2B electronic commerce system. For this project, we consider five(5) alternative software architectural designs : one pipe-and-filter, two in OO, and two in implicit invocation. Afterwards, we make a rational choice among the five alternatives.


4

Source: Morgan Stanley Dean Witter Internet Research

Intersection of Demand &

Supply Chain

ManufacturingAssembly Inventory

End Customer &Distributor

Suppliers

ManufacturingAssembly Inventory

Demand Chain Supply Chain

B2B-EC

Buyer Supplier


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Process ArchitectureMethodology-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

As software complexity has increased, so has the number of people involved in the design, implementation, testing and launching of software systems. No longer does a lone programmer create a single application that runs independently. Today, more than ever, there is a need for a plan. A process architecture that will delineate the steps and milestones required to complete a fully operational and interactive system.

As the software architects, our team, consisting of Joon Ho, Robin Delcambre, and Andrew Schmidt, took the following steps in order to derive a good system architecture:

Understand the requirements Assign and complete architectural alternatives Review and analyze completed architectural alternatives Complete the trade-off analysis Integrate information into one coherent document

While understanding the requirements seems like the obvious first task, it is surprising how many people jump into a project without an understanding of what they are doing. For this reason we highlight this step as the most critical. By completing this component we gain an understanding of what the project expectations are.

We divided the work of creating the architectural alternatives amongst our selves in order to complete this most labor intensive component quickly. Our goal was to come up with three Implicit Invocation architectures, three Object Oriented (ADT) architectures, and two pipe-and-filter. While this was more work than required, we wanted to be able to take the best parts of each design and incorporate them into the architectural alternatives that we would present.

Using the designed alternatives, we reviewed and analyzed each in order to ensure completeness and correctness. We modified any errors or redundancies in order to create a clear and concise design.

With the completed design alternatives, we completed a trade-off analysis. We used this information to choose the best design alternative for presentation.

Finally, all the information from all the previous steps was organized and placed into this document for review.


5


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Process ArchitectureProcess Architectural Design-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Primary concerns and roles played by team members are listed as follows:

Team Member

Role Primary Concern

Joon Ho Potential end-userRequirement EngineerArchitect

Enterprise Requirements Knowledge negotiation System Requirements Spec. Architecture Design Issue

Andrew Schmidt

ArchitectCustomer Quality Assurance Manager

Functions Performed Development Time, Cost Verification of Design System Requirements Issue

Robin F. Delcambre

ArchitectProject managerProduct Manager

Customers, end-users Needs Revenue, Profits, Market Share Backward/Forward Traceability Overall Understandability

Process Diagram

Component : PersonInteraction / glue : Communication


6

Customer/ End-User

Requirement Engineer

Architect

QA Manager

Project/Product Manager

NegotiationValidation

Verification

Backward TraceabilityForward Traceability


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Requirement SpecificationBrief Description-------------------------------------------------------------------------------------------------------------------------------------------------------------------------Functional Requirements

The B2B-IPSTM has the following features: issuing invoices, authenticating customers, receiving payments (the system shall allow both on-line payments and payments via other means), issuing receipts, and generating reminders for unpaid invoices.

The B2B-IPSTM shall issue invoices to two distinguished kinds of customers - member customers and non-member customers. Only member customers are allowed to use special features of the system such as viewing real-time research on the goods and services being sold, etc.

Reconciliation between invoices and paid payments need to be done once a week. This might be done by associating invoice #, date, amount and customer # with each payment, and by associating invoice #, data, amount and customer with each invoice.

For those invoices, which have been paid, a receipt is issued, and its record is kept in order to handle any potential complaints from customers in future. Issuing a receipt might be done by associating customer #, name, address and credit period with each customer, and by associating invoice #, date, amount and customer # with each receipt. For those invoices, which have not been paid within the allowed payment time, a reminder is issued. This might involve comparing invoices with payments and identifying all payments that are due or overdue.

Depending on the architectural style chosen, certain modules may be needed to deal with I/O of various sources and destinations (e.g., reading invoices from a database, reading customer information from database, writing payment into a database, writing receipts into a database, etc.).

Nonfunctional Requirements

Every system has to meet certain nonfunctional requirements in addition to the functional requirements. For our model, we are including consideration of the following nonfunctional requirements:

Reliability Performance Modifiability Complexity Portability Reusability

The listing given is in order of our estimation of the relative importance of each of the nonfunctional requirements. Additionally, since each of the architectural models developed within this project meet the Functional Requirements, the evaluation of relative merits for each model are done on the basis of how well they meet the nonfunctional requirements. This analysis is shown in Table 1 under the Trade-Off Analysis of this report.


7


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Architectural Design AlternativesPipe-and-Filter Architecture-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Introduction

A pipe-and-filter model of system architecture structures the system into a set of sequential components. Each component is defined by the major task that it performs. The result of each component is passed along to the next component for processing.

The advantages to a pipe-and-filter system lie in the simplicity of the system. While this architecture is best suited for simpler software systems, it has its roots back to the earliest programs written. For many years software was written as one long code segment that was executed sequentially. The advent of subroutines made this type of system easier to create and maintain. While many think of pipe-and-filter as outmoded, this style of architecture will be used for years to come.

The Pipe-and-Filter Design

Design Diagram part 1


8

Element: ReceiptReceipt is created and sent to customer

Element: SchedulerStarts events at designated interval

Element: ReconcilerCompare payments with outstanding invoices.

If invoice is paid, sends info to Receipt

Account Number, payment number

Invoice Information

Late Payment: Send Invoice Information

Element: NotifierSend invoice information to customer if

payment is late


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------Design Diagram part 2


9

Element: Customer Interface; GeneralHTML based

Input: Customer requests to make

payment

Input: Customer requests product

information

Input: Customer wants to make a complaint

Customer ID, Password

Bad Password

Output: Reject Request

Account Number, Customer Type

Element: Customer Interface; SpecificHTML Based

Product ID, Customer

Type

Complaint, Account Number

Payment, Account Number

Element: Payment Database

Element: Product Database

Element: Complaint Database

Product Info for Member

Customer Interface

Info is displayed

Input: Payment info,

Account number

comes in from Account Dept. (i.e. Payment was mailed in) (element out

side our scope.)

Element: SecurityPassword is checked

Product Info for

Non Member

s

Customer Interface

Info is displayed


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------Style : Pipe-and-Filter

Data is passed from component to component for processing.

Components : Elements (Filters)

Customer Interface

This element provides interactivity with the customer. It comes in two types: General and specific. The two types are linked together because both will be written in a markup language like HTML and should be implemented by a common group. This element is directly linked to the input and output mediums and passes customer input to the next element for processing and then displays the result of that processing.

Security

This element takes care of customer password checking during customer login. While the activities of this element could easily be handled by another element, we decided that it would be best if this part of system was kept separate and information about it’s implementation be kept secret. This element accepts customer ID and password and passes along the customer’s account number and customer type if the password is correct.

Complaint Database

This element stores complaint data. Each complaint is associated to an account number. In order to provide fault tolerance while interfacing with the database, this element engages a two-phase locking protocol. The element accepts the account number and complaint details. The output of the element will redirect the customer to the customer interface for another request.

Payment Database

This element stores a record for each payment received. Online payment information will be received from the customer interface. The element also allows for accounting personnel within the company to directly enter payment information. This element also engages a two-phase locking protocol for fault tolerance. The element accepts the account number and payment details. The output of the element will redirect the customer to the customer interface for another request.

Product Database

This element looks up product information for the customer. If the customer has member status, the customer will be allowed to view more detailed information about the product. The element accepts the product ID and customer type and passes the product information to the customer interface.

Scheduler

This element is separate from the rest and runs independently. The Scheduler initiates payment reconciliation by passing the account number and payment number to the Reconciler a week after the payment was recorded. In order to do this the element must have access to the payment database.

Reconciler

This element compares payment information with outstanding invoices. If a payment and invoice match, receipt information is passed to the Receipt element for storage. If a past due invoice is found, the element sends the invoice information to the Notifier. In order to do this, the element must have access to the invoice database.Project #1 :B2B Invoice Processing System Architecture - Oct. 3 2000-------------------------------------------------------------------------------------------------------------------------------------------------------------------------"The important decisions in design are not what to put in but what to leave out". – Attributed toTony Hoare by Per Brinch Hansen

10


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------Receipt

This element prepares the receipt from the received information, stores a copy of the receipt in a database and sends a copy to the customer.

Notifier

This element sends a notice to the customer that a payment is past-due. It receives this information from the Reconciler.

Interactions : Pipe

Each pipe passes the output of one element into the input of another. The item that is most commonly passed is the customer account number. Also passed is the customer ID, password, payment detail, invoice details, product details and complaint details.

Constraints

Each element should be executed sequentially. The Scheduler element must have access to the payment database and the Reconciler must have access to the invoice database.

Pattern

Each element passes data to the next through a pipe.


11

ElementPipe

Element


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Architectural Design AlternativesObject-Oriented Architecture-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Introduction

An object-oriented model of a system architecture structures the system into a set of loosely coupled objects with well-defined interfaces. An object-oriented decomposition is concerned with object classes, their attributes and operations. When implemented, objects are created from these classes and some control module is used to coordinate object operations.

The advantages of the object-oriented approach are well known. Because objects are loosely coupled, the implementation of objects can be modified without affecting other objects. Objects are often representations of real-world entities so the structure of the system is readily understandable. Because their real-world entities are used in different systems, objects can be reused. However, the object-oriented approach does have disadvantages. To use services, objects must explicitly reference the name and the interface of other objects. If an interface change is required to satisfy proposed system changes, the effect of that change on all users of the changed object must be evaluated. While objects may map cleanly to small-scaled real-world entities, more complex entities are sometimes difficult to represent as objects.

The first Object-Oriented Design

Design Diagram


12

Subprocedure Call

Customer• Address• Name• Customer#• Credit period

Receipt• Amount• Customer#• Invoice#• Date

Reconcile

Payment• Amount• Customer#• Invoice#• Date

Master Control

OutputMedium

Print

Invoice• Amount• Customer• Invoice#• Date

Query

System I/OAccess Attributes including procedures

isOnlinePaym

ent isO

therPayment

findRecord

keepRecord

checkDue reconcile

realTimeR

esearch

generalInfo

recordCom

plaints

findCom

plaints

issueInvoice sendR

emin

der

acceptPayment

sendReceipt

isMem

ber

isNonM

ember

Input Medium


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------Style : Abstract Data Type (ADT)

Data is no longer directly shared by the process components instead, each module provides interface. Other components access data only by invoking that interface (Information hiding).

Components : Objects & Data

Module Payments

This module receives payments from customers and issues receipts for these payments. To do this, this module provides routines to access individual acceptPayment, sendReceipt in the Invoice module. For the convenience of the customers, this module will allows both online payments (e.g. through transfer of funds) and payments via other means (e.g. checks and wire transfer) through procedure isOnlinePayment and isOtherPayment .

Module Reconcile

This module reconciles the payments, which have been made with the invoices once a week due to the control of Master Control. To do this, this module provides access to the Payment module to retrieve associating invoice#, data, amount, and customer# with each payments, and access to the Invoice module to retrieve associating invoice#, date, amount, and customer with each invoice, comparing those two kinds of data to reconcile. To retrieve those data, this module provides interface to the attributes in the module Payment and Invoice as represented thick dashed arrows. This thick-dashed arrows can also access procedures in each module, as needed. For those invoices that have been paid, a receipt shall be issued. For this purpose, this module accesses to procedure sendReceipt in the module Invoice. The issued receipts are kept to the record through procedure keepRecord to be used in handling any complaints from the customers in the future. This module also provides procedure findRecord which retrieve paid receipts data to service to the Query module. If procedure reconcile finds unpaid invoices, Master Control invokes procedure checkDue to find invoices that have not been paid within allowed payment period. To do this, procedure checkDue accesses: a) the Payment module to retrieve associating invoice#, data, amount, and customer# with each payments; and b) the Invoice module to retrieve associating invoice#, date, amount, and customer with each invoice. checkDue compares data from Payment and Invoice modules to find any unpaid invoices that are overdue. It then issues a reminder to each customer that has overdue invoices through procedure sendReminder in module Invoice.

Module Invoice

This module functions issuing Invoice when receives orders basically through procedure issueInvoice. But, most important feature in this architecture is that provides main procedures as sendRemainder, sendReceipt, and acceptPayment. So, module Payment and Reconcile access those procedures in this module. The procedure sendReminder issue a reminder for those invoices that have not been paid within allowed payment time. The procedure sendReceipt issue receipts, which are done by associating customer#, name, address and credit period with each customer, and by associating invoice#, date, amount and customer# with each receipt. To do this, procedure sendReceipt accesses modules Customer and Receipt through thick dashed arrows, and retrieves data from each module. The procedure acceptPayment is used by module Payment to check validation of payments from customer.

Module Customer

This module keeps the customers’ data like customer#, address, credit period and name. Also, it checks whether customer is a member or non-member and returns this result to module Query to let Query prevent a non-member customer in accessing certain data search.


13


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------Module Receipt

This module keeps the receipts’ data like invoice#, amount, date and customer# and provides this data to module Invoice to let Invoice issue receipts.

Module Query

This module fetches data for requests of search, information and complaints from customers in the Input Medium after checking if the customer is a member or nonmember through subprocedure calls to isMember and isNonMember in the module Customer. RealTimeResearch is for Member customer and generalInfo is for Non-Member customer. This module accesses procedure findRecord in module Reconcile to get receipt information for that customer during handling of complaints from customer and also procedure findComplaints to keep track of old complaints data to determine whether there are some topics of complaints or not. The procedure recordComplaints keeps complaints data after handling customer’s complaints.

Module Print

This module accesses procedures sendReceipt, sendReminder and issueInvoice in module Invoice and sends those results to Output Medium.

Interactions/ glue : Procedure Call, Access Attributes, System I/O

Procedure Call

One module can access procedures in other modules through this routine. Arrow directions in the diagram indicate that the calling module hands control to the called module, and after called procedure finishes its job, control is returned to the calling procedure.

Access Attributes

This thick dashed arrows indicate that calling procedure accesses called module’s attribute(s) ( e.g. invoice#, date, name, customer#, and so on), and also accesses procedure(s) of called module. In this first diagram, module Reconcile accesses modules Payment and Invoice to compare data, reconcile, and check due. In this case, module Reconcile also accesses procedures sendReminder, sendReceipt in module Invoice. Module Invoice accesses modules Customer and Receipt to issue a receipt. (See friend keyword note in Constraints below regarding possible implementation.)

System I/O : This is Input/Output from outside medium.

Constraints

Modules access other modules' data only by invoking the other modules' interface (information hiding). However, in this particular object-oriented architectural design, the thick dashed arrows allow modules to access each other's data directly. In C++, this feature can be implemented with friend keyword.

Pattern During running the procedure, calling other procedures in the other module is a pattern.


14

Subprocedure Call

Access AttributesSystem I/O


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------The second Object-Oriented Design

Design Diagram


15

Reconcile

Customer Interface

Master Control

OutputMedium

System I/O

Input Medium

Subprocedure Call

ProductProduct ID

Product Info

PaymentPayment # AmountCustomer ID Date

InvoiceInvoice # AmountCustomer ID Date

ComplaintComplaint # Customer ID

Complaint

CustomerCustomer ID Name

Address

Add

Com

plaint

IsMe

mber

Get

Mem

berData

Get

Non

Mem

Data

Security

Che

ckPa

ss

Add

Pay

ment

GetP

ayment

AddI

nvoice

GetI

nvoice

Start

Rec

on

ReceiptReceipt # Invoice #

Customer ID Payment #

Add

Rec

eipt

Start

Mem

berInfo


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------Style : Abstract Data Type (ADT)

Data is no longer directly shared by the process components instead, each module provides interface. Other components access data only by invoking that interface (Information hiding).

Components : Objects & Data

Module Customer Interface

This module provides interactivity to the customer by accepting the input from the input medium and supplying output to the output medium. The module is started by the Master Control and can call on most of the other modules for information. Through the CheckPass subroutine, it can have the security module check a customer ID and password. The return value is the customer type or false. Through GetMemberData and GetNonMemData, it can interface with the product module and get product information that can be displayed to the customer. Via AddPayment and AddComplaint, the module can add payment information to the Payment module and complaint data to the Complaint module.

Module Reconcile

This module is initiated by the Master Control through the StartRecon subroutine. It uses the GetPayment and GetInvoice subroutines to get payment data and invoice data. It compares this data to identify which invoices have been paid and which have not. For those that have been paid a receipt is created and stored in the Receipt module via the AddReceipt subroutine. If an invoice is past due, the module uses its link to the output medium to notify the customer of the late payment.

Module Invoice

This module stores invoice information. As well as the GetInvoice subroutine, there is also a AddInvoice subroutine to be used by groups external from our own. Invoice data that is stored includes invoice number, customer account number, date and amount. Customer information is accessed through the MemberInfo subroutine.

Module Customer

This module stores customer information. The customer information that is stored includes customer account number, customer name and customer address.

Module Security

This module checks customer ID and password for entry into the system. This module accesses customer information through the IsMember subroutine.

Module Receipt

This module stores receipt information that is created by the Reconciler. That information includes receipt number, invoice number, payment number and customer account number.

Module Complaint

This module stores complaint information. That information includes complaint number, customer account number and the complaint.


16


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------Module Product

This module stores product information that can be accessed by the customer interface. At a minimum, the stored data would include product number and product information.

Module Payment

This module stores payment information. It includes an AddPayment subroutine that can be used by external systems to add payment information to the database. The information that is stored includes payment number, payment amount, customer account number and date. Customer information is accessed through the MemberInfo subroutine.

Interactions/ glue : Procedure Call, System I/O

Procedure Call

One module can access procedures in other modules through this routine. Arrow directions in the diagram indicate that the calling module hands control to the called module, and after called procedure finishes its job, control is returned to the calling procedure.

System I/O : This is Input/Output from outside medium.

Constraints

Other modules access data only by invoking that interface (information hiding



17

Subprocedure Call

System I/O


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Architectural Design AlternativesImplicit Invocation-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Introduction

Implicit Invocation uses a form of component integration based on shared data. However, there are two important differences. First, the interface to the data is more abstract. Rather than exposing the storage formats to the computing modules, this solution accesses data abstractly. Second, computations are invoked implicitly as data is modified. Thus interaction is based on an “active data” model.

The first Implicit Invocation Design

Design Diagram


18

payment query receiptcustomer reconcile

memberCheck reconcile sendReminder

MasterControl

input

Inputmedium

output

outputmedium

acceptPayment

paymentInfo

complaints

research

receiptInfo

customerInfo

checkDue

result

sendReceipt

invoice

invoiceInfo

Control

Invoice#AmountDateCustomer#

Invoice#AmountDateCustomer

CustomerAddressCredit PeriodName

Invoice#AmountDateCustomer#

Paid infoOverdue infoCompared results

ComplaintsOnline data

Subprocedure Call

System I/OImplicit Invocation


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Style : Implicit Invocation

Data are accessed abstractly and computations are invoked implicitly as data is modified, based on an active data model.

Component : Processes and Data(Repository)

Module input

This module receives payments from customers via the input medium and through operation acceptPayment saves customers’ payment information and complaints information, if any. AcceptPayment invokes module memberCheck if there are any complaints or requests for online research, and invokes module sendReceipt automatically to send receipts immediately after receiving payments. Module memberCheck

This module reads payment information and customer requests through operation acceptPayment, and handles complaints and online research according to whether a customer is a member or a non-member through interfaces complaints and research.

Module reconcile

This module reconciles the payments that have been made with the invoices once a week due to the invoking of Master Control. To do this, this module accesses the Payment database to retrieve associated invoice#, data, amount, and customer# with each payment through interface paymentInfo, and accesses the Invoice database to retrieve associated invoice#, date, amount, and customer for each invoice, comparing those two kinds of data to reconcile. Module reconcile writes information, whether invoices were paid or not, to the reconcile database through the interface checkDue. The operation checkDue invokes module sendReceipt if a invoice has been paid, and invokes module sendReminder if a invoice has not been paid and due date has already passed.

Module sendReceipt

Once this module is invoked, it accesses the customer database to get customer information through interface customerInfo and the receipt database to get receipt information through interface receiptInfo. It compares the data and writes results to the reconcile database through interface result.

Module sendReminder

Once this module is invoked, it accesses the customer database to get customer information through interface customerInfo and writes information to the reconcile database through interface result.

Module Output

This module accesses the reconcile database through interface result and send receipt and reminder data to Output Medium according to the control of Master Control.


Subprogram Call

A module can only access the related database through an appropriate interface. Project #1 :B2B Invoice Processing System Architecture - Oct. 3 2000-------------------------------------------------------------------------------------------------------------------------------------------------------------------------"The important decisions in design are not what to put in but what to leave out". – Attributed toTony Hoare by Per Brinch Hansen

19


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------Implicit Invocation

When data in database change through an interface, this interface call related processes through Implicit Invocation methods.

System I/O

This is input/output from outside medium.

Constraints

Computations are invoked implicitly as data is modified, based on an active data model.

Pattern During running the procedure, calling procedures in other modules is a pattern.


20

Subprogram Call

System I/O Implicit Invocation


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------The second Implicit Invocation Design

Design Diagram


21

Control

Payment database Invoice database

Reconcile

Customer databaseRecipt databaseProduct database Complaintdatabase

AddP

ayment

Rconcile

GetP

ayment

GetInvoice

AddR

eceipt

GetP

roduct

AddC

omplaint

IsMem

ber

Customer Interface

Master Control

System I/OImplicit InvocationSubprocedure Call

Input MediumOutput

Medium

Security

CustInfo

CustInfo


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------Style : Implicit Invocation

Data are accessed abstractly and computations are invoked implicitly as data is modified, based on an active data model.

Component : Processes and Data(Repository)

Module Customer Interface

This module receives the input and processes it. It also creates the output. It saves payment information through the AddPayment routine. Through AddComplaint, a complaint can be registered. It also can do product information lookups through GetProduct.

Module Reconcile

This module reconciles payments. The Master Control initiates reconcile with the Reconcile operation. The module accesses invoices via GetInvoice and payments via GetPayment. If an invoice is paid then a receipt is saved through AddReceipt. If an invoice is overdue a notice is sent to the customer.

Module CustInfo

This module accesses customer information from the customer database through CustInfo.

Module Security

This module accesses the customer database to determine if a customer is a member and/or his rights to use the system. This is checked through the IsMember routine.


Subprogram Call

A module can only access the related database through an appropriate interface. Implicit Invocation

When data in database changes through an interface, this interface calls related processes through Implicit Invocation methods.

System I/O This is Input/Output from outside medium.

Constraints

Computations are invoked implicitly as data is modified, based on an active data model.



22

Subprogram Call

System I/O Implicit Invocation


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Trade-Off AnalysisIndividual Analysis-------------------------------------------------------------------------------------------------------------------------------------------------------------------------The Pipe-and-Filter Design

Reliability : (Relative score : 3)Poorer than Implicit Invocation and Object-Oriented.

In pipe-and-filter each element is dependent on its predecessor. Failure in one module normally requires restarting the entire operation.

Performance : Space and Response time (Relative score : 4)Space : Better than Implicit Invocation and Object-Oriented.

In pipe-and-filter elements are terminated when they complete their task. The module keeps no data.

Response time : can be poorer than in Implicit Invocation and Object-Oriented.

Pipe-and-filter has no master control or control module. Each element must do overhead processing. Modifiability (Relative score : 2)Changes in process algorithm : same as Implicit Invocation and Object-Oriented.

Processing in each element is separate and does not affect other elements.

Changes in data representation : Much poorer than Implicit Invocation and Object-Oriented

All data is passed to the next element after processing is complete. Changes in data representation will often require a reanalysis of the proceeding element.

Complexity (Relative score : 1)Object complexity : Poorer than Implicit Invocation and Object-Oriented

Each element is essentially a stand-alone program. Without a master control, each element must do its own overhead processing (garbage collection, fault tolerance, etc)

Interface complexity : Poorer than Implicit Invocation and Object-Oriented.

There is no data hiding or encapsulation. Often elements must receive data not associated to their task and then pass it to the next element.

Portability (Relative score : 4)Better than Implicit Invocation, similar to Object-Oriented.

Small memory footprint and a common operations model allow the pipe-and-filter architecture to be implement on a wide variety of system architectures and operating systems.

Reusability (Relative score : 2)Poorer than Implicit Invocation and Object Oriented.

Complex data transactions make pipe-and-filter elements much harder to transfer.


23


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------The first Object-Oriented Design

Reliability : (Relative score : 4)Better than Pipe-and-Filter, similar to Implicit Invocation.

Designs with a master control can implement system-wide fault tolerance that includes trapping errors within modules and keeping them from affecting the system. Also system check pointing will allow for restarts.

Performance : Space and Response time (Relative score : 4)Space : can be poorer than in Implicit Invocation, poorer than Pipe-and-Filter.

This design has seven modules. Among those, module Payment and Receipt have similar data. If these data can be shared in same storage as in Implicit Invocation, space can be saved and data searching time can be reduced.

Response time : can be better than in Implicit Invocation and Pipe-and-Filter

For example, each module is invoked explicitly and consequently event trigger detecting time is not needed here as in Implicit Invocation. Overhead is centralized in master control. Modifiability (Relative score : 4)Changes in process algorithm : similar to Implicit Invocation and Pipe-and-Filter

Processing is encapsulated. e.g., during reconciling, when compares module Payment data and module Invoice data, it does not matter whether it compares Invoice# first or compares customer# first.

Changes in data representation : better than Pipe-and-Filter, similar to Implicit Invocation

Data is hidden. e.g., storing module Payment data in an array or in linked lists does not affect module Reconcile when comparing those data items. Second OO design is more modifiable than first OO design because second OO has more modules and each simpler module can be modified more easily.

Complexity (Relative score : 3)Object complexity : better than Implicit Invocation, poorer than second OO design, better than Pipe-and-Filter

First OO has 7 modules vs. second OO has 9 modules.

Interface complexity : better than Implicit Invocation and second OO design, better than Pipe-and-Filter.

First OO has more module interfaces than second OO. E.g., for Reconcile module, first OO has 4 interfaces and second OO has 1 interface.

Portability (Relative score : 4)Better than Implicit Invocation, similar to Pipe-and-Filter.

An accepted system architecture allows for this to be implemented in a wide variety of systems.

Reusability (Relative score : 3)Poorer than Implicit Invocation, better than Pipe-and-Filter.

If an object has little interaction with the others, then reusability could be improved. But, in this design, Invoice module has many interactions with Payment module and Reconcile module. So second OO is


24


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------more reusable than first OO.


25


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------The Second Object-Oriented Design

Reliability : (Relative score : 4)Better than Pipe-and-Filter, similar to Implicit Invocation.

Designs with a master control can implement system-wide fault tolerance that includes trapping errors within modules and keeping them from affecting the system. Also system check pointing will allow for restarts.

Performance : Space and Response time (Relative score : 3)Space : can be poorer than in Implicit Invocation, first OO and Pipe-and-Filter.

Repeating of data will use more space than OO-1 and Implicit-Invocation.

Response time : can be better than in Implicit Invocation and Pipe-and-Filter.

Centralized overhead and explicit invocation improve response time. Modifiability (Relative score : 5)Changes in process algorithm : similar to Implicit Invocation and Pipe-and-Filter.

Processing is encapsulated. e.g., during reconciling, when compares module Payment data and module Invoice data, it does not matter whether it compares Invoice# first or compares customer# first.

Changes in data representation : better than Pipe-and-Filter and OO-1, similar to Implicit Invocation.

Data is hidden. e.g., storing module Payment data in array or in linked list does not affect module Reconcile when comparing those data. Simpler modules are more easily modified.

Complexity (Relative score : 4)Object complexity : better than Implicit Invocation, first OO design, and better than Pipe-and-Filter

First OO has 7 modules vs. second OO has 9 modules.

Interface complexity : better than Implicit Invocation and Pipe-and-Filter, poorer than first OO design.

First OO has more module interfaces than second OO. E.g., for Reconcile module, first OO has 4 interfaces and second OO has 1 interface.

Portability (Relative score : 4)Better than Implicit Invocation, similar to Pipe-and-Filter.

An accepted system architecture allows for this to be implemented in a wide variety of systems.

Reusability (Relative score : 4)Poorer than Implicit Invocation, better than Pipe-and-Filter.

If an object has little interaction with the others, then reusability could be improved. In the first OO design, Invoice module has many interactions with Payment module and Reconcile module. So the second OO is more reusable than first OO.


26


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------The first Implicit Invocation Design

Reliability (Relative score : 4)Better than Pipe-and-Filter, similar to Object Oriented.

As in Object Oriented, modular design allows for error trapping and fault tolerance in master control.Performance : Space and Response time (Relative score : 1)Space : can be better than in Object-Oriented , poorer than Pipe-and-Filter.

Data can be shared, e.g. Payment module data and Receipt module data. So this tends to use more space than OO design for natural representation. Concurrent processing in modules uses more space than pipe-and-filter.

Response time : can be more inefficient than in OO design.

Each module can be invoked implicitly with detection of an event trigger, and detection can be costly in time. Also, this design has a critical drawback. The sendReceipt module could be invoked at the same time between payment and reconcile triggering events. This means that it could be possible for sendReceipt module to be in deadlock.

Modifiability (Relative score : 5)Changes in process algorithm : similar to Object Oriented, better than Pipe-and-Filter.

As in first OO design, during reconciling, when compares module Payment data and module Invoice data, it does not matter whether it compares Invoice# first or compares customer# first.

Changes in data representation : better than Object Oriented and Pipe-and-Filter

Data access is abstract, so data representation changes do not affect the other modules

Complexity (Relative score : 5)Object complexity : better than Pipe-and-Filter and Object Oriented.

Fewer modules, control module created by third party.

Interface complexity : better than Pipe-and-Filter and similar to Object Oriented.

Due to implicit calls, interfaces are fairly simple.

Portability (Relative score: 2)Poorer than Pipe-and-Filter and Object Oriented.

Implicit Invocation is still new and not supported on all systems and all languages. In time this will improve.

Reusability (Relative score : 5)Better than OO design and Pipe-and-Filter.

Implicitly invoked modules rely only on the existence of certain externally triggered events. Data storage is done by third party and is not a factor.


27


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------The second Implicit Invocation Design

Reliability (Relative score : 4)Better than Pipe-and-Filter, similar to Object Oriented.

As in Object Oriented, modular design allows for error trapping and fault tolerance in master control.Performance : Space and Response time (Relative score : 1)Space : can be better than in Object-Oriented , poorer than Pipe-and-Filter.

Data can be shared. Optimized database entries would improve space usage. Concurrent processing in modules uses more space than pipe-and-filter.

Response time : can be more inefficient than in OO design.

Greater overhead in event triggers and control module.

Modifiability (Relative score : 5)Changes in process algorithm : similar to Object Oriented, better than Pipe-and-Filter.

Processing is encapsulated in modules. Changes in algorithm do not affect other modules.

Changes in data representation : better than Object Oriented and Pipe-and-Filter.

Data access is abstract, so data representation changes do not affect the other modules.

Complexity (Relative score : 5)Object complexity : better than Pipe-and-Filter and Object Oriented.

Fewer modules, control module created by third party.

Interface complexity : better than Pipe-and-Filter and similar to Object Oriented.

Due to implicit calls, interfaces are fairly simple.

Portability (Relative score: 2)Poorer than Pipe-and-Filter and Object Oriented.

Implicit Invocation is still new and not supported on all systems and all languages. In time this will improve.

Reusability (Relative score : 5)Better than OO design and Pipe-and-Filter

Implicitly invoked modules rely only on the existence of certain externally triggered events. Data storage is done by third party and is not a factor.


28


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Trade-Off AnalysisOverall Analysis-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Each of the five architectural models was evaluated as to their relative abilities to meet each of the nonfunctional requirements as shown in Table 1 above. Each model was given a score ranging from 1-poor to 5-excellent on a subjective basis for each of the six nonfunctional requirements. The nonfunctional requirements were prioritized and given a weighting factor from 10-critical, to 1-lowest importance, also on a subjective basis. The individual scores were multiplied by the weighting factors and totaled for each model. The bottom row of the table shows the relative ranking of each architectural model in relation to how they scored on the weighted nonfunctional requirements with respect to one another. The "best" model as determined by this analysis is the OO-2 model.


29

NonFunctional Requirement Pipe-n-Filter OO-1 OO-2 II-1 II-2Reliability 10 3 4 4 4 4Performance 9 4 4 3 1 1Modifiability 7 2 4 5 5 5Complexity 6 1 3 4 5 5Portability 3 4 4 4 2 2Reusability 2 2 3 4 5 5

102 140 146 130 1305 2 1 3 3

*Note: Scores are on a relative scale of 1 to 5 for each Non-Functional Requirement(5 being the best score)

Relative Rank

Weight

Comparison of Architectural Models Based on Non-Funtional Requirements Scores*

Architectural Model

Total Weighted Score


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Selected Architectural Design-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Based on the trade off analysis of the five alternatives, we have concluded that the best alternative is the second Object Oriented design. We feel this design provides the greatest number of benefits to our customer. The design uses a well-accepted model for implementation and should be able to run on a wide variety of systems. The design should provide adequate speed to meet customer needs without requiring extraordinary amounts of system memory. The design also provides a distributed approach to processing that should make implementation by a team easier and faster. The design also provides a level of fault tolerance that is in line with customer expectations. While the other designs also meet these criteria, we found that that second Object Oriented design provides a solution that will best meet our customer's needs.


30


-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Decision Points-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

During the design phase of the project we were faced with a several kinds of decision points. Most notable were:

Which software architectural design alternatives would be considered; this decision was facilitated by the requirement of the assignment. (Two OO, two II, and one pipe and filter.)

Which modules to implement within each design; we had different opinions on the how to decompose the processing activities. For example, one member felt that it was very important that a separate security module be used.

Which interactions to implement; interactions could be few, but complex or many, but simple. The number of interactions chosen were judged to be sufficient to meet the functional requirements for each of the design alternatives while avoiding excessive detail that would cause complexity which might hinder the understandability of the design.

How to store data; some in our group wanted a simplified approach, while others looked for more optimized methods of data storage.

Which subprocedures to use; again, the approach can be many, simple items or few, complex ones.

Which of the five alternative architectural designs would be selected; this decision was made by making a rational choice among the alternatives based on an analysis of their relative ability to satisfy the nonfunctional requirements of this system.


31

Documents

2chung/SA/B2BIPS.doc · Web viewThe compelling benefits that B2B marketplaces offer for buyers, suppliers and market makers are driving their rapid adoption. Marketplaces are the