The use case model for B2B systems in the electronic commerce product line is depicted in Figure 14.1. There are three actors: Customer, Supplier, and Bank. The customer initiates four use cases: Browse Catalog, Create Requisition, Make Purchase Request, and Confirm Delivery. The supplier initiates three use cases: Process Delivery Order, Confirm Shipment, and Send Invoice. These are the main B2B use cases in the product line; other, less important use cases for querying the servers and monitoring progress have been omitted for brevity.

Figure 14.1. B2B electronic commerce system: use cases

The B2B use cases are briefly described next. In the Browse Catalog use case, the customer browses the various World Wide Web catalogs, views various catalog items from a given supplier's catalog, and selects items from the catalog. In the Create Requisition use case, the customer makes a requisition request. The system has to find a customer contract with the catalog supplier for which there are sufficient operation funds. If a valid contract is found, the system authorizes the requisition and informs the customer. In Make Purchase Request, the customer asks the system to send a purchase request to the supplier.

Although an initial use case analysis might suggest that Create Requisition and Make Purchase Request should be combined into one use case (e.g., Place Requisition), the reason for splitting the two use cases is that Create Requisition applies only to B2B systems, while Make Purchase Request applies to all e-commerce systems.

In the Process Delivery Order use case, the supplier requests a delivery order, determines that the inventory is available to fulfill the order, and displays the order.

In the Confirm Shipment use case, the supplier prepares the shipment manually and then confirms the shipment.

In the Confirm Delivery use case, when the shipment arrives at the customer, the customer confirms the delivery. The operation funds are committed for payment.

In the Send Invoice use case, the supplier sends an invoice to the customer organization. After the customer confirms delivery, the invoice is approved by the customer organization's Accounts Payable department, and an electronic payment request is sent to the customer's bank.

The use case model for B2C systems in the electronic commerce product line is depicted in Figure 14.2. As in B2B systems, there are the three actors; this time, though, they are Customer, Supplier, and Authorization Center. The customer initiates three use cases: Browse Catalog, Check Customer Account, and Make Purchase Request. The supplier initiates three use cases: Process Delivery Order, Confirm Shipment, and Bill Customer.

Figure 14.2. B2C electronic commerce system: use cases

Two of the B2C customer-initiated use cases—Browse Catalog and Make Purchase Request—are identical to B2B use cases; Check Customer Account, however, is different from any of the B2B use cases. In the Check Customer Account use case, the customer enters personal details. The system creates a customer account if one does not already exist. The customer's credit card is checked for validity and sufficient credit to pay for the requested catalog items. If the credit card check shows that the credit card is valid and has sufficient credit, then the customer purchase is approved.

Two of the B2C supplier-initiated use cases—Process Delivery Order and Confirm Shipment—are identical to B2B use cases; Bill Customer, on the other hand, is different. In the Bill Customer use case, the system retrieves the customer's credit card details from the customer account and sends a payment request to the credit card authorization center.

The supplier initiates two optional use cases that could be used in either B2B or B2C systems: Prepare Purchase Order and Deliver Purchase Order (see Figure 14.3). In the Prepare Purchase Order use case, the supplier checks inventory and requests creation of a purchase order for the inventory items that need to be replenished. In the Deliver Purchase Order use case, the system sends the purchase order to the wholesaler. When the delivery order arrives from the wholesaler, the supplier enters the information into the inventory database and approves electronic payment from the supplier bank to the wholesaler bank.

Figure 14.3. Optional purchase order use cases

In the reverse engineering approach, the use cases from the various use case models (see Figures 14.1–14.3) are integrated to produce the product line use case model. Two of the customer-initiated use cases (Browse Catalog and Make Purchase Request) are common to all electronic commerce systems and so become kernel use cases of the product line. Similarly, two of the supplier-initiated use cases (Process Delivery Order and Confirm Shipment) are common to all electronic commerce systems, so they become kernel use cases. On the other hand, two of the customer use cases (Create Requisition and Confirm Delivery) are used only in B2B systems, and a third use case (Check Customer Account) is used only in B2C systems. On the supplier side, one use case (Send Invoice) is used only in B2B systems, and another use case (Bill Customer) is used only in B2C systems. Finally, the two purchase order use cases (Prepare Purchase Order and Deliver Purchase Order) are optional and could be used in either B2B or B2C systems.

The use cases that can be used in only B2B or only B2C systems, but not both, are categorized as alternative use cases. The optional purchase order use cases, which have no such restriction, are categorized as optional use cases. The use case model for the product line is shown in Figure 14.4.

Figure 14.4. Use cases of the electronic commerce software product line

The product line context model depicts three external user classes, depicted as actors: the kernel Customer and Supplier classes, and the optional Wholesaler external user. Furthermore, the Customer actor is specialized into two variant actors: Business Customer and Home Customer. There are two optional external system classes: Authorization Center and Bank. In this product line the context diagram (see Figure 14.6) is very similar to the use case diagram because the external classes correspond to the actors on the use case diagram.

Figure 14.6. Context class diagram of the electronic commerce software product line

This section outlines an approach that uses software agents in the electronic commerce product line. In this example there are client agents and server agents, where each agent defines the business rules for a particular aspect of the electronic commerce problem domain. In this application the client agents are user agents that act on behalf of users and assist users in performing their jobs. To do this, the client agents interact with server agents. The server agents receive requests from client agents. To satisfy a client agent request, a server agent typically interacts with server objects and with other agents.

The use of software agents is illustrated conceptually in Figure 14.7 for B2B e-commerce systems. In the electronic commerce problem, there are two types of client agents: Customer Agent and Supplier Agent. There is one instance of the Customer Agent for each customer and one instance of the Supplier Agent for each supplier. There are several server agents, with many instances of each. The server agents are

Note: This diagram does not use the UML notation.

Figure 14.7. Agent-based B2B electronic commerce system: conceptual view

Customer Agent (see Figure 14.7) is a client agent that acts on behalf of the human customer. Customer Agent assists the customer who wishes to order one or more items from a catalog. It takes the customer's request and interacts with the server agents to further the processing of the customer's selection and to track the status. The customer may select several items from a catalog. When a customer completes catalog selection, Customer Agent acts on behalf of the customer and initiates certain actions. In particular, when the customer makes a catalog selection, Customer Agent sends a requisition request to a Requisition Agent.

Requisition Agent is a server agent that queries various databases and communicates with various agents to ensure the processing of a customer-initiated requisition. It queries the requisition database, contracts database, and operation funds database, as well as communicating with Customer Agent. It sends a contract query to the contracts database to determine if a contract is in place. It sends a funds query to the operation funds database to determine if the funds are in place. If the response to both queries is positive, Requisition Agent authorizes the requisition and sends the requisition status to Customer Agent. Customer Agent sends a purchase request to Delivery Order Agent.

Supplier Agent is a client agent that is instantiated to work with the supplier. It retrieves a delivery order from Delivery Order Agent and helps the supplier fulfill the order. Supplier Agent updates the inventory database, and the order status is sent to Delivery Order Agent and Customer Agent. The customer eventually acknowledges receipt of the goods, and the delivery order is updated to reflect the receipt date.

Supplier Agent sends the invoice to Invoice Agent at the customer organization. When notified by Delivery Order Agent that the goods have been received, Invoice Agent queries the contracts database and the operation funds database (see Figure 14.7). If both responses are positive, Invoice Agent authorizes payment and sends the invoice to the accounts payable database, which updates the account. Invoice Agent then sends the electronic payment request to the customer's bank.

Billing Agent is used in B2C applications to handle the validation and billing of the customer's electronic purchase by interacting with various agents and servers, as well as with the credit card authorization center, as shown in Figure 14.8. Purchase Order Agent (also shown in Figure 14.8) is an optional server agent that addresses the preparation and delivery of a purchase order by interacting with various agents and servers, as well as with the external wholesaler and the bank.

Note: This diagram does not use the UML notation.

Figure 14.8. Agent-based B2C electronic commerce system: conceptual view

Several legacy databases are used in the electronic commerce software product line. Each of these is a stand-alone database residing on a mainframe. These databases need to be integrated into the electronic commerce application by means of a broker technology (see Chapters 2 and 10 for more information on brokers).

The legacy databases in the customer organizations are the contracts database, the operation funds database, the requisition database, the invoice database, and the accounts payable database. The legacy databases in the supplier organizations are the catalog database, the inventory database, and the delivery order database.

To integrate these databases into the electronic commerce application, the server objects that access them need to be database wrapper objects that encapsulate the details of how to read and update the individual databases. Thus, Requisition Server, Contracts Server, Operation Funds Server, Accounts Payable Server, Invoice Server, Catalog Server, Delivery Order Server, and Inventory Server are all database wrapper objects.

In addition, to maintain low coupling between clients, agents, and servers, a broker naming service is used to maintain the location of the specific services. Servers and agents register their services and locations with the object broker. When a service is required, a message is sent to the broker to determine the location of the service. An example is given in Figure 14.9 in which a client agent, Customer Agent, determines from the broker the location of a server agent, Delivery Order Agent. Customer Agent then communicates directly with Delivery Order Agent.

Figure 14.9. Object broker in an agent-based electronic commerce product line

A static model of the problem domain is developed and depicted on a class diagram (see Figure 14.10). Because this is a data-intensive application, the emphasis is on the entity classes, many of which represent the data stored in the legacy databases. The database wrapper objects will map between the conceptual objects and the actual databases. Because each customer and supplier organization is liable to have its own specific legacy database, many individual solutions to the wrapper problem are likely to exist. But if broker and wrapper technology is used, it is possible to have a systematic way of integrating the disparate legacy databases into a general solution.

Figure 14.10. Conceptual static model for e-commerce B2C entity classes

Entity Classes

The electronic commerce software product line has two main groups of applications: B2C applications and B2B applications. The static entity class model for B2C applications is depicted in Figure 14.10, which shows the entity classes for all the important problem domain entities and the relationships among these classes. The classes include home customer classes (Customer and Customer Account), supplier classes (such as Supplier, Inventory, and Catalog), and classes that deal with the customer's order (such as Delivery Order, which is an aggregation of Selected Item).

The static entity class model for B2B applications is shown in Figure 14.11. These classes include business customer classes (such as Requisition, Contract, and Operation Funds), supplier classes (such as Catalog and Inventory), and classes that deal with the customer's order and payment (such as Delivery Order, Payment, and Invoice).

Figure 14.11. Conceptual static model for e-commerce B2B entity classes

The integrated static entity class model for the product line is shown in Figure 14.12. In the product line static model, classes have a second stereotype to depict the reuse category of each class: either «kernel» or «optional». Classes such as Customer and Catalog, which exist in the static models of both B2C and B2B applications, become kernel classes in the product line static model. Classes that appear in only one of the static models, such as Contract (which appears only in the B2B static model) and Customer Account (which appears only in the B2C static model), become optional classes in the product line static model. Entity classes that might exist in either a B2B or a B2C application, such as Purchase Order, also become optional classes in the product line static model.

Figure 14.12. Conceptual static model for e-commerce software product line entity classes

The attributes for the kernel and optional classes are shown in Figures 14.13 and 14.14, respectively. Many of the class attributes need to be defined at configuration or initialization time before a member of the product family can become operational. Included are attributes for the kernel classes, as well as for the optional and variant classes selected for the product line member. For a B2B system, these include attributes for the Customer, Supplier, Contract, Operation Funds, and Bank Account classes.

Figure 14.13. Kernel entity classes for the e-commerce software product line

Figure 14.14. Optional entity classes for the e-commerce software product line

The entity classes determined in the previous section will all be incorporated into the server classes, which will provide the necessary legacy database wrapping as described in Section 14.4.3. User interface classes are needed to interact with the external users—in particular, Customer Interface and Supplier Interface. Furthermore, the software agents described in Section 14.4.2 are also needed.

In the communication diagram for the Browse Catalog use case (Figure 14.15), Customer Interface interacts with Customer Agent, which in turn communicates with Catalog Server. The message descriptions are as follows:

Figure 14.15. Communication diagram for the Browse Catalog use case

In the communication diagram for the Make Purchase Request use case (Figure 14.16), Customer Agent sends a purchase request to Delivery Order Agent and receives a confirmation. The message descriptions are as follows:

Figure 14.16. Communication diagram for the Make Purchase Request use case

In the communication diagram for the next use case, Process Delivery Order (Figure 14.17), Supplier Agent queries Delivery Order Agent for a new delivery order, and Delivery Order Agent selects a delivery order. Supplier Agent checks the inventory and displays the order and inventory information to the supplier via the user interface. The message descriptions are as follows:

Figure 14.17. Communication diagram for the Process Delivery Order use case

In the communication diagram for the Confirm Shipment use case (Figure 14.18), the supplier prepares the shipment manually. The supplier then confirms the shipment by entering the shipping information, including the shipping date. Supplier Agent updates the inventory, and the order status is sent to Delivery Order Agent and to Customer Agent, which displays the order status to the customer. The message descriptions are as follows:

Figure 14.18. Communication diagram for the Confirm Shipment use case

In the communication diagram for the Create Requisition use case (Figure 14.19), Requisition Agent sends a contract query to Contracts Server to determine if a contract is in place. It also sends a funds query to Operation Funds Server to determine if the funds are in place. If the response to both queries is positive, Requisition Agent authorizes the requisition and sends the requisition status to Customer Agent. The message descriptions are as follows:

Figure 14.19. Communication diagram for the Create Requisition use case

In the communication diagram for the Confirm Delivery use case (Figure 14.20), when the shipment arrives at the customer, the customer acknowledges receipt of the goods, and the delivery order is updated to reflect the receipt date. Requisition Agent is also notified. The message descriptions are as follows:

Figure 14.20. Communication diagram for the Confirm Delivery use case

Because the supplier confirmed in the Confirm Shipment use case (see Figure 14.18) that the goods were sent to the customer, Supplier Agent sends the invoice automatically, as shown in the communication diagram for the Send Invoice use case (Figure 14.21). The arrival of the invoice at the customer organization causes the instantiation of Invoice Agent to follow through on the invoice. Invoice Agent subscribes to Delivery Order Agent to be notified when the goods have been received. When notified of the receipt of the goods, Invoice Agent queries Contracts Server and Operation Funds Server. If both responses are positive, Invoice Agent authorizes payment and sends the invoice to Accounts Payable Server, which updates the account. Invoice Agent then sends the electronic payment to the customer's bank server and the invoice status to the supplier. The message descriptions are as follows:

Figure 14.21. Communication diagram for the Send Invoice use case

In the communication diagram for the Prepare Purchase Order use case (Figure 14.22), the supplier requests a new purchase order to replenish low inventory. This interaction involves a new agent, Purchase Order Agent, as well as Purchase Order Server and an interface to the wholesaler, who has to fill the purchase order. The message descriptions are as follows:

Figure 14.22. Communication diagram for the Prepare Purchase Order use case

In the communication diagram for the Deliver Purchase Order use case (Figure 14.23), the supplier receives a new purchase order to replenish low inventory. Purchase Order Agent interacts with Purchase Order Server and Inventory Server, as well as with Bank Server Interface. The message descriptions are as follows:

Figure 14.23. Communication diagram for the Deliver Purchase Order use case

The communication diagram for the Check Customer Account use case (Figure 14.24) addresses the B2C case in which a customer provides the account information, which is checked by Customer Agent in conjunction with Billing Agent. The message descriptions are as follows:

Figure 14.24. Communication diagram for the Check Customer Account use case

An alternative to this use case is that the customer does not have an account, in which case an account will be created.

The communication diagram for the Bill Customer use case (Figure 14.25) addresses the B2C case in which a customer is billed for the purchase. This use case involves Supplier Agent and Billing Agent, as well as electronic billing. Because the supplier confirmed in the Confirm Shipment use case (see Figure 14.18) that the goods were sent to the customer, Supplier Agent sends the payment request automatically, as shown in Figure 14.25. The message descriptions are as follows:

Figure 14.25. Communication diagram for the Bill Customer use case

Each subsystem can be depicted as a package that contains the components in that subsystem, depicted as classes. Each component is depicted with two stereotypes: the component stereotype (what kind of component it is, as specified by the component structuring criteria) and the product line stereotype (the reuse category, such as kernel, optional, or variant). The components in each subsystem are determined by analysis of the communication diagrams for those use cases that are required for B2C and B2B systems, respectively.

One additional consideration is that some of the objects behave differently in B2B systems than in B2C systems. In particular, this situation applies to the Customer Interface and Customer Agent classes. It is therefore necessary to design B2B and B2C variants of these classes. The kernel class is designed as a kernel abstract class, which captures the generalized properties of the class and provides an interface that is inherited by the subclasses. Each subclass then provides additional behavior specific to its needs. The generalization/specialization hierarchy for the Customer Interface and Customer Agent classes is shown in Figure 14.26.

Figure 14.26. Generalization/specialization hierarchies in the electronic commerce software product line

The components are structured into the layered architecture such that each component is in a layer where it needs the services provided by components in the layers below but not the layers above. This layered architecture is based on the Flexible Layers of Abstraction pattern, which is a less restrictive variant of the Layers of Abstraction pattern in which a layer can use the services of any of the layers below it, not just the layer immediately below it. This architecture facilitates adaptation of the electronic commerce software product line architecture to derive individual application members of the product line. User interface components at the user interface layer communicate only with client agent components. Client agent components communicate with server agent components and server components. Server agent components communicate with server components. Applying the component structuring criteria, the following components, organized by subsystem and layer are determined:

Supplier Organization Subsystem

Supplier Organization Subsystem (see Figure 14.27) consists of the kernel supplier components, together with the optional Billing Agent and Customer Account Server components, which are used only in B2C systems:

• Layer 1: Server components. There are three kernel server components (Catalog Server, Delivery Order Server, and Inventory Server) and one optional server component (Customer Account Server).

• Layer 2: Server agent components. There are two server agents: the kernel Delivery Order Agent and the optional Billing Agent.

• Layer 3: Client agent components. There is one kernel client agent: Supplier Agent.

• Layer 4: User interface component. There is one kernel user interface component: Supplier Interface.

Figure 14.27. Layered architecture: Supplier Organization Subsystem

Home Customer Subsystem

Home Customer Subsystem (see Figure 14.28) consists of the variant B2C Customer Interface and B2C Customer Agent components:

• Layer 1: Server components. There are no server components.

• Layer 2: Server agent components. There are no server agent components.

• Layer 3: Client agent components. There is one variant client agent: B2C Customer Agent.

• Layer 4: User interface component. There is one variant user interface component: B2C Customer Interface.

Figure 14.28. Layered architecture: Home Customer Subsystem

Business Customer Organization Subsystem

Business Customer Organization Subsystem (see Figure 14.29) consists of the variant B2B Customer Interface and B2B Customer Agent components, as well as several optional components that are used only in B2B systems:

• Layer 1: Server components. There are several optional server components: Requisition Server, Contracts Server, Invoice Server, Operation Funds Server, and Accounts Payable Server.

• Layer 2: Server agent components. There are two optional server agents: Requisition Agent and Invoice Agent.

• Layer 3: Client agent components. There is one variant client agent: B2B Customer Agent.

• Layer 4: User interface component. There is one variant user interface component: B2B Customer Interface.

Figure 14.29. Layered architecture: Business Customer Organization Subsystem

Purchase Order Subsystem

Purchase Order Subsystem (see Figure 14.30) consists of optional components that exist at two layers and can be used with either B2B or B2C systems:

• Layer 1: Server components. There is one optional server component (Purchase Order Server) and one optional system interface component (Wholesaler Interface).

• Layer 2: Server agent components. There is one optional server agent: Purchase Order Agent.

• Layer 3: Client agent components. There are no client agents.

• Layer 4: User interface component. There is no user interface component.

Figure 14.30. Layered architecture: Purchase Order, Bank, and Authorization Center subsystems

To handle the variety of communication between the components in the product line architecture, several communication patterns are applied:

The concurrent communication diagrams for the B2C and B2B systems, shown in Figures 14.31 and 14.32, respectively, depict the concurrent components in the major applications that can be derived from the electronic commerce software product line architecture. They represent integrated generic communication diagrams determined from the individual communication diagrams supporting the use cases for B2C and B2B systems, respectively.

Figure 14.31. Concurrent communication diagram for the B2C electronic commerce system

Figure 14.32. Concurrent communication diagram for the B2B electronic commerce system

To keep the design simple, the Synchronous Message Communication with Reply pattern has been widely used in this case study. As described in Chapter 10, however, this approach has the disadvantage of suspending the client while it awaits a response from the server. An alternative design to avoid suspending the client is to use the Asynchronous Message Communication with Callback pattern. Examples of asynchronous communication are widely used in the microwave oven and factory automation product line case studies (Chapters 13 and 15, respectively).

The design of the components and component interfaces within the overall product line architecture is depicted in Figures 14.33 through 14.36. Each component has one or more ports, with provided interfaces, required interfaces, or both. In the four-layer architecture, each client user interface component has one required port, which supports a required interface. Each server has one provided port, which supports a provided interface. The agents have ports with both required and provided interfaces because they act as intermediaries between the clients and agents. Whereas clients and servers each have one port through which they can communicate, agents communicate through multiple ports because each one needs to communicate with several components.

Figure 14.33. Kernel software architecture of the economic commerce software product line

Figure 14.36. Kernel architecture and optional purchase order components

The kernel components and ports are depicted in the kernel software architecture diagram in Figure 14.33. In Customer Subsystem, which consists of two kernel abstract classes, Customer Interface is a client and thus has only a required port. Customer Agent has both required and provided ports. Both of these components capture the commonality among all customers, home and business. In Supplier Organization Subsystem, the Supplier Interface and Supplier Agent components provide the same functionality in both B2B and B2C systems, and the three servers also provide common functionality. Both Supplier Agent and Delivery Order Agent also provide functionality accessed via ports, which are used by different B2B and B2C components.

Consider the software architecture for B2C systems. In Home Customer Subsystem, both B2C Customer Interface and B2C Customer Agent are variant components, which are specialized from the kernel components to provide additional B2C functionality, as shown in Figure 14.34. B2C Customer Agent also adds two required ports, which support required interfaces to two optional components in Supplier Organization Subsystem that operate only in B2C applications: Billing Agent and Customer Account Server. To bill for customer purchases from the supplier, Supplier Agent communicates through a connector that joins its RPayment required port to Billing Agent's PBillPayment provided port. For the subscription/notification service, a bidirectional connector joins the RSubscription required port of the subscriber (Billing Agent) to the PSubscription provided port of Delivery Order Agent. The connector is bidirectional because Billing Agent sends a subscription message to Delivery Order Agent, which later responds with the notification. Customer payment is made by credit card, necessitating the optional Authorization Center Interface component.

Figure 14.34. Software architecture of the B2C system

In the software architecture for B2B systems (see Figure 14.35), Business Customer Organization Subsystem is much more complex than Home Customer Subsystem. In addition to variant B2B Customer Interface and B2B Customer Agent components, there are several optional agent and server components added to provide the B2B functionality. B2B customer billing is handled differently, with the optional Invoice Agent handling customer payment. For this purpose, a connector now joins Supplier Agent's RPayment required port to Invoice Agent's PInvoicePayment provided port. In B2B systems, it is Invoice Agent that subscribes to Delivery Order Agent's subscription/notification service. Payment is made by electronic funds transfer via a request to the optional Bank Interface component.

Figure 14.35. Software architecture of the B2B system

If optional purchase order (PO) functionality is needed in either B2B or B2C systems, variant PO Supplier Interface and PO Supplier Agent components provide the additional PO functionality to initially make the order and then later install the delivered items. An optional Purchase Order Subsystem is also added, consisting of three optional components, as shown in Figure 14.36. Electronic payment is made by Purchase Order Agent via the optional Bank Interface component, which is also used in B2B applications.

The ports and interfaces for each component are described next. The component ports and interfaces for Customer Agent are depicted in Figure 14.37. A generalized interface is shown for Customer Agent, which is specialized to the interfaces for B2C Customer Agent and B2B Customer Agent, respectively. There is a corresponding Customer Agent component to realize each interface, with the ports and interfaces depicted on the customer agent component diagram. Each Customer Agent component has a bidirectional port to communicate with Customer Interface, thereby allowing for asynchronous responses from the agent. All other ports have required interfaces because Customer Agent is a client agent that initiates communication with server agents as well as with server components.

Figure 14.37. Component ports and interfaces for Customer Agent

Billing Agent, which is an optional server agent, has five ports because it communicates with five components, as shown in Figure 14.38. It receives client requests from Customer Agent through the PBillingAgent port, which supports a provided interface called IBillingAgent. In its role as a client, Billing Agent has two required interfaces for communication with Customer Account Server and Authorization Center Interface. Its interaction with Supplier Agent and Delivery Order Agent has already been described.

Figure 14.38. Component ports and interfaces for Billing Agent

Delivery Order Agent is a kernel server agent that operates in both B2B and B2C applications. However, it is designed to be versatile so that it can operate with different components, as shown in Figure 14.39. Delivery Order Agent has one provided interface to receive requests from Supplier Agent and another to receive requests from Customer Agent, either the B2B or B2C variant. It provides a subscription service via a bidirectional port to allow asynchronous responses to its subscribers. Finally, Delivery Order Agent has a required interface to allow it to be a client to Delivery Order Server.

Figure 14.39. Component ports and interfaces for Delivery Order Agent

Supplier Agent (see Figure 14.40) provides the same functionality for B2B systems and B2C systems. It receives supplier requests via the PSupplierAgent port, which supports a provided interface called ISupplierAgent. However, PO Supplier Agent can additionally provide optional functionality for purchase orders. This functionality is handled through a specialized provided interface for PO requests called IPOSupplierAgent and a required interface (IPOAgent) to communicate with Purchase Order Agent. The component and port interfaces for the other optional agents (Requisition Agent, Purchase Order Agent, and Invoice Agent) are designed in a similar way, as depicted in Figure 14.41.

Figure 14.40. Component ports and interfaces for Supplier Agent

Figure 14.41. Component ports and interfaces for other optional agents

The component ports and interfaces for the server components—both kernel (Figure 14.42) and optional (Figure 14.43)—are all handled in the same way; each component has one port and provided interface through which the services are accessed. The clients of the server invoke the appropriate services synchronously.

Figure 14.42. Component ports and interfaces for kernel server components

Figure 14.43. Component ports and interfaces for optional server components

Figure 14.44 shows the ports and interfaces for the user interface and system interface components. The required ports and required interfaces for the variant Customer Interface user interface components (see Figure 14.44), are specialized from a generalized ICustomerAgent interface into B2C and B2B versions (see Figure 14.37). The optional system interface components (Bank Interface, Authorization Center Interface, and Wholesaler Interface) each support one port with a provided interface.

Figure 14.44. Component ports and interfaces for interface components