Design of a Framework for Electronic Commerce Brokers

Nadia Bouassida, Thouraya Ayadi, Hanêne Ben-Abdallah, Faïez GargouriDépartement d’Informatique, Laboratoire LARIS, Faculté des Sciences Economiques et de

Gestion de Sfax, Route de l'aérodrome km 4,Bp 1088-3018 Sfax, TunisieNadBouassida@yahoo.fr, {Thouraya.Ayadi, Faiez.Gargouri,

Hanene.BenAbdallah}@fsegs.rnu.tn

AbstractThe abundance of specialized electronic brokers

(e-brokers) combined with the complexity of theirdesign phase reinforce the need for a reusabledesign for e-brokers.

This paper presents an e-broker framework: areusable object-oriented design that capturesseveral e-brokers’ behaviours. The framework isexpressed in F-UML, a design language thatvisually distinguishes between the parts common inall e-broker applications and the parts adaptablewhen deriving a specific e-broker from theframework. The paper briefly presents F-UML. Itthen focuses on the design process. Finally, ithighlights the difficulties, the advantages and limitsof the proposed design method.

Keywords: e-commerce broker, framework design,F-UML, framework design process.

1. Introduction

The abundance of suppliers and customers onthe web makes the customers unable to locaterapidly the goods and services they seek at a goodprice and the suppliers unable to reach thecustomers. The existence of an electroniccommerce broker (e-broker) matching customerswith providers is therefore vital to electroniccommerce.

Electronic commerce brokers cover a diverserange of commerce activities including [8]:-locating goods and services a customer needs,-helping suppliers to make potential customersaware of their products,-negotiating a transaction,-processing all the steps of a transaction, and-tracking the product delivery.

The abundance of specialized e-brokerscombined with the complexity of their design phasereinforce the need for a reusable design for e-brokers. With a reusable design, the development ofa new e-broker consists in adapting the reusabledesign, instead of composing one from thebeginning.

Frameworks are a promising softwaretechnology that facilitates design reuse. Theypromise increased productivity, shorterdevelopment times and a higher quality ofapplications, since they allow designers andimplementers to reuse their previous experience inproblem solving at the design and code levels [9].

A framework represents a software architecturethat captures several applications’ behaviors in aspecific domain. An object-oriented framework is aset of concrete and abstract classes with theirinteractions, designed for a particular applicationdomain. It represents a flexible design that can beextended to develop new applications by “adapting”the framework abstract classes. In general, anobject-oriented framework has parts that could becustomised through inheritance (sub-classing) andparts that could be parameterised (instantiation).

A framework design method must provide for adesign language as well as a design process.Several design languages have been proposed forobject-oriented frameworks (c.f. [6].) We haveproposed a design language, called F-UML [3],based on the following four UML diagramsextended with tags and graphical annotations: a usecase diagram, a class diagram, a pattern diagram [7]and a sequence diagram.

The main motivations leading to the extensionsof the original UML notation: 1) to distinguishvisually among the fixed components and thevariable components of a framework; 2) to facilitatethe understanding of a framework; 3) to guide theuser in instantiating a framework when applied to aspecific application in the framework domain.

As for the design process for frameworks, itmust guide the designer in determining the variableaspects (called hot-spots [16]) in which differentapplications may differ and the frozen spots thatremain unchanged in all the applications of theframework domain. In addition, to facilitatepotential reuse of a given framework, the designprocess should guide the developer in deciding

Proceedings of the First IEEE International Conference on Cognitive Informatics (ICCI’02) 0-7695-1724-2/02 $17.00 © 2002 IEEE

whether a hot-spot is a blackbox or a whitebox hot-spot [16].

The framework design process can be eitherbottom-up [16] or top-down [12]. Bottom-updesign works well where a framework domain isalready well understood, e.g., after some initialevolutionary cycles. In this case, the design processstarts from a set of existing applications andreplaces problematic solutions by applying thedesign patterns (c.f., [11], [13]). On the other hand,top-down design is preferable where a frameworkdomain has not yet been sufficiently exploredwhile the target domain of the framework is wellunderstood. In this case, the design process startsfrom a domain analysis and then constructs aframework design.

This paper aims at evaluating our design methodin the domain of e-commerce. It applies ourbottom-up design process to derive a framework fore-brokers. First, it presents four specialized e-brokers designed in UML (antique broker[1], autobroker[2], book broker[10] and Low price broker).Secondly, it applies three unification phases toconstruct a framework design for generic e-brokersin F-UML. Finally, the paper highlights thedifficulties, the advantages and limits of theproposed design method.

2. The F-UML design method

A framework is defined as a system composedof[6]:-A framework core (frozen-spot) that is common toall applications that may be derived from theframework. It describes the software architecture.-Hot-spots that constitute the points of variability inthe framework. They allow the framework to beadapted to a particular application. Schmidt [16]defines two types of hot-spots: A whitebox hot-spotthat can be adapted by implementing some of theframework methods or classes. On the other hand, ablackbox hot-spot that can be adapted to aparticular application by selecting classes from thelibrary accompanying the framework.

A hot-spot (blackbox or whitebox) is thereforevery important since it offers points of variabilityand flexibility to a framework. Hence, its designshould be expressed clearly in order to avoid anyframework misuse.

2.1 The framework design language F-UML

The design language F-UML[3] increases theexpressiveness of UML for frameworks and guidesthe design reuse. Tags and graphical annotationshave been added to UML diagrams in order to

distinguish between the core of the framework andits variable parts.In F-UML, a framework design consists of thefollowing four diagrams:1. A use case diagram determines the frameworkscope, objectives and the domain limits. Table 1shows the extensions added to the UML notationand their objectives.2. A class diagram describes the staticarchitecture of the framework. Table 2 summarizesthe extensions to the UML notation.3. A pattern diagram shows the roles of theframework classes and helps in understanding theinteractions among the objects of the framework. Itis obtained from the class diagram by filtering outthe details inside the classes and by matching theresulting structure to a set of design patterns.4. Sequence diagrams describe potential objectinteractions. The sequence diagram in F-UML usesthe same notation as the sequence diagramproposed by [6], where the tag {optional} can marka message.

Graphical

Notation

Explanation Objective

-A highlighted use

case border

-A highlighted actor

border

to show the

framework

core

-An actor filled in gray

-A use case filled in

gray

to show the

framework

hot-spot

Table 1. F-UML extensions to UML use casediagrams

2.2 The F-UML design process

The F-UML design process [4] constructs adesign solution from a set of available applications.It helps the framework designer to structure theframework by determining its core, blackbox andwhitebox hot-spots. It starts from severalapplication designs and goes through threeunification steps (In fact, Roberts[14] states thatthree applications sufficiently represent theirdomain): 1. Design of the framework use case diagram:The unification process first extracts use casescommon to all the applications and puts them as theframework core. Secondly, it extracts the differentuse cases and puts them as hot-spots of theframework.2. Design of the framework class diagram: Theunification process first extracts classes common toall the applications and puts them as the frameworkcore. Secondly, it extracts the different classes and

Proceedings of the First IEEE International Conference on Cognitive Informatics (ICCI’02) 0-7695-1724-2/02 $17.00 © 2002 IEEE

puts them as hot-spots of the framework. Theframework designer is probed to decide whetherthese latter are whitebox or blackbox hot-spots.3. Design of the framework sequence diagram:The unification process extracts optional messagesand puts them as hot spots.

The pattern diagram is not obtained byunification. It is deduced from the class diagramsobtained in step 2 by applying the design patterns.

In the above unification processes, we use a setof unification rules and a dictionary that defines thesemantic equivalences between nouns of classes,attributes and methods, the generalization-specialization, the includes and the extendsrelations between class nouns. The notion of thesemantic equivalence defined in the dictionary isbased on a linguistic criteria.

Graphical

Notation

Explanation Objective

A highlighted

class border

to show the

framework core

A square filled

in black at the

top-right

corner of a

class

to show the

framework

blackbox hot-spot

A square filled

in gray at the

top-right

corner of a

class

to show that this

class with all its

inheriting classes

are in the

framework

whitebox hot-spot

A circle filled

in gray in front

of a method’s

name

To show a virtual

method

The tag

undefined for a

method with a

varying

signature

To show a

method with an

undefined

signature

The tag{extensible} ina class

To show that the

class can be

adapted by

adding/removing

attributes/methods

The UMLconstraintincomplete ona relation(generalization,aggregation,association)

To show that the

framework may

be adapted by

adding other

related classes.

Table2. F-UML extensions to UML class diagrams

Unification process of the use case diagramsThe design of the framework use case diagram

through unification is guided by the following threerules :1. If an actor (a use case) appears in all theapplications’ use case diagrams with equivalentnames, then this actor (use case) describes one ofthe essential needs in any application and, thus, it isadded to the framework core.2. If an actor (a use case) does not appear in allthe applications, then it is added to the frameworkas a hot-spot.3. The relations of the use case diagram in theframework originate from two sources :a) Relations transferred from the applications: if

two actors (use cases) in the framework arerelated in any application then their relationsare transferred in the framework.

b) New relations (generalization, includes,extends) between actors/use cases originatingfrom different applications are automaticallyadded by using the dictionary.

Unification process of the class diagramsThe unification of the applications implies that

whenever the applications contain duplicate,complementary or related descriptions of the sameconcept, these descriptions should be appropriatelymerged to form a single concept in the framework.The design of the framework class diagram throughunification is guided by the following seven rules :

1. If there is a set of classes, one from eachapplication, with equivalent names (e.g. Person,Individual) anda) if they have the same attributes and methods,

then a representative class is added to theframework core.

b) if they have distinct attributes and/or methods,the names are therefore in homonymy, thenthey are all added to the framework as hot-spots and the developer has to change theirnames to resolve the ambiguity.

c) if they have attributes and/or methods inintersection, then a class is added to theframework core that contains the commonattributes and methods with the tag

{incomplete}

Method()

{extensible}

Method(undefined)

Proceedings of the First IEEE International Conference on Cognitive Informatics (ICCI’02) 0-7695-1724-2/02 $17.00 © 2002 IEEE

{extensible} to indicate that we can add orremove attributes and methods.

d) if they have attributes and/or methods inintersection with other attributes and/ormethods in conflict1, then a class is added tothe framework core containing the commonattributes and methods with the tag{extensible}.

In addition, for the cases c) and d), new classesinheriting from the already added class could beadded according to the two following rules:- For each application, if its class has a significantnumber of attributes and methods (with respect tothe already added class), then an inheriting class isadded to the framework with the additionalattributes and methods. The added class hierarchy isa whitebox hot-spot since the class interface maychange; further, if the designer decides that theinheriting classes do not represent all the domain,then the inheriting relation is tagged with{incomplete};

- For each application, if its class has a significantnumber of attributes and methods (with respect tothe already added class), then an inheriting class isadded to the framework with the additionalattributes and methods. The method in conflict hasa corresponding method in the class of theframework core that has the same name, and anundefined signature, it is a virtual method, theattribute in conflict has a corresponding attribute inthe class of the framework core that has the samename and the more general attribute type. Theadded class hierarchy is a whitebox hot-spot sincethe class interface may change; further, if thedesigner decides that the inheriting classes do notrepresent all the domain, then the inheriting relationis tagged with {incomplete};

A class A has a significant number of attributesand methods with respect to another class B, if thenumber of attributes and methods that appear onlyin A divided by the number of attributes andmethods that appear in A is more than 50%.

2. If there is a set of classes, one from eachapplication, with names that constitute a variationof a concept. (e.g., employee-contractual,employee-permanent, employee-vacationer), anda) if they have equivalent attributes and methods,

then a representative class is added to theframework core, having the most genericname;

1 A method in conflict is a method that exists in allthe applications with equivalent names but with adifferent signature. An attribute in conflict is anattribute that exists in all the applications withequivalent names but with a different type.

b) if they have attributes and methods inintersection, then they are all added to theframework as inheriting classes to a newabstract class. The abstract class will have asattributes and methods the attributes andmethods common to these classes. Theframework developer has to decide whetherthis class hierarchy is a whitebox or a blackboxhot-spot; further, if the designer decides thatthe inheriting classes do not represent all thedomain, then the inheriting relation is taggedwith {incomplete};

c) if they have attributes and methods inintersection with other attributes/methods inconflict, then the classes are added to theframework as inheriting classes to a newabstract class. The abstract class will have theattributes and methods common to theseclasses, a virtual method representing themethods in conflict (having the same name andan undefined signature), and an attributerepresenting the attribute in conflict (having thesame name and the more general attributetype). The newly added hierarchy represents awhitebox hot-spot in the framework; further, ifthe designer decides that the inheriting classesdo not represent all the domain, then theinheriting relation is tagged with {incomplete}.

d) if they have distinct attributes and/or methods(i.e., their names are in homonymy), then theyare all added to the framework as hot-spots andthe developer has to change their names inorder to resolve the ambiguity and decide thetype of each hot-spot.

3. If there is a set of classes with one classrepresenting a composition of other applicationclass names (e.g., car, engine), and

a) if they have equivalent attributes and methods,then they are equivalent and only thecomposite class is added to the frameworkcore;

b) if they have attributes and methods inintersection, then the composite class and thecomponent classes are added to the frameworkwith an aggregation relation between them, andthe attributes and methods in intersection areput in the component class and removed fromthe composite. The developer must decidewhether the added classes represent a whiteboxor blackbox hot-spot and if the aggregationrelation should be marked {incomplete};

c) if they have attributes and methods inintersection with other attributes/methods inconflict, then rule 3.b is applied on thecommon attributes/methods, and a virtual,undefined-signature method is added to thecomposite class for each method in conflict,

Proceedings of the First IEEE International Conference on Cognitive Informatics (ICCI’02) 0-7695-1724-2/02 $17.00 © 2002 IEEE

and a general type attribute is added to thecomposite class for each attribute in conflict;

d) if they have distinct attributes and methods,then the composite class and the componentclasses are added to the framework with anaggregation relation between them. Thedeveloper must decide whether the addedclasses represent a whitebox or blackbox hot-spot and if the aggregation relation should bemarked {incomplete};

4. The generalization relations among classnames are dealt with in a manner similar to theaggregation relation (rule 3).

5. If a set of classes have names completelydifferent (not equivalent, not composed, not avariation of a concept), then they are added to theframework as hot-spots. The developer must decideon the type of each hot-spot.

6. If two or more classes are transferred in theframework, all their relations (aggregation,inheritance, association) will also be transferred inthe framework.

7. To decide whether a class is a blackbox or awhitebox hot-spot: If the applications contain allpossible variants of the super class (components ofthe composite class) and the inheriting (component)classes have a fixed and

�

� defined set of attributesand methods, then the class is a blackbox hot-spot;otherwise the class is a whitebox hot-spot.

Unification process of sequence diagramsThe Framework message sequence diagrams are

obtained by taking the “union” of all the sequencediagrams of the applications and marking anymessage as {optional} if it does not appear in all theapplications.

3. The design of four E-Brokers

To illustrate our design process, we haveconsidered four applications of e-brokers: a bookbroker called Tunisia Book[10], an auto brokercalled Auto Broker[2], a broker for antiquitiescalled Antique Broker[1], and a person-to-persontrading broker called Low Price Broker inspiredfrom the Ebay [19].

3.1. Tunisia BookThe Tunisia Book broker is a broker for selling

and buying books, magazines, etc, ...

3.1.1. The Use case Diagram

As illustrated in Figure 1, the actors that use thebrokerage services are the Consumer and theProvider. One of the functionality assumed by thesystem is the consumer/provider subscription to thebroker in order to benefit from services. Anotherfunctionality is the provider registration of itsproducts for sale and the consumer product requestsubmission. The consumer has to determine thebook kind, the book title and the maximal price.The function of the broker is to search for the bestoffer and to return the list of books found. Theconsumer evaluates the list of found offers anddecides which books to buy and pays for them.

Select an offre

Consumer Provider

Registrates a product

Subcription to the services of a

Broker

Determine book kind

Determine Max price

« include » « include »

Determine book title

« include »

Payment Payment with credit card

«extend »

Makes request

« include »

Search

Figure 1. The use case diagram of Tunisia Book

3.1.2. The Class DiagramAs illustrated in Figure 2, the Subscription,

Registration and Search are represented byassociation relations between the respective classes.In addition, the Broker manages the Consumer andProvider accesses via login names and passwords(in the Access class). Furthermore, the consumersevaluation and selection of found offers are alsorepresented by aggregation between the Consumerclass and the Book class.

The Basket class contains the list of bookschosen by the consumer. Each Provider has acertification, this is represented by an aggregationrelation. The Provider and the Consumer possess aCredit Card, thus there is an aggregation betweenCredit card class and Provider class and betweenCredit card class and Consumer class.

3.1.3. Sequence DiagramsAs Figures 3.a and 3.b indicate, the Consumer

and Provider subscriptions and identifications areindependently sent to the Broker. Figure 3.c showsthe methods involved during the search for andbuying of books. Finally, Figure 3.d shows thepayment process.

Proceedings of the First IEEE International Conference on Cognitive Informatics (ICCI’02) 0-7695-1724-2/02 $17.00 © 2002 IEEE

Book id_bok : int des_bok : string kind_bok : string hous_ed : string price_min : float quantity : int

getid_bok() getdes_bok() Getkind_bok() Gethous_ed() getprice_min() getquantity() CreateBook()

broker

Search (kind : string, title:string, price : float)

Subscribe()

consumer Id : int Firstname : string LastName : string Adress : string Email : string City : string State : string

getId_con() getFirstname() getLastName() getAdresse() getEmail() getVille() evaluateBook(Book): int selectBook(Book) SubmitRequedt(title : string, price : float, kindBook : string)

1..*

1..*

1..*

1..*

0..* 0..*

1..*

0..*

certification Id_cer : int Dat_cer : date getId_cer() getDat_cer()

Credit card card_id : int prop_nam : string date_exp : d tnumber_card : int

getCard_id() getprop_nam() getDate_exp() getNumber_card()

Basket date : date

addBook() deleteBook()

Order OerderDate : date PriceBooks : float Free : float Total : float getOerderDate() getPriceBooks() getFree() getTotal () createOrder()

Payement ValidatePayement()

{subset}

0..1

Select

Evaluate

acces login : string pwd : string getLogin () getPwd()

Subscribe

provider Id : int FirstName : string LastName : string Email : string City : string Address : string State : string

getId() getFirstName() getLastName() getEmail : string getCity() getAddress() getState()

Subsribe

Search

Possess

Verify

1..*

Figure 2. The class diagram of Tunisia Book

Subscribe() Subscribe()

: Consumer : Broker

: Provider : Consumer : Acces : Provider

getLogin() getLogin()

getPwd() getPwd()

Fig. 3.a. Subscription of users Fig. 3.b. User Identification

:Broker : Consumer

EvaluateBook(Book)

SubmitRquest()

[X] AddBook()

: Basket

[X] : A good book [Y] : Don’t decide to buy

:Book

Research()

SelectBook(Book)

[Y] DeleteBook()

: Consumer : Order

CreatOrder()

: payement

ValidatePayement()

Fig. 3.c. Research and buy Fig. 3.d. Payment

Figure 3. The sequence diagrams of Tunisia Book

3.2. Auto BrokerAuto broker is a broker for searching and selling

cars.3.2.1. The use case Diagram

As illustrated in Figure 4, the actors that use thesystem are Buyer and Seller. Unlike Tunisia book,this broker does not require a subscription and doesnot handle payment. In addition, we notice a strongsimilarity between the use case diagrams in Figure1 and Figure 4.

Seller Buyer

Enter sources of Information

Evaluate Auto choices

Determine max price

Determine auto type Determine

auto option

« include »

« include » « include »

Search auto

Determine Initial Parameters

« include »

Figure 4. The use cases diagram of Auto Broker

3.2.2. The Class DiagramCompared with the previous broker class

diagram, the class diagram of Auto broker (Figure5) also has the classes Broker, Seller/Provider andBuyer/Consumer. In addition, it has the class Autoand its aggregate classes: Financial Data, Optionsand Technical Details.

Option

recorderType : string

getRecorderType() getOption()

Technical Details

horsepower : float acceleration : float turning raduis : float engine-noise : float

getHorsepower() getAcceleration() getTurningRaduis() getEngineNoise() getTechnicalDetails()

Auto

size : int color : string shape : string

dimension : string style : string NbrofDoors : int

getId_auto () getVehiculeCost() getSize() getColor() getShape() getDimension() getStyle() getNbrofDoors() CreateAuto()

Id_auto : int VehiculeCost : float

Financial Data

MaintenaceCost : float LoanAvailability : float InterestRates : float

getmaintenaceCost() getLoanAvailability() getInterestrates() getFinancialData()

Seller Broker

SearchAuto(type : string, option, price : float)

Buyer

getBuyerPreferences() EvaluateAutoChoices(Auto)

1..*

1..*

0..*

0..*

1..* 1..*

1.* 1..*

1..*

Consultation Posess

Search

Request Belong to

Figure 5. The class diagram of Auto Broker

3.2.3. The Sequence DiagramsCompared to the previous broker, here a buyer

can search for an auto with a prior subscription(Figure 6.b).

: Seller : Auto

CreateAuto()

: Option : Financial Data : Technical Details

getOption() getFinancialData() getTechnicalDetails()

Fig. 6.a. Description Autos for sale

: Buyer : Broker

getBuyerPreference()

SearchAuto()

EvaluateAuto()

: Auto

Fig. 6.b. Search and evaluate autos

Figure 6. the sequence diagrams of Auto Broker

Proceedings of the First IEEE International Conference on Cognitive Informatics (ICCI’02) 0-7695-1724-2/02 $17.00 © 2002 IEEE

3.3. Antique Broker

Antique Broker is a broker for buying andselling antique items such as antique watches, cars,etc.

3.3.1. The use case diagramAs illustrated in Figure 7, the main difference

from the previous application is in the Payment usecase which is extended by other use cases.

Seller Buyer

Enter Information Describing Item wanted

Subscription

Evaluate choices

Enter Information Describing Item for Sale

Find Potential Matches

Payment

Payment with personal check

Payment with wire transfer

«extend»

Payment with credit card

«extend»

Payment with certified check/money

«extend»

«extend»

«include»

Figure 7. The use case diagram of Antique Broker

3.3.2. The Class diagramAs illustrated in Figure 8, the common classes

with the previous applications are Broker, Buyerand Seller. The main difference is that the classesBuyer and Seller which are inheriting classes of theclass Part To Transaction.

Collector addItemWanted(AntiqueItemWanted) DeleteItemWanted(AntiqueItemWanted)

Part To Transaction

Name() : String PassWord() : string Address() : string

getName() getPassWord() getAddress()

AntiqueItemsForSale

Reference : string description : String Price : double Condition : int Year : int

getDescription() : string getPrice() : double getCondition() : int getYear() : int CreateItemsForSale()

Broker subscribe() addBuyers(Buyer) addseller(Seller) findMatches(key : string)

Buyer

getItemsWanted() evaluateMatch(AntiqueitemForSale) : int

AntiqueItemWanted

Reference : string description : string priceRange : Range conditionRange : range yearRange : Range

getDescription() : String

Seller

���

���

Order OederDate : date PriceItems : float Free : float Total : float

getOrderdate() getPriceItems() getFree () getTotal () createOrder()

1..*

1..*

Payement

validatePayment()

Check Wire transfert Money Credit card card_id : int prop_nam : string date_exp : date number_card : int

getCard_id() getprop_nam() getDate_exp() getNumber_card()

���

Subscribe Subscribe

Research Matches

���

Pocess Consult

����

Figure 8. the class diagram of Antique Broker

3.3.3. The sequence diagramsSimilar to the application Tunisia Book, to buy

and sell an item the users (Consumer/Provider) firstsubscribe to the brokerage service (Figure 9.a). Inaddition, a buyer can first make a request, thenevaluate offers found (Figure 9.c) and finallyvalidate the payment of the items selected (Figure9.d)

Subscribe() Subscribe()

: Buyer : Broker

: Seller

addSeller() addBuyer()

: Buyer : Part To Transaction : Seller

getName() getName()

getPassword() getPassword()

Fig. 9.a: Subscription of users Fig. 9.b. User Identification

: AntiqueItemWanted : Buyer

geDescrition()

FindMatches()

: Broker

EvaluateItemsMaches()

: Collector

[x]AddItemWanted(ItemWanted)

[x] : A good Item [y] : Cancel Buy

[y]DeleteItemWanted(ItemWanted)

Fig. 9.c. Search and evaluation

: Order : Buyer

CreateOrder()

: Payement

Validatepayement()

Fig. 9.d. Payment

Figure 9. the sequence diagrams of Antique Broker

3.4. Low Price Broker

Low Price Broker is a person-to-person brokerthat allows a buyer to search and negotiate severaltypes of items. It resembles the brokers Ebay(www.ebay.com), Ibazar(ibazar.com) and Jango(www.excite.jango).

3.4.1. The use case diagramAs illustrated in Figure 10, again the actors and

the use cases resemble those in the previousbrokers. The main differences are the lack ofpayment and the availability of negotiation withthe seller providing the first price.

Proceedings of the First IEEE International Conference on Cognitive Informatics (ICCI’02) 0-7695-1724-2/02 $17.00 © 2002 IEEE

Determine ItemCategory

Evaluate Items

Buyer Seller

List items for sale

Register

« include »

Determine Item Location

« include »

Identify items of interest

Search

Negociation

Determine Initial Price

Determine close Day

« include » « include » « include »

Figure 10. The use cases diagram of Low PriceBroker

3.4.2. The class diagramCompared with the previous brokers’ class

diagrams, the class diagram of Low Price Broker(Figure 11) also has the Buyer, Seller and Brokerclasses. In addition, it has the negotiation class thatis supervised by the broker and that characterizesthe association relation between the buyer and theitem classes.

broker

subscribe() Search(categ : string, Locat : string) caculateCloseTime()

category

getCateg_item()

categ_item : string

Seller id_seller : int name : string email : string company : string adress : string city : string state : string zip_cod : int phone : int date_birth : date gender : string

getid_seller() getName() getEmail() getCompany() getAdress() getCity() getState() getZip_cod() getPhone() getDate_birth() getGender()

1..*

buyer id_buyer : int name : string email : string company : string adress : string city : string state : string zip_cod : int phone : int date_birth : date gender : string

getid_buyer() getName() getEmail() getCompany() getAdress() getCity() getState() getZip_cod() getPhone() getDate_birth() getGender() submitRequest() evaluate items(items) SelectItems(Items) submitBid()

access Login : string pwd : string getLogin () getpwd()

1..* items

ref_item : int description : string price : float getRef_item() getDescription() getPrice() addItems()

1..*

1..*

1..* 1..*

1..*

Negociation NnrBidder : int First_Bid : float Currently_Bid : float TimeClose : float

getNbrBidder() getFirst_Bid() getCurrently_Bid() getTimeClose() Auction()

Dutch QteItems : int

GetQteItems() Auction()

Reseve Price Auction()

Private

Auction()

Supervise

1..*

1..*

Subscribe Subscribe

Propose

Negotiate

Possess

1..* Verify

Figure 11. the class diagram of Low Price broker

3.4.3. The sequence diagramsThe sequence diagrams (in Figure 12.a through

Figure 12.c ) resemble those in the previousbrokers. In addition, we have a sequence diagramthat illustrates one negotiation scenario (Figure12.d).

Subscribe() Subscribe()

: Buyer : Broker

: Seller : Buyer : Part To Transaction : Seller

getName() getName()

getPassword() getPassword()

Fig. 12.a: Subscription of users Fig. 12.b. User Identification

:Broker : Buyer

EvaluateItems()

SubmitRquest()

:Items

Search()

SelectItems(Items)

Fig. 12.c. Search

: Buyer : Negotiation

Auction()

: Broker

CalculateCloseTime() getCurrentBid()

Fig. 12.d. Negotiation

Figure 12. The sequence diagrams of Low PriceBroker

4. The e-broker framework

4.1. The use cases diagramThe Framework use case diagram is shown in

Figure 13. It has been obtained by applying theunification rules as follows :1. The actor Buyer/Consumer, andProvider/Seller appear in all the applications2, thusthey are added to the framework core (rule 1).2. The use case make request / Determine InitialParameters / Identify items of interest / EnterInformation Describing Item wanted appears in allapplications, thus this use case belongs to theframework core (rule 1).3. The use cases Enter sources ofInformation/Register a product / Enter InformationDescribing Item for sale / List Items for saleappears in all the applications, thus this use casebelongs to the framework core (rule 1).4. The use cases Evaluate Auto choices / select anoffer / Evaluate items / Evaluate choices appears inall the applications, thus this use cases belongs tothe framework core (rule 1).5. The use case Search auto / Search / Findpotential matches appears in all the applications,thus this use case belongs to the framework core(rule 1).6. The use case subscription to the services of abroker / Register / subscription does not appear inall the applications, therefore it is a framework hot-spot (rule 2).

2 We note equivalent nouns separated by a slash.

Proceedings of the First IEEE International Conference on Cognitive Informatics (ICCI’02) 0-7695-1724-2/02 $17.00 © 2002 IEEE

7. The use case Negotiation does not appear in allthe applications, therefore it is a framework hot-spot (rule 2).8. The use case Payment does not appear in all theapplications, therefore it is a framework hot-spotand it is extended by all the use cases appearing inthe applications (rule 2).9. The use case Enter Information describingItem Wanted includes different use cases indifferent applications, therefore these latter are alladded to the framework as hot-spots (rule 2).10. The use case Enter Information describingItem For sale includes different use cases indifferent applications, therefore they are all addedto the framework as hot-spots (rule 2).11. Each time two use cases or actors aretransferred to the framework, their relations are alsotransferred (rule3).

Seller Buyer

Enter Information Describing Item for Sale

Search

Subscription

Evaluate choices

«extend»

Determine Auto type

Determine Auto option

« include »

« include »

« include »

Determine Max Price

Determine Item Categories

« include »

Determine Item Location

« include » Determine Book Kind

« include » Enter Information Describing Item wanted

Determine Book Title

« include »

Negotiation

Payment

Payment with personal check

«extend»

Payment with credit card

«extend» «extend»

Payment with wire transfer

Payment with certified check/money

« include »

Determine Initial Price Determine

close Day « include » « include »

Figure 13. The use case diagram

4.2. The Class diagramThe Framework class diagram is show in Figure

14. It has been obtained by applying the unificationrules as follows:

1. As in rule 1.c), the class Broker belongs to allthe applications and it has attributes and methods inintersection, but the method search has a differentsignature in the applications. Thus, this class isadded to the framework core with the commonattributes and methods and tagged with{extensible}. The method Search() is virtual andhas an undefined signature. Then the class Broker isa whitebox hot-spot. Furthermore, two newinheriting classes from the class Broker are addedsince they have a significant number of attributesand methods..2. By applying rule 1.c), we obtain the classSeller (equivalent to Provider) in the frameworkcore.

3. By applying rule 1.c), we obtain the classBuyer (equivalent to Consumer) in the frameworkcore.4. As in Rule 2.b), the classes Auto, Book,AntiqueItemsForsale and Items have differentnames but they constitute a variation of the sameconcept and they have attributes and methods inintersection, then these classes are added to theframework as inheriting classes to a new abstractclass Product. The class Product has the commonattributes and methods and is tagged with{extensible}. This hierarchy constitutes a whiteboxhot-spot in the Framework since the methodCreateProduct() is virtual, i.e., it has a differentimplementation depending on the inheriting class.We added the tag {incomplete} to the hierarchybecause the application does not contain allpossible variants of Product.5. As in rule 5, the classes Certification, FinancialData, Option, Technical Details,AntiqueItemsWanted, Category, Negotiation and itshierarchy, Order, Basket, Payment and its hierarchyhave names completely different, thus these classesare added to the framework as hot-spots.6. As in rule 6, the relations of the classestransferred in the framework are also transferred.

{extensible} Ref : int Description : string Price : float {extensible} getRef() getDescription() getPrice() CreateProduct()

Product

Seller

{extensible}

1..*

1..*

1..*

0..*

0..*

1..*

1..*

acces login : string pwd : string getLogin () getPwd()

Credit card card_id : int prop_nam : string date_exp : date number_card : int

getCard_id() getprop_nam() getDate_exp() getNumber_card()

Payement ValidatePayement()

Check Wire transfert Money

{incomplet}

kind_bok : string hous_ed : string quantity : int

getkind_bok() gethous_ed() getquantity()

Book

Condition : string year : int

getCondition() getyear()

AntiqueItemForSale Auto size : int color : string shape : string dimension : string style : string NbrofDoors : int

getSize() getColor() getShape() getDimension() getStyle() getNbrofDoors()

1..*

1..*

1..*

Financial Data

maintenaceCost : float LoanAvailability : float InterestRates : float

getmaintenaceCost() getLoanAvailability() getInterestrates() get Financial Data()

Option

recorderType : string

getRecorderType() getOption()

Technical Details

horepower : float acceleration : float tuming raduis : float engine-noise : float

getHorepower() getAcceleration() getTumingRaduis() getEngineNoise() get Technical Details()

Broker-Antique subscribe() addBuyer() addSeller()

category

getCateg_item()

categ_item : string

1..*

1..*

{Subset}

certification Id_cer : int Dat_cer : date getId_cer() getDat_cer()

Dutch QteItems : int

GetQteItems() Auction()

Reseve Price

Auction()

Private

Auction()

Negociation NnrBidder : int First_Bid : float Currently_Bid : float TimeClose : float

getNbrBidder() getFirst_Bid() getCurrently_Bid() getTimeClose() Auction()

AntiqueItemWanted

Reference : string description : string priceRange : Range conditionRange : range yearRange : Range

getDescription() : String

1..*

basket {extensible} optional} date : date addProduct() deleteProduct() 1..*

0..1

Order OerderDate : date PriceBooks : float Free : float Total : float getOerderDate() getPriceBooks() getFree() getTotal ()

Broker

{extensible}

{extensible} Search(Undefined)

Broker-LowPrice

subscribe() CalulateClaseTime()

Broker-Book

subscribe()

1..*

Seller-LowPrice id_seller : int name : string email : string company : string adress : string city : string state : string zip_cod : int phone : int date_birth : date gender : string

getid_seller() getName() getEmail() getCompany() getAdress() getCity() getState() getZip_cod() getPhone() getDate_birth() getGender()

Seller-Book Id : int FirstName : string LastName : string Email : string City : string Address : string State : string

getId() getFirstName() getLastName() getEmail : string getCity() getAddress() getState()

Buyer-Book Id : int Firstname : string LastName : string Adress : string Email : string City : string State : string

getId_con() getFirstname() getLastName() getAdresse() getEmail() getVille() selectBook(Book)

Buyer

{extensible}

SubmitRequest(Undefined) EvaluateChoices(Undefined)

Buyer-LowPrice id_buyer : int name : string email : string company : string adress : string city : string state : string zip_cod : int phone : int date_birth : date gender : string

getid_buyer() getName() getEmail() getCompany() getAdress() getCity() getState() getZip_cod() getPhone() getDate_birth() getGender() submitBid()

1..*

Figure 14. The e-broker class diagram

4.3. The Sequence diagramsThe Framework sequence diagrams are obtained

by taking the union of all the sequence diagram ofthe applications and marking any message as{optional} if it does not appear in all theapplications.

Proceedings of the First IEEE International Conference on Cognitive Informatics (ICCI’02) 0-7695-1724-2/02 $17.00 © 2002 IEEE

Subscribe() Subscribe()

: Buyer : Broker

: Seller

{optional} addSeller()

{optional} addBuyer()

: Buyer : Part To Transaction : Seller

{optional}getName()

{optional}getPassword()

Fig. 15.a: Subscription of users Fig. 15.b. User Identification

{optional}getName()

{optional}getPassword()

: Seller : Auto

{optional}CreateAuto()

: Option : Financial Data : Technical Details

{optional} getOption()

{optional} getFinancialData()

{optional} getTechnicalDetails()

Fig. 15.c. Description Autos for sale

Fig. 15.d. Search

:Broker : Buyer

EvaluateItems()

SubmitRquest()

: Product

Search(undefined)

{optional} SelectProduct(Product)

: Order : Buyer

{optional}CreateOrder()

: Payement

{optional} Validatepayement()

Fig. 15.e. Payment

: Buyer : Negotiation

{optional}Auction()

: Broker

{optional} CalculateCloseTime() {optional}getCurrentBid()

Fig. 15.f. Negotiation

Figure 15. The sequence diagrams

5. Conclusion

This paper first presented a design method thatis based on a design process and a design languageF-UML.

Applied to the development of a framework fore-brokers, the design language F-UML showed thatthe added annotations helped distinguishingbetween the framework core, blackbox andwhitebox hot-spots. In addition, we have found outthat the bottom-up design process wasstraightforward by applying the unification rules,except for the decision on the hot-spot type whichrequires a wide domain expertise. However, oneessential difficulty in the design process isconstructing the dictionary which requires both awide domain expertise and a deep understanding ofthe specific applications.

We are currently developing a tool for the semi-automatic generation of a framework design basedon the unification rules. The developer is probedonly to decide on the nature of a hot-spot.

6. References

[1] http://www.Antiqnet.com

[2] A. Y. Birkes, C. H. Hsiung, T. Cohen and R. E.Fulton, "A Prototype Multimedia Auto Broker",ASME Computers in Engineering Conference,Proceedings of the engineering DatabaseSymposium Boston, MA, Sept 17-21, 1995.

[3] N. Bouassida, H. Ben-Abdallah, F. Gargouri "AUML based Design Language for FrameworkReuse". The 7th International Conference onObject-Oriented Information Systems (OOIS’01),Calgary, Canada, 2001.[4] N. Bouassida, H. Ben-Abdallah, F. Gargouri " ABottom-up Framework Design Method," SeventhMaghrebian Conference on Computer Sciences(MCSEAI), May, 6-8, 2002.[5] Fayad, M., D.S chmidt, R. Johnson, BuildingApplication Frameworks, Wiley 1998.[6] Fontoura, M.F., A systematic approach forframework development. Ph.D. Thesis, Puc-Rio,July.[7] Gamma E., Helm R., Johnson R. and VlissidesJ. Design patterns: Elements of reusable ObjectOriented Software", Addisson-Wesley, Reading,MA, 1995.[8] Hands J, Bessonov M., Blinov M., Patel A.,Smith R. "An inclusive and extensible architecturefor electronic brokerage", Proceedings of the32ndHawaii International Conference on SystemSciences,1999.[9] Johnson R. E., Foote B, "Designing reusableclasses", Journal of Object Oriented Programming,vol 1, no 2, June/July 1988, pp 22-35.[10] Khelifi A., "Les Brokers pour le commerceélectronique : analyse de l’existant, développementd’un prototype", Faculté des sciences de Tunis.[11]Koskimies K., Mossenback H. "Designing aframework by stepwise generalization", 5thEuropean Software Engineering Conference,Barcelona. Lecture Notes in Computer Science 989,Springer-Verlag,1995.[12] Landin N., Niklasson A., Development ofobject-oriented frameworks, Master Thesis, LundUniversity,1995.[13] Mattson M. “Object Oriented frameworks: asurvey of methodological issues”, Licentiate thesis,Lund University, 1996[14]Roberts. D, Johnson. R "EvolvingFrameworks : A pattern language for DevelopingObject Oriented Frameworks", Proceedings of thethird conference on pattern languages andprogramming, Montecilio, Illinois, 1996.[15] Rumbaugh et al., Object Oriented Modelingand design ,Prentice Hall, 1991.[16] Schmid H.A. "Systematic framework designby generalization ", Communications of the ACM,vol 40, no 10, October,1997.

Proceedings of the First IEEE International Conference on Cognitive Informatics (ICCI’02) 0-7695-1724-2/02 $17.00 © 2002 IEEE