The paper introduces a new situational method for Web applications design. The purpose of the approach is to respond to the following limits of web development methods: they do not cover all design aspects and they lack of °exibility and guidance. The approach consists on the construction, on the °y, of new methods based on existing methods components, that are rede¯ned and stored in method repository to be selected and assembled in a new method. The approach provides two types of guidance: (1) guidance in the selection of the most appropriate process-model, (2) guidance in the selection of the most appropriate method components.
The growth of the Internet and the world wide web has resulted in a large
number of web applications. The development of these applications and the practices
used to their development are di®erent from traditional software development
[
Although various methods have been proposed in literature, none of these
aforementioned techniques and methodologies are used to any signi¯cant extent in
practice [
The empirical study conducted in [
Based on these observations, we have interested in the following research issue: How can we assist web designers to design web applications through the use of existing and proposed methods ? When answering this question, we have study of near existing web development methods. Two sub-research issues have been, consequently, appeared turning around these following questions: (1) How can we structure design process without adding a new method to the already existing list of methods and avoiding, so, to fall in the YAM (Yet Another Model) syndrome? and (2) Could we propose a °exible solution rather than a prescriptive one?
First, we present our contribution. Second, we give an overview of the proposed approach. Finally, we describe how the approach provide guidance in the selection of the most appropriate design process and in the selection of the most appropriate method components. 1.1
To understand, deeply, the discipline of Web engineering, we have established
a Web Engineering Framework [
Considering all these issues, we propose to both relax the prescription of web
design process model even further and cover all aspects that should be
considered during web design. Situational Method Engineering responds to this need
by o®ering techniques to construct methods by assembling reusable method
components stored in a method repository. [
At the beginning of the web design process, the designer is invited to characterize the current situation of the web application being developed by a set of situational factors. Based on introduced situational factors, the most appropriate design process is selected at di®erent levels of abstraction.
The selected path is constituted of successive steps allowing each one the
de¯nition of a product model. We have adopted this principle conformingly to existing
methodologies which often advocate a model-driven approach, inspired by the
separation-of-concerns principle. In order to tackle the complexity of the
problem, each model in the system focuses on a di®erent aspect of the design and
often also a di®erent level of abstraction. The di®erent steps which constitute
the selected path are achieved by method components. These latter are de¯ned
accordingly to the COMET meta-model [
Selected components are, then, assembled and transformations from instances
of one model into instances of the next model are taken place to, ultimately,
reaching the ¯nal result in the form of a web situational method.
In this sense, our solution is based on the following aspects which were be further
detailed in this paper: (1) a list of classi¯ed product models [
We propose a multi-process method o®ering panoply of design processes for web applications. Every activity addresses a particular concern and is accomplished separately since it covers existing approaches transparently. First, we base our process meta-model on a set of product models concerning each one a particular aspect of design. Second, to model associated design process models, we need to adopt a process model formalism. As our solution provides many alternatives and paths, strategic oriented process models seems to be the solution. In particular, the MAP formalism belonging to this class can be employed to model the design process as we intend to do; that is why we keep it for our solution.
In the following, we present ¯rst, product models and their classi¯cation, and second, we give a brief description of the MAP formalism. Finally, we describe the di®erent situational factors in which navigation in process meta-model is based on.
Web development methods consider design phase as a phase of product models delivery, addressing each one a particular concern of design.
A typical web design approach deliver the following product models [
Although existing web development methods recommend to deliver
aforementioned models, we have noted that they do not consider them with the same
degree of importance. In fact, they focus on the informational aspect by
delivering: conceptual model, navigation model and presentation model. This is can
be justi¯ed by two reasons: (1) at the early beginning of the web, web
applications have primarily the role of disseminating information to users. This made
methods privilege information dimension and derived aspects such as
navigation and presentation; (2) informational dimension is recognized as fondamental
in the design of any web application type [
Consequently, others aspects besides the informational dimension should be considered during their design.
Based on this analysis, we have classi¯ed aforementioned product models in two classes: Commun models class and Features models class. The ¯rst class comprises conceptual model, navigation model and presentation model. The second class contains requirements analysis model, adaptation model, user model, business model and services model.
The proposed approach covers all aforementioned design product models and adopt the process meta-model MAP as modelling formalism. In the following, we present an overview of the MAP and its associated guidelines. 2.2
A MAP is a meta-process model which allows designing several processes under a single representation. It is a labelled directed graph with intentions as nodes and strategies as edges between intentions.
The directed nature of the graph shows which intentions can follow which ones.
A MAP is composed of one or more sections. A section is a triplet <source
intention I, target intention J, strategy Sij> that captures the speci¯c manner to
achieve the intention J starting from the intention I with the strategy Sij. An
intention is expressed in natural language and is composed of a verb followed
by parameters. Each MAP has two special intentions "Start" and "Stop" to
respectively begin and end the navigation in the MAP. Each intention can only
appear once in a given MAP. To each section, is associated a guideline that can
be one of the following three types: Simple, Tactic or Strategic. There are three
guidelines associated with a MAP: IAG, ISG and SSG. IAG can be one of the
aforementioned types namely tactic or simple or strategic while SSG and ISG
are always tactic guidelines. For more details see [
The process meta-model for the web applications design formalized using MAP is shown in ¯gure 1. It contains two core intentions "De¯ne Commun models" and "De¯ne Features models" in addition to "Start" and "Stop" intentions.
To allow designer going through the di®erent intentions of the map, the approach provides a set of factors called Situational Factors.
The ¯rst step is to analyze the projects, categorize them in situations, and
identify their speci¯c requirements. The categorization of situations is based on their
distinguishing characteristics. [
By analogy, we have proposed a list of situational factors characterizing current development situation. They help designer to choose the appropriate strategy among those presented in the map. We have identi¯ed the following factors: Application type: fkiosque application, Web Information System, Adaptive application, e-commerce applicationg All aforementioned types are obviously web applications; however they are di®erent in term of deliverable models during design process.
Application complexity is measured through the complexity of services offered by application. Being more complex than kiosque applications, WIS should be designed di®erently, by giving more attention to services modelling dimension.
The similarity with others applications factor speci¯es if the designer has already participated in the development of similar applications belonging to the same domain. It is to notice that web applications belonging to a same domain have similar structures and provide similar services. Thus, during design process, approach considers designer pro¯le by o®ering to him the possibility to reuse their past experiences.
This factor determines the adaptation degree of the application to users. A user-application adaptation having a high degree is speci¯c to adaptive applications. when designer consider user aspect during design process a user-centered approach, this factor will take Medium value. In other cases, this factor will be of a low degree.
This factor reveals either the problem description of the current project is well de¯ned and clari¯ed or not.
The approach considers the di®erent pro¯les of designers such whose having long experiences. In fact, they can exploit the di®erent design patterns collected and stored to be employed.
Situational factors guide designer during navigation through the design process meta-model. We continue, in the following section, with showing how the proposed approach employ these aforementioned factors during the design process.
The choice of a particular path among those of the meta-model of ¯gure 1 depends largely on purpose of designer in term of web application type to be designed. A more in-depth analysis of the process MAP shows that designer is guided in very deep and °exible ways. Associated sections are re¯ned to a lower level of abstraction proposing various techniques available to achieve the corresponding intentions.
From the "Start" intention, designer is faced to a choice of two alternatives. He can either progress to achieve "De¯ne Features Model" intention or "De¯ne Commun Model" intention.
When designing a simple web site (kiosk application) which problem description is well identi¯ed and requirements are well de¯ned, designer should progress to "De¯ne Commun Model" intention. In others cases, designer should progress to "De¯ne Features Model" intention.
When progressing to "De¯ne Commun Model" intention, designer can perform only one strategy named Informational-guided strategy. However, if he intends to progress to "De¯ne Features Model" intention, he is faced to three alternatives. These strategies can be performed in parallel or alternatively depending on given situation: Business-guided strategy is followed when designer intends to develop an ecommerce application. In this case, he needs to conceptualize both Business Model and Services Model. We provide designer with the ability to design a Services Model in particular for WIS which are characterized by a high complexity of service. This strategy will be re¯ned with a strategic guideline: a MAP at a lower level of abstraction. This latter contains two intentions: "De¯ne Business Model" and "De¯ne Services Model".
User-centered strategy can be performed when designing an adaptive application. In this case, designer needs to consider users aspects and/or adaptation techniques through a user model and/or an adaptation model.
Requirements-centered strategy helps to gather and form speci¯cation of users and stakeholder requirements.
All aforementioned guidelines associated to these strategies are re¯ned through a MAP at lower level of abstraction. We have to stress that these three strategies can be performed alternatively or together. Let's taken the example of an ecommerce application where requirements are all the time di®erent and several. In fact, such application is characterized by both a high complexity of services and heterogeneity of clients to who we should satisfy requirements. Consequently, all strategies Requirements-centered, User-centered and Business-guided strategy must be followed and achieved in this case.
Once "De¯ne Features Model" intention is achieved, designer should progress to "De¯ne Commun Model" intention either following informational-guided strategy or patterns-based strategy. We should recall that he can design a kiosk application and in this case, he follows also informational-guided strategy from "Start" intention. Being in one or other situation and at a lower level of granularity, re¯nement of this strategy is done through a MAP providing panoply of paths and strategies from "Start" and "Stop" intentions. It contains three core intentions: "De¯ne Conceptual Model", "De¯ne Navigation Model" and "De¯ne Presentation Model".
Beginning from the "Start" intention, designer is faced to two strategies to
achieve "De¯ne Conceptual Model" intention. The modelling techniques-based
strategy is applied when designer decides to start from scratch and to adopt a
well known conceptual data-model like ER model or any Object-Oriented
technique [
Once the "De¯ne Conceptual model" intention is achieved, designer progresses to achieve "De¯ne navigation model" intention either by following web design framework-guided strategy or process-guided strategy. The ¯rst consists on the same one as the previous step but navigation oriented at this level. The processguided strategy allows to be guided by a particular method selected as the most appropriate one from method components repository. The same strategies are, also, proposed to achieve "De¯ne Presentation Model" intention oriented, here, presentation dimension. Navigation in the Map is stopped by the validation strategy aiming to validate the di®erent product models de¯ned.
Once the most appropriate design process is selected, we proceed to the selection of method components based on a list of criteria by employing a multicriteria method. 4
We describe in this section how the approach allows selection of the most appropriate method components given a selected design process. The selection step is realized based on a set of selection criteria associated to each de¯ned product model. Designer is invited to attribute values to these criteria every time the process-guided strategy is selected.
We have ¯xed a set of selection criteria characterizing product models; we refer
readers to [
{ Notation (NOT) indicates the standardization degree of the notation. It can be Standard, Mix or Proper. { Evolved Dimensions (DIM) indicates dimensions that are considered during design. It can be Statique, Dynamique or Mixte. { Access Structures (StrAc) indicates wether method integrates additional navigation nodes. They allow acceding to navigation objects. It is a boolean criteria. { Adopted approach(APP) indicates the approach adopted to de¯ne the navigation model. It can be Button-up, Top-down or Mix. 4.1
To achieve selection of most appropriate components we propose to employ a
multi-criteria method such as the Analytic Hierarchy Process (AHP) method
[
The ¯rst step of AHP consists in determining analysis criteria, in our case,
selection criteria associated to product models. Next step aims to elaborate binary
comparison, in order, in one hand, to identify importance of one criterium
relatively to others, and in the other hand, evaluate method components relatively
to every criterium. Introduced values during evaluation should be conform to
the AHP table [
To achieve intentions included in selected design process, designer is invited to introduce his preferences by giving priorities between selection criteria as illustrated in ¯gure 2.
B0 NOT N1O=1T D3I=M1 St3r=A1c A7P=1PC1 00:51111 MC = BB DIM 1=3 1=1 5=1 5=1 CC VP C = BB@00::13119584CAC
B@SAtrPAPc 11==73 11==55 11==31 13==11 CA 0:0535
For instance, the value 7/1 evaluated between notation (NOT) and Adopted Approach (APP) indicates that designer judges that the ¯rst criterium (NOT) is much more important than the second criterium (APP). In another side, methods such as OOHDM, WebML, WSDM and UWE, examples of web development methods allowing the production of navigation model are evaluated in method repository. The method expert has the responsibility to compare methods according to every criterium of all product models as illustrated by ¯gure 3. It is to recall that existing methods do not support product models de¯nition with the same degree of importance. For employed notation, most of methods except UWE method based on UML standard employ mix notation. OOHDM, for example, combines OO technique with its proper notation (context, etc.) and WebML integrates content units with XML. Evaluation matrix and associated eigen vector are shown in ¯gure 3. For instance, the value 7/1 between UWE and WSDM means that the component of UWE method associated to the navigation model de¯nition is much more important that WSDM component relatively to Notation criterium. This is due to the fact that UWE is entirely based on the standard UML language.
0
BOOHDM M M 1 = BB WSDM
B@ UWE
WebML
OOHDM WSDM UWE WebML1 1=1 5=1 1=5 2=1 C 1=5 1=1 1=7 1=3 CC 5=1 7=1 1=1 7=1 AC 1=2 3=1 1=7 1=1
00:20571 VP M1 = BB@00::05771981CCA 0:1109
The same principle of evaluation is taken for all criteria of a particular product model. All eigen vectors obtained from evaluation matrix (in this case 4 vectors) form a matrix which will be multiplied by the eigen vector obtained from designer comparison matrix. The highest value in the AHP vector corresponds to the most adequate method that is UWE in this example. At this level, proposed approach continues to guide designer during application and employment of the selected components as they are stored in a method repository and rede¯ned according to COMET meta-model. 5
The paper has presented our proposed approach subscribing in the context of Web oriented Situational Method Engineering discipline. We have begun by describing the process meta-model which is formalized with MAP formalism and allows designer guidance in the selection of the most appropriate design process at di®erent levels of abstraction. We have focused, after that, in describing how the approach guides during selection of most appropriate components through ¯xed criteria. The approach provides, also, guidance in the application of selected method components. This part is not presented in this paper.
Remark 1. In the printed volumes, illustrations are generally black and white (halftones), and only in exceptional cases, and if the author is prepared to cover the extra cost for color reproduction, are colored pictures accepted. Colored pictures are welcome in the electronic version free of charge. If you send colored ¯gures that are to be printed in black and white, please make sure that they really are legible in black and white. Some colors as well as the contrast of converted colors show up very poorly when printed in black and white.