A UML based Framework Design Method
H. Ben-Abdallah, Faculté des Sciences
Economiques et de Gestion de Sfax, Tunisie
N. Bouassida, F. Gargouri, A.
Ben-Hamadou, Institut Supérieur d’Informatique
et de Multim édia de Sfax, Tunisie |
 |
REFEREED
ARTICLE
PDF Version |
Abstract
Object-oriented frameworks offer reuse at a high design level promising
several benefits to the development of complex systems. However, framework
design remains a difficult task due to the generality and variability
frameworks must encompass. In addition, traditional object-oriented
design methods only deal with the design of specific applications and
do not facilitate the design of frameworks.
In this paper, we present a UML-based framework design method
called FBDM. The method offers a design language, called F-UML, and
a semi-automatic design process both of which supported by a CASE environment.
The
design language F-UML visually distinguishes among the fixed components
and
the adaptable components of a framework. The design process for F-UML
is based on stepwise, bottom-up unification rules that apply a set
of comparison criteria on various applications in the framework domain.
The design method is illustrated and evaluated through the design
of a framework for electronic commerce brokers.
1 INTRODUCTION
Frameworks promise increased productivity, shorter development times
and a higher quality of applications since they allow developers to
reuse their previous experience in problem solving both at the design
and code levels [Johnson 1988]. In fact, they are an extension to object-oriented
designs, that helps reuse at a level of abstraction higher than classes,
patterns [Gamma 1995] and components.
An object-oriented framework
represents a software architecture that captures several applications’ behaviours
in a particular domain. It is composed of a set of concrete and abstract
classes with their
relations. It is organized in two parts [Pree 1994]: a core (also
called frozen-spot) that is common to all applications derived
from the framework, and hot-spots that represent the variable
parts which allow a framework to be adapted to a particular application.
Schmid
[Schmid 1997] defines two types of hot-spots: whitebox hot-spots adapted
by implementing some of their methods and classes, and blackbox
hot-spots adapted through composition.
Traditional object-oriented
design methods (e.g., OMT [Rumbaugh 1991]) deal with the design of
only specific applications. They are inappropriate
for the design of frameworks since they lack concepts to determine
and express hot-spots, an essential concept that should be clearly
expressed in order to avoid any framework misuse. This deficiency motivated
several proposals of new framework notations (c.f., [Riehle 2000],
[Fontoura 2000b], [Sanada 2002]) and design processes (c.f., [Schmid
1997], [Koskimies 1995], [Fontoura 2000a]).
In this paper, we present
a framework design method that offers a UML-based design language called
F-UML [Bouassida 2001] and a bottom-up design
process [Bouassida 2002]. F-UML is an UML profile [Bouassida 2003b]
that increases the expressiveness of UML by adding tags and graphical
annotations to UML use cases, class, pattern and sequence diagrams.
The extensions help to distinguish visually between the core of the
framework and its hot-spots and guide the user in instantiating a framework.
The design process is based on a bottom-up strategy that generates
a framework design by unifying a set of application designs. It is
composed of three main steps: The first step extracts the domain specifications
and potential uses of the framework through unification of the use
case diagrams of different applications in the domain. The second step
models the framework static features through unification of the class
diagrams of the given applications. The last step extracts the dynamic
framework features through the unification of sequence diagrams.
The
FBDM design method is supported by a toolset [Ayadi 2003] that allows
an easy representation of syntactically, well-defined frameworks
[Bouassida 2003b] and a semi-automatic generation of a framework design.
The toolset prompts the framework designer only to decide on the completeness
of certain relations (inheritance, association,…), which requires
a deep domain knowledge.
This paper
is organized as follows. Section 2 overviews existing framework design
methods. Section 3 and 4 present the framework design language
F-UML and its design process, respectively. Section 5 illustrates the
method through the design of a framework for electronic commerce brokers.
Section 6 evaluates the method. Finally, section 7 summarizes the paper
and outlines future work.
2 OVERVIEW OF FRAMEWORK DESIGN METHODS
In this section, we first
outline a set of concepts necessary in a framework design language.
We then use the outlined concepts to examine
current framework design languages that are based on UML. Finally,
we present current framework design processes.
The following five requirements
detail out concepts necessary in a design language for frameworks [Bouassida
2001]:
- The framework design notation must provide for a means to
describe statically the framework:
- classes and their relations (association,
generalization, aggregation);
- core; and
- whitebox and blackbox hot-spots.
- Within a whitebox hot-spot,
the notation must statically guide the user to the potential changes
they are expected to introduce. For example,
the notation indicates that the user is expected to redefine the
code of a method, or the user may add inheriting classes, etc. This
criterion
facilitates a correct reuse of a framework.
- The notation must contain
concepts for regulating the interactions within a framework by:
- explicitly showing the collaborations between objects instantiated
from the framework classes;
- clarifying the object responsibilities,
contexts on which the responsibilities depend and how the objects
may combine the different responsibilities;
and
- being abstract and independent of unessential implementation
details that may unnecessarily tie the design to a specific
environment and
limit the framework generality.
- The notation must show the framework
aim and potential uses of the, i.e., it must show scenarios
of the framework instantiations.
- The notation must be unambiguous to facilitate
the correct comprehension of the framework.
Current Framework Design Languages
[Rational 2001] models a framework through three UML diagrams:
a class diagram enriched with packages, a collaboration diagram and
a use case
diagram. The enriched UML class diagram expresses the static structure
of a design (1.a). However, it does not distinguish between the classes
in the core and those in the hot-spots (1.b-c). Although the name of
an abstract class is in italic in the UML notation, this is not sufficient
to deduce all the hot-spots. The UML collaboration diagram successfully
shows the object interactions (3.a) and responsibilities (sender/receiver)
(3.b partially). However, working at the message exchange level can
be too detailed and does not indicate how and in which context the
framework works. The UML use case diagram defines a set of external
actors and their possible uses of the system. It could therefore be
used to define the aim and possible contexts (4).
Fontoura et al. [Fontoura
2000b] propose a UML profile for frameworks, called UML-F, where a
design is expressed by a class diagram and a
sequence diagram both extended by presentation tags (e.g., complete,
incomplete), basic modeling tags (e.g., fixed, application, framework)
and essential pattern tags (e.g., FacM-Creator, FacM-ConcreteCreator).
The added tags are used to mark, essentially, the complete and incomplete
parts, the variable parts in the diagrams and the roles of diagram
elements. In this notation, the extended class diagram represents the
framework classes and relations (1.a). However, according to the tag
definitions, this notation only identifies the whitebox hot-spots (1.c
partially and 2). In addition, several tags are complementary and thus
redundant (e.g., complete and incomplete, application and framework).
Furthermore, the combined pattern tags and presentation tags could
overcharge the diagram and impede the understanding of the design.
The extended sequence diagram guides the user when adapting framework
interactions (2 partially), and it explicitly shows the object collaborations
(3.a) and responsibilities (3.b partially). However, similar to the
UML sequence diagrams, it remains at a detailed level.
Sanada [Sanada
2002] presents an UML extension that aims to be comprehensive and well
defined. However, most of the extensions proposed have already
been defined by Fontoura[Fontoura 2000b], and the only difference is
the constraint "covariant" which shows that
adding a subclass to a certain class might result in adding a subclass
to
another
one.
Riehle
[Riehle 2000] proposes a role modeling language that adapts the OORAM
methodology [Reenskaug 1996]. The proposed language represents
a framework through a class model with an extension-point class
set (points of extension), a built-on class set (framework
interface) and a free role type set (the use of the framework
by other frameworks). Overall, this notation represents the architecture
and collaborations
in a framework (1.a and 3.a-b) and describes the framework context
(3.b). However, it focuses more on framework composition than framework
adaptation. For instance, it does not visually distinguish between
extension-point classes and frozen classes in the framework. Therefore,
one cannot easily recognize the whitebox and blackbox hot-spots.
Current
Framework Design Processes
Current framework design processes can be
classified as either bottom-up or top-down. Bottom-up design works
well where a framework domain is
already well understood, for example, after some initial evolutionary
cycles. In this case, the design process starts from a set of existing
applications and generalizes them to derive a framework design (c.f.,
[Koskimies 1995], [Schmid 1997]). On the other hand, top-down design
is preferred when the domain has not yet been sufficiently explored.
In this case, the design process starts from a domain analysis and
then constructs the framework design (c.f., [Aksit 1998]).
Koskimies
and Mossenback [Koskimies 1995] propose a two-phase bottom-up framework
design process. The first phase, called problem generalization,
generalizes a representative application in the framework domain into “the
most general” form. In the second phase, called framework
design,
the generalization levels of the previous phase are considered in a
reverse order leading to an implementation for each level. The implementation
of the framework at level i requires adding specific classes and applying
various design patterns on the framework. The last step in the design
phase is to apply the resulting framework to the initial example problem
of the generalization phase. This design process lacks guidelines for
the problem generalization phase. In addition, both the reuse degree
of the resulting framework and the ease of deriving the framework depend
on how well the original application represents the domain. Furthermore,
the resulting framework does not provide for reuse guidelines; that
is, it does not clearly identify nor does it guide the designer in
finding the framework core and hot-spots.
Schmid [Schmid 1997] decomposes
the framework design process into three steps:
- design of a class
model for an (arbitrary) application in the framework domain;
- analysis
and specification of the domain variability and flexibility, i.e.,
identification of the hot-spots; and
- generalization of the class
model by applying a sequence of transformations that incorporate
the domain variability.
This design process leaves it to the developer’s
expertise to identify the hot-spots during the second step.
Pree [Pree
1994] proposes a framework design process based on combining hot-spots
specified as metapatterns. These latter are a set of design
patterns that describe how to construct frameworks. This design process
focuses on hot-spot combination without defining how to determine them.
Fontoura
et al [Fontoura 2000a] propose a design process that considers a set
of applications as viewpoints (i.e., perspectives) of the domain.
The process informally defines a set of unification rules that describe
how the viewpoints can be combined to compose a framework. The result
of applying the unification rules is a template hook model that represents
the hot-spots through template and hook methods. After developing the
template hook model, the developer has to find which meta-pattern should
be used to model each hot-spot. The resulting framework is an OMT class
diagram that does not completely specify the framework; in particular,
it neither distinguishes between the two hot-spot types, nor does it
not specify the object interactions. In addition, this process does
not address semantic issues in the unified applications (e.g., synonyms,
homonyms,…); it supposes that all the semantic inconsistencies
between the viewpoints have been solved beforehand.
3 THE DESIGN LANGUAGE
F-UML
The development of the design language F-UML was motivated by
the design criteria outlined earlier. In F-UML, a framework design
consists
of
the following four UML based diagrams:
- A use case diagram that
determines the framework scope, objectives and domain limits (criteria
4). The extensions to the use case
diagram are summarized in Table 1.
Table 1. F-UML extensions to UML use case diagrams
- A class diagram that describes the static architecture of a
framework. The extensions to the class diagram (see Table 2) let
the user distinguish
between the core of the framework and its hot-spots (1) and guide
him/her in adapting a whitebox hot-spot to a specific application
(2).
- A
pattern diagram that shows the design patterns and metapatterns
identifying the roles of the framework classes (3.a-b). The pattern
diagram helps understanding the interactions among the objects
of
the framework.
- Sequence diagrams that describe possible interactions
between various object instances of the class diagram (3.a, 4).
While the
sequence
diagrams might present too detailed information compared to
the previous diagrams, they can provide important information in
understanding
how to use, and consequently reuse, a framework. The F-UML
extensions to
the sequence diagram are summarized in Table 3.
The F-UML diagrams
can be enriched with OCL constraints [OCL 1997] to specify constraints
and invariants on classes and types and
pre and post conditions on methods.
The F-UML notation is a UML
profile whose syntax (derived from the UML meta-model) has a formal
semantics [Bouassida 2003b]
(criteria 5). 
Table 2. F-UML extensions to the UML class
diagram 
Table 3. F-UML extensions to UML sequence diagrams
4 THE FBDM
DESIGN PROCESS
The F-UML bottom-up design process helps the
framework designer to structure the framework by determining
its core, blackbox
and whitebox
hot-spots. It starts from several application designs and goes through
three unification steps (In fact, Roberts[Roberts 1996] states that
three applications sufficiently represent their domain):
- Design
of the framework use case diagram: The unification process
first extracts use cases common to all the applications
and puts them
as the framework core. Secondly, it extracts the different use
cases and puts them as hot-spots.
- Design of the framework class diagram:
The unification process first extracts common classes and
puts them as the framework core. Secondly,
it puts the remaining classes as hot-spots. For certain relations,
the designer is probed to decide on their completeness.
- Design of the
framework sequence diagrams: The unification process identifies
optional messages and tags them as hot-spots.
Currently, the
pattern diagram is not obtained through unification. It is
obtained from the class diagram (obtained in step 2) by filtering
out the details inside the classes and by matching the resulting structure
to a set of design patterns and metapatterns. At this level of representation,
the user is interested in the roles and interactions between the various
classes of the framework.
The above three unification steps use a set
of unification rules based on semantic comparison criteria.
These latter rely on linguistic definitions
to define semantic equivalence, generalization-specialization, variation
and composition between names.
In the remainder of the paper, to facilitate
the presentation of unification process, we note:
- The class C (object O) in the application
Ai as CAi (OAi;);
- The use case U (actor A) in the application
Ai as UAi (AAi);
- The message M in the application Ai as
MAi; and
- The application A1 as the application containing
the minimal number of actors and use cases in the use case
diagram (classes in the class
diagram or messages in the sequence diagram).
Use case diagram unification
The unification of use case diagrams
relies on semantic correspondences among the actors, use cases
and their relations. These latter are expressed
by the following relations:
- N_equiv(AA1,...,AAn) means that
the names of the actors are either identical or synonym,
e.g., ConsumerA1-BuyerA2.
- N_var(AA1,...,AAn) means that the names of the
actors are a variation of a concept, e.g., employee-contractual,
employee-permanent, employee-vacationer.
-
Gen_Spec(AA1;AA2,...,AAn) means that the name AA1 is a
generalization of the specific names AA2 ,…, AAn, e.g., PersonA1-EmployeeA2.
- N_dist(AA1,...,AAn) means that none of the above
relations holds.
The relations between use cases are defined in a similar manner.
The design of the framework use case diagram is guided by
the six rules depicted in Figure 1. As illustrated in this
figure,
the core and
hot-spots of the framework are derived automatically. In addition,
the designer’s intervention is guided (rule 2 and 3); it is
needed to decide on the completeness of the diagram, which requires
domain expertise.
Fig. 1: Design of the use case diagram
Rules 4 and 5 add or ignore hot-spot actors (use cases) according
to the domain coverage ratio Rdc(AAi):
Class diagram
unification
The design of the framework class diagram consists
of the eight unification rules shown in Figure 2. The unification
rules
essentially take classes “common” to
all of the applications as the framework core and add the remaining
(specific) classes as hot-spots. These rules use semantic correspondence
criteria to compare class names, attributes and operations. The class
name comparison criteria use five relations among class names. Four
of these relations are defined in a way similar to the relations between
actors. The fifth relation reflects class composition:
-
N_comp(CA1;CA2,...,CAn) means that the name CA1 is a composite of the
components CA2,…,CAn, e.g., HouseA1-RoomA2.
The attribute comparison
criteria use four relationships to compare the attribute names and
types:
- Att_equiv(CA1,..., CAn) means that the classes have eitheridentical
or synonym attribute names with the same types.
- Att_int(CA1,..., CAn) means that the classes CA1,...,
CAn have attributes in intersection.
- Att_conf(CA1,..., CAn) means that there exists at least
one attribute of CA1 having a name equivalent to some attributes
of CA2,..., CAn
but these attribute types are different.
- • Att_dist(CA1,..., CAn) means that none of the above relations
holds.
The operation comparison criteria use four relations (Op_equiv(CA1,...,CAn),
Op_int(CA1,...,CAn), Op_dist(CA1,...,CAn),
Op_Conf(CA1,...,CAn)
) to compare the operation names and signatures (returned types and
parameter
types). These relations are defined in a way similar to the attribute
comparison relations.
In the unification process shown in Figure 2, Rule 5 deals with
the generalization-specialization relation in a manner similar to
N-Comp relation of Rule 4. Furthermore, Rule 3.b may add new inheriting
classes to the framework. The addition depends on the significance
of the number of attributes and methods in an inheriting class C with respect to another class C’. This is defined using the
ratio Rsig:
Informally, a class C has a significant number of attributes
and methods with respect to a class C’, if Rsig is greater
than a fixed threshold (e.g., 50%) that can be fixed by the framework
designer.
Further, Rule 6 adds or ignores hot-spot classes according
to the
domain coverage ratio Rdc:
Informally, this ratio is used to determine the reuse potential
of a class. If a class is present in several applications, then
it covers
an important space of the framework domain; thus, it must be
present in the framework hot-spot. On the other hand, if a class
is present
in few applications, it is too application specific; thus, if
it is added to the framework, it may complicate unnecessarily
the
framework comprehension.
Sequence diagram unification
The design of the framework sequence
diagram consists of five unification rules (shown in Figure 3)
that rely on the semantic relations
among classes adapted
to objects and on name comparison of messages. The main idea of these rules
is to unify sequence diagrams that correspond to the same or an equivalent
scenario. That is, the process takes the “union” of all the sequence
diagrams of the applications and marks any message as {optional} if
it does not appear in all the applications.
Fig. 2: Design of the framework class diagram
The design unification rules are implemented in the FUMLTool [Ayadi
2003]. This tool provides for the graphical representation of both
applications and frameworks. Moreover, it manages the comparisons relations
through a dictionary. In addition, it allows a semi-automatic generation
of a framework design in F-UML based on the above presented unification
rules. As the rules indicate the designer is probed only to identify
the completeness of certain relations.
Fig. 3: Design of the sequence diagram
5 APPLICATION: E-BROKER FRAMEWORK
To evaluate the F-UML language,
process and tool, we designed an electronic commerce broker. The
choice of electronic commerce domain has several
motivations. One motivation is the expansion of e-commerce; a second
motivation is the importance of the broker entity in this type
of commerce; a third motivation is the software complexity of electronic
brokers, which makes design reuse a judicious choice in order to
benefit from the expertise gained in the design of particular e-broker
applications.
In order to design the E-broker framework, we followed
three steps. First, we took three e-broker applications designs:
a book broker
called Tunisia Book [Khelifi 2000], an auto broker called Auto
Broker [Birkes
1995] and a broker for antiquities called Antique Broker [Antique
2002]. Secondly, we constructed the relation dictionary used
in the comparison
rules of the design process. Finally, we used the framework generation
function of the F-UMLTool to obtain the E-broker framework. Due
to space limitations, we next present a simplified version of this
case
study.
Fig. 4: The use case diagram of Tunisia Book Use case generation
Figure 4 presents part of the use case diagram
of Tunisia Book. As illustrated in this figure, the actors that use
the brokerage services
are the Consumer and the Provider. One of the functionalities assumed
by this application is the consumer/provider subscription to the
broker. Another functionality is the Provider registration of
its products
for sale and the Consumer product request submission. The functionality
of the broker is to search for the best offer and to return the
list of books found. The consumer evaluates the list of found offers
and
decides which books to buy and pays for them.
Figure 5 presents
part of the use case diagram of the Auto broker. As illustrated in
this figure, the actors that use the system are
Buyer and Seller, two variants of the actors in Tunisia Book.
Unlike Tunisia
Book, this broker does not require a subscription. Figure 6 presents
part of the use case diagram of the Antique Broker.
Fig.5: The use case diagram of Auto broker 
Fig. 6:. The use
case diagram of Antique Broker
Fig. 7: The framework use case diagram The generated use case diagram of the E-broker framework is shown
in Figure 7. It has been obtained by applying the unification rules
as indicated in Table 4.
Table 4: Design of the use case diagram of the framework broker
Class diagram generation
Figure 8 presents part of the class diagram
of Tunisia Book. The Broker manages the Consumer and Provider subscriptions.
Furthermore, the
association between the Consumer class and the Book class represents
the consumers’ evaluation and selection of found offers.
Fig.
8: The class diagram of Tunisia Book 
Fig. 9: The class diagram of Auto broker
Figure 9 partially presents the class diagram of Auto Broker.
Similar to the previous broker class diagram, the class diagram
of Auto broker
has the classes Broker, Seller and Buyer. In addition, it has the class
Auto and its aggregate classes: Options and Technical Details.
Fig.
10: The class diagram of Antique Broker 
Table 5: Design of the class diagram of the framework broker
As illustrated in Figure 10, which presents the class diagram
of Antique Broker, the common classes with the previous applications
are Broker, Buyer and Seller.
The main difference is the class AntiqueItemWanted which is a hot-spot.
The
framework class diagram (Figure 11) has been obtained by
applying the unification rules shown in Table 5. The application
A1 is Tunisia Book since it contains
the minimum number of classes, A2 is Antique Broker and A3 is
Auto Broker. During the generation of the class diagram, F-UMLTool produced
the diagram
shown in Figure 11 with the inheritance relation between auto, book,
antiqueitemwanted and Product as undecided (Rule 3.d). We have decided
that it is incomplete since the inheriting classes does not cover all the
domain.
Fig. 11: The framework class diagram Sequence diagram generation
Fig. 12: A sequence diagram of Tunisia book
Fig. 13: A sequence diagram
of auto Broker Figure 12 presents the simplified sequence diagram of Tunisia Book,
which corresponds to the scenario “Search and buy”. Figure
13 presents a part of a sequence diagram Auto Broker, which corresponds
to the scenario “Search and evaluate auto”. Figure 14 presents
a part of the sequence diagram of the antique Broker corresponding
to the scenario “Search and evaluation”.
Fig. 14: A sequence diagram of antique Broker
Fig. 15: The framework
sequence diagram
The Framework sequence diagram corresponding
to the scenario “Search
and evaluation” (Figure 15) was automatically derived using the
semantic comparison between the message’ names and types and
between the sending and receiving object names.
6 EVALUATION OF THE
FBDM METHOD
In addition to the E-commerce domain, we have
evaluated the FBDM method and its associated toolset in the
graphical drawing
editor domain [Bouassida 2005]. This domain was chosen since a
popular and
mature framework already exists: the JHotDraw framework (about
one hundred classes) [Gamma 1997]. Furthermore, JHotDraw was chosen
in
order to have a comparison basis for the generated framework since
several applications were derived from it.
On one hand, both case
studies showed that the F-UML notation facilitates the distinction
between the core of the framework, which must be
present in any application derived from it, and its variable
parts (hot-spots).
This in turn can guide the designer in estimating the degree
of reuse the framework can offer. On the other hand, both case studies
showed
that the FBDM design process generates a framework that contains
the whole framework core (e.g., Buyer, Seller, Product for E-Broker).
However,
the design process produces a framework with (possibly too many)
application specific increments i.e., classes specific to a particular
application
(e.g., Antique item wanted, Option, Technical details in E-Broker).
These latter could complicate the comprehension of the framework
and hence impede its reuse. However, the F-UML notation helps
by
visually
distinguishing these details. Thus, when reusing a framework,
the designer can first focus on the core, and later he/she can choose
to examine
or ignore the hot-spots. Moreover, some of the framework internal
increments (i.e., classes belonging to the library accompanying
the framework)
are not deduced by our design process since they are absent in
the original applications. However, the process puts the tag
{incomplete}
wherever the designer can add details (classes, attributes, or
methods).
While this may reduce the number of classes reused (as a reuse
measurement), the designer is at least advised of the places
he/she is expected
to focus his/her design effort.
Overall, we can note that the
degree of details produced in the generated framework depends on
the level of domain coverage in
the unified
applications. Finally, the F-UML Tool was vital in the design
process, especially
in managing the complexity of applying the rules face to the
size of the diagrams, in particular for the JHotDraw case study.
7
CONCLUSION
This paper first reviewed current framework design languages and processes.
Secondly, it presented a framework design method that offers a UML-based
design language and a systematic bottom-up design process. The presented
FBDM method is distinguished from existing methods in three ways: 1)
its UML-profile language visually distinguishes between the framework
core, whitebox and blackbox hot-spots; 2) its design process is well-defined
through a precise set of unification rules that identifies automatically
the core and hot-spots; and 3) its toolset provides for the graphical
representation of applications and the semi-automatic generation of
a framework. The FBDM design method was illustrated through the design
of a framework for brokers of e-commerce. It was evaluated through
two case studies in the e-commerce and graphical editor domains.
We are currently investigating how to generate automatically
the dictionary of the semantic relations in the design
process. Future
works include
the development of a module for the generation of the
pattern diagram. The module would propose the patterns adapted
to a design and the
framework designer would decide which pattern fits the
problem.
REFERENCES
[Antique02] http://www.Antiqnet.com
[ArgoUML02] ArgoUML, http://arguml.tigris.org
[Aksit99] M. Aksit,
B. Tekinerdogan, F. Marcelloni and L. Bergmans: Deriving Object-Oriented
Frameworks from Domain Knowledge, Building
Application Frameworks: Object-Oriented Foundations of Framework Design,
M. Fayad, D. Schmidt, R. Johnson (Eds.), John Wiley & Sons Inc.,
pp. 169-198, 1999.
[AYADI03] T. Ayadi, N. Bouassida, H. Ben-Abdallah,
F. Gargouri, D. Slimane: F-UMLTool: A Tool for Object-Oriented Framework
Design, Int’l
conference on Industrial Engineering and Production Management (IEPM’03),
Portugal, 26-28 May 2003.
[Birkes95] 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 Database Symposium Boston, MA, Sept
17-21, 1995.
[Bosch97] J. Bosch, P. Molin, M. Mattsson, P. O. Bengtsson:
Object oriented frameworks: problems & experiences, http://www.ide.hk-r.se/~michaelm/papers/ex-frame.ps , 1997.
[Bouassida01] N. Bouassida, H. Ben-Abdallah, and F. Gargouri:
A UML based Design Language for Framework Reuse, 7th International
Conference
on Object-Oriented Information Systems (OOIS’01), Calgary, Canada,
2001.
[Bouassida02] N. Bouassida, H. Ben-Abdallah, and F. Gargouri,
A. Ben-Hamadou: A stepwise Framework Design Process, IEEE International
Conference
on Systems Man and Cybernetics, 07-09 October, Hammamet, Tunisia, 2002.
[Bouassida05] N. Bouassida, H. Ben-Abdallah, F. Gargouri, A. Ben-Hamadou:
"Evaluation of a framework design method", submitted to Information
Sciences for Decision Making Journal (ISDM), 2005.
[Bouassida03b]
N. Bouassida, H. Ben-Abdallah, and F. Gargouri, A. Ben-Hamadou: F-UML:
a design language for frameworks and its formal specification,
International conference on Software Engineering and Formal Methods
(SEFM’2003), Australia, Brisbane, 26-29 September, 2003.
[Fontoura00a]
M.F. Fontoura, S. Crespo, C.J. Lucena, P. Alencar, D. Cowan: Using
viewpoints to derive Object-Oriented Frameworks: A case
study in the web education domain, Journal of Systems and Software
(JSS) Elsevier Science, 54 (3), 2000.
[Fontoura00b] M.F. Fontoura,
W. Pree, B. Rumpe: UML-F: A Modeling Language for Object-Oriented Frameworks,
Proceedings of European Conference
on Object Oriented Programming (ECOOP 2000), Springer-Verlag, 2000.
[Gamma95]
E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design patterns: Elements
of reusable Object Oriented Software, Addisson-Wesley, Reading,
MA,1995.
[Gamma97] E. Gamma, T. Eggenschwiler, http://www.jhotdraw.org
[Johnson88]
R. E. Johnson, B. Foote: Designing reusable classes, Journal of Object
Oriented Programming, Vol 1, N°2, June/July 1988,pp 22-35.
[Khelifi00]
A. Khelifi, Les Brokers pour le commerce électronique: analyse
de l’existant, développement d’un prototype,
rapport de fin d’études, Faculté des sciences de
Tunis, 2000.
[Koskimies95] K. Koskimies, H. Mossenback: Designing a
framework by stepwise generalization, 5th European Software Engineering
Conference,
Barcelona. Lecture Notes in Computer Science 989, Springer-Verlag,
1995.
[OCL97] Object Constraint Language, version 1.1, September, 1997.
[Pree94]
W. Pree: Meta-patterns: a means for capturing the essentials of object-oriented
designs, Proceedings of the 8th European Conference
on Object Oriented Programming, Bologna, Italy, 1994.
[Rational01] Rational
Software, URL: http://www.rational.com/UML/
[Reenskaug96] T. Reenskaug: Working with objects, Greenwich : Manning,
1996.
[Riehle00] D. Riehle,
Framework design: A Role modelling approach, Dissertation N° 13509,
ETH, Zurich, 2000. http://www.riehle.org/diss/
[Roberts96] D. Roberts,
R. Johnson, Evolving Frameworks: A pattern language for Developing
Object Oriented Frameworks, Proceedings of
the third conference on pattern languages and programming, Montecilio,
Illinois, 1996.
[Rumbaugh91] Rumbaugh et al., Object Oriented Modelling
and design, Prentice Hall, 1991.
[Sanada02] Y. Sanada, R. Adams: Representing
Design Patterns and Frameworks in UML-Towards a Comprehensive Approach,
in Journal of Object Technology,
Vol. 1, N°2, July-August 2002, pp. 143-154. http://www.jot.fm/issues/issue_2002_07/article3
[Schmid97] H. A. Schmid: Systematic
framework design by generalization, Communications of the ACM, Special
issue on Object Oriented Application
frameworks, vol. 40, no. 10, October 1997.
About the authors
Hanene Ben-Abdallah received a Ph.d. in Computer and Information Science
from theUniversity of Pennsylvania, Philadelphia, PA. She is currently
Assistant Professor at the Department of Computer Science of Faculté des
Sciences Economique et de Gestion de Sfax at the University of Sfax,
Tunisia. Her research interests include formal method application and
architecture reuse techniques. Her e-mail address is hanene@gnet.tn.
Nadia Bouassida is preparing a Doctorate degree in Computer Science
at the Faculté des Sciences de Tunis, Tunisia. She is a Teaching
Assistant at the Institut Supérieur d'Informatique et du Multimédia
of The University of Sfax, Tunisia. Her e-mail address is nadia.bouassida@isimsf.rnu.tn.
Faiez Gargouri is an Associate Professor at the Institut Supérieur
d'Informatique et du Multimédia of The University of Sfax, Tunisia.
He worked in Paris 5 and Paris 13 universities. His research interests
include object-oriented software design, Data Warehouses and conceptual
reuse. His e-mail address is faiez.gargouri@fsegs.rnu.tn.
Abdelmajid Ben-Hamadou is Professor of Computer Science and the director
of the Institut Supérieur d'Informatique et du Multimédia
of The University of Sfax, Tunisia. He has been the director of the
LARIS reserach laboratory since 1983. His research interests include
automatic processing of Natural Language, object-oriented design and
component software specification. His e-mail address is abdelmajid.benhamadou@isimsf.rnu.tn.
Cite this article as follows: N. Bouassida, H. Ben-Abdallah, F. Gargouri,
A. Ben-Hamadou: “A UML based Framework Design Method”,
in Journal of Object Technology, vol. 3, no. 8, September-October
2004, pp. 97-119. http://www.jot.fm/issues/issue_2004_09/article1
|
