of crosscutting concerns in design models , improve the ..... for example, the users' personal wish list, wedding ..... concerns, there is a need to tackle both the.
Modeling and Composing Navigational Concerns in Web Applications. Requirements and Design Issues. Silvia Gordillo 1,3, Gustavo Rossi1,4, Ana Moreira2, Joao Araujo 2, Carla Vairetti 1, Matias Urbieta1 1 Lifia. Facultad de Informatica. Universidad Nacional de La Plata, Argentina 2 CITI/ dept. Informática, Faculdade de Ciências e Tecnologia, Universidade Nova de Lisboa, Portugal. 3 Also at CICPBA, 4Also at Conicet {gordillo,gustavo}@lifia.info.unlp.edu.ar, {amm, ja}@di.fct.unl.pt Abstract Complex applications, in particular Web applications, deal with a myriad of different concerns and some of them affect several others. The result is that these crosscutting concerns are scattered throughout different software artifacts and tangled with other concerns. In this paper we present an approach for modeling and composing navigational concerns in Web applications. By showing how to build partial navigation scenarios with user interaction diagrams, analyzing how they crosscut and defining corresponding composition rules, we add modularity to the requirements specification stage, facilitating reasoning about the requirements and a consequent tradeoff analysis to support informed decisions of on architectural choices Moreover, by focusing on navigation concerns during the early stages of applications development, we aim to address the impact of crosscutting concerns in design models , improve the discovering of meaningful design artefacts and improve traceability of design decisions.
1. Introduction and Motivation Web applications must cope with a myriad of functional and non-functional concerns. Some of them are typical of “conventional” software while others are idiosyncratic of the Web (such as navigation). Yet, others are application or domain-specific such as payment, advising, advertising, etc. The only way to deal with these concerns is to be able to correctly identify and modularize them, understand the impacts and trade-offs among them and the relationships between design artifacts that realize them.
While mature Web engineering approaches have dealt with the problem of separation of concerns (e.g. using well-known object-oriented techniques), they have not addressed the problems caused by crosscutting concerns, i.e. when the realization of a given concern is scattered along multiple components, or when different concerns are “tangled” in the same component (e.g. a class, a node or a method). For example, authentication behavior (e.g. testing that the user has logged) is usually “tangled” with base functionality behaviors, and scattered among different modules . Even those concerns which are not scattered but which influence core classes, complicate design further. When designers are faced with the multiplicity of application concerns typical of Web software, they have a small repertoire of abstraction and composition mechanisms (e.g. those provided by the underlying object-oriented approaches, e.g. [11, 13, 14]) to deal with those concerns separately. A possible consequence is that a design artifact (a class for example) might describe several disparate concerns, or the same concern may appear scattered through different components thus making evolution hard. We argue that in most cases, crosscutting concerns are responsible for the emergence of complex navigational structures and therefore they should be identified and handled earlier in development. Consider the simple example shown in Figure 1, part of the Amazon.com website, where information, relationships and operations corresponding to different concerns are present: the “Product Information” concern, marked with ellipse 1, allowing to obtain the basic product information (e.g. name, list price); the “Marketplace” concern at the right hand side for letting the user sell his products (2); the “Gifts”
concern allowing to manipulate wish lists (3); the “Advising” concern showing related CDs (4); the “Navigation History” concern on the left hand side, giving information on the recently viewed items (5), and the “User Record” concern on top allowing the user to have information about his order history (6). Other system concerns not shown in the Figure are: the “Sales” concern, which refers to the purchase of two products at reduced prices; the Reviews concern, which encompass operations for letting the user write and access reviews ; the “Multimedia” concern, which provides access to videos, or segments of a song; the “External Services” concern, which provides access to tickets for an artist’s show; the “Navigation Facilities” concern, which allows the access to other stores, the access to the shopping cart, etc. It is clear from the example above that the conceptual and navigation classes that abstract the CD page (e.g. using OOHDM [14] or UWE[11]) encompass information and functionality pertaining to different concerns. Notice also, that many outgoing links from this page correspond to different concerns, i.e. they might not be elicited just analyzing the basic product information needs. Moreover, part of this functionality might be volatile (they may have a short living interest to the system) or irregular (e.g. not all CDs provide videos or access to concert’s tickets).
Figure 1: Different concerns in the same page
Identifying concerns and encapsulating them in separate modules, independently from their crosscutting or non-functional nature is fundamental to support improved modularization, therefore facilitating reuse, traceability and evolution. In the example above, if we need to change some requirement related to the advising policy, we shouldn’t have to modify the class of the product information concern. This means that
incremental changes to a given concern should be oblivious to others. Given the dynamic nature of web applications, techniques for advanced separation of concerns appear to offer mechanisms that are worth being explored in this application domain. For example, aspect-oriented software development (AOSD) aims at handling crosscutting concerns at the various levels of the software development process, by providing means to their systematic identification, modularization and composition [8]. These concerns are encapsulated in separate modules, known as aspects, and composition mechanisms are later used to weave them back with other core modules . Typical examples of crosscutting concerns are non-functional requirements, such as security, availability, and persistency. However, crosscutting concerns can also encompass functional requirements, such as order auditing, and in the Web engineering domain, tracing the user navigation history. At the requirements level, aspects or themes [6] allow the modularization of crosscutting concerns that cannot be encapsulated by a single use case [10], for example, and are typically spread across several of them. This paper shows how the ideas of advanced separation of concerns can be applied to improve requirements specifications and early design stages of Web applications. It presents an approach that allows the early capture of crosscutting concerns that affect navigation and their representation using separated analysis artifacts. It helps to produce a modular design model, in which aspects might, or might not, be used. The contributions of this paper are twofold: (i) offer a requirements approach to handle navigational concern s, characterizing the situations in which crosscutting exists; (ii) provide support for improving the construction of design models in complex applications. Additionally, we describe a software tool which allows capturing and modularizing requirements and provides hints to the designer regarding how to modularize crosscutting requirements. For conciseness, we base our discussion on the OOHDM [14] design approach, though the same ideas can be easily used by other object-oriented design methods, such as UWE [11] and OOWS [13]. The rest of the paper is structured as follows: Section 2 introduces navigational concerns and the core of our approach. Section 3 discusses how to improve design models . Section 4 presents our software tool. Section 5 analyzes related work and Section 6 concludes and provides some future research directions.
2. Identifying and Composing Navigational Concerns A concern refers to a feature that the future system needs to address to satisfy the stakeholders’ needs. Also, according to [12], a concern implies any coherent set of requirements, e.g. all requirements referring to a particular theme or behavioral application feature. Concerns may be functional such as Check-Out and Reviews or non-functional such as Usability and Availability. We define a navigational concern as an application concern that impacts in the way users navigate the application; a navigational concern is reflected in some navigational information structure (e.g. a web page, a link), or behavior (e.g. checking if the user is allowed to navigate to a page). As a consequence, a navigational concern will also impact in the application’s navigational model, either in a node or link class. These concerns may be realized in classes, methods, attributes (such as information or anchors), or links. For example, in order to satisfy the requirements in the Advising concern of Figure 1, we enrich the CD page with links pointing to other related CDs. Certainly, as nodes and links are derived from conceptual classes and relationships, navigational concerns (which certainly are application concerns) impact in the conceptual model. In this example, we might need to provide corresponding behaviors to calculate the related CDs using the appropriate algorithms. Notice that these behaviors do not correspond to the core of the CD class, and they certainly might vary at a different pace with respect to other CD responsibilities. Navigational concerns are critical in Web applications as the most important design decisions in these applications are related to the information they provide, their linking structure and the operations they support while the user navigates the information space. We say that navigational concerns crosscut when they are scattered throughout navigational classes (i.e. the same concern shows itself in different node or link classes), or when they are tangled (i.e. the same navigational class supports more than one concern). Crosscutting concerns may appear as information or behavior that seems not to completely belong to the current node, as links that “break” the current task flow, as conditions that have to be checked in different classes or methods, etc. Concerns shown in Figure 1 are examples of crosscutting navigational concerns. They all crosscut the same software artifact (a CD page).
Notice that crosscutting in navigational concerns may be originated in the intended interaction and navigation facilities, e.g. we want the user to be able to sell his products (Marketplace concern) while exploring a particular CD fo r shopping (Product Information concerns). Therefore, identifying cross-cutting concerns also helps to find non obvious links or operations. Besides, while some crosscutting navigational concerns may simplify the user’s task, they may also impact negatively in the application’s modularity, as tangling makes it difficult to isolate them (e.g. for maintenance purposes). More concretely, tangling means that the same navigation class provides information and links related to different concerns (e.g. buying, selling and advising). When some of these concerns evolve (e.g. new requirements appear) or new concerns are added, all design models might be impacted as a consequence of concern tangling and scattering. Notice that our definition of crosscutting is broader than the typical definition in aspect-oriented software design, where tangling has the flavor of code tangling. Therefore, the information we can derive from the fact that some concerns crosscut other concerns not only implies the definition of aspects , but also the identification of other design structures such as links, or other kinds of module compositions as we will show later in the paper. Early identification and description of navigational concerns help stakeholders to decide about potential trade-offs, improves application modularity and provide traceability to requirements, thus simplifying maintenance.
2.1. From meta to application specific concerns The model we envisage to deal with navigational concerns at the requirements level is illustrated in Figure 2 and has been inspired by [12]. Meta-Concern Space
System Space
Identify&Specify Concerns Concern identification and description Modelling navigation concerns w/ UID s
Concern Composition Identify Crosscutting Identify navigational units
Build crosscutting matrix
Define composition rules
Figure 2: Overview of the approach
Certain concerns, be functional or non-functional, appear once and again during system development. This was the drive to propose a reuse mechanism with a catalogue of concerns defined in a very abstract and system-independent fashion. This catalogue, here named meta-concern space, should be used to help eliciting the problem domain concerns. The idea is to use these meta-concerns, to help organizing the system space requirements (where the application domain is described), so that concerns of the problem domain are identified. These concerns can be seen as specializations of concerns at the meta-space level. Meta-concern and system spaces are represented by ovals in Figure 2. Both the abstract concerns in the meta-concern space as well as their concrete realizations are specified using a set of well-defined templates based on the eXtensible Markup Language (XML). A catalogue of non-functional concerns has been provided in [4]. Here, we extend the notion of such a catalogue to typical navigational concerns found in web applications, such as Shopping, Advising, Sales , Navigation History, etc. In summary, the system space contains the problem domain description we want to develop, obtained from different sources (interviews, ethnographic studies, analysis of business practices, etc.) and the metaconcern space contains a set of typical abstract concerns which repeatedly manifest themselves in various application domains. The identification of the concrete concerns can be achieved iteratively and incrementally, by handling small parts of the problem domain at a time. Note that not all concerns in the metaconcern space are necessarily used during this categorization; mostly only a subset of concerns relevant to the problem domain is needed. Some of the mo st important concrete concerns (from the catalogue of abstract concerns in the meta-concern space) we have identified for our Amazon case study are: • Product Information: to access basic information of the store products using different access strategies. • Shopping cart: to handle the user’s selection of products to be bought . • Authentication: to check personal information against a valid username and password. • Navigation history: to access to past information on previous user choices. • Advising: to suggest alternative and potential products of interest.
• • • • •
Gifts: to add, remove or update information about, for example, the users’ personal wish list, wedding list, gift certificates, etc. Checking out: to handle the payment of the purchases. Sales: to inform users about sales and handle respective discounts during purchasing. Donation: to collect funds to be donated to particular charity organizations. Marketplace: to allow users to sell his own products in the store.
As an example we show in Figure 3 one metaconcern, Information Retrieval and in Figure 4 one of its concrete concerns, Product Information. The operation of accessing information from a co mputer system Databas e retrieval, Multimedia retrieval Availability, Mobility, InformationUpdate
Figure 3: Information Retrieval meta-concern - The system will be accessed to provide basic information (e.g. for a CD there should be title, artist name, price, availability, cover, genre, record company, list of songs with name and excerpt), of the store products - Different search strategies such as finding the product given the title or part of the title can be used to access the product information. Products will be organized in categories according to musical genre
Figure 4: Product Information concrete concern
2.2 Specifying Navigational Requirements with UIDs Once the description of the problem domain has been organized into concrete specializations of concerns from the meta-concern space we can model the interactions related to each concern. To do that, those requirements in each navigational concern, which involve user interactions, are modeled with User Interaction Diagrams (UID) [9].
Similar to use cases [9], a UID describes the exchange of information between the user and the system, without considering user interface or design issues. UIDs enrich use cases with a simple graphical notation, allowing eliciting partial navigation paths. UIDs are simple state machines wherein each interaction step (i.e. each point in which the user is presented with some information and either indicates his choice or enters some value) is represented as an ellipse, and transitions between interaction points as arcs. We extend the UIDs to allow state numbering, which will be used later when we discuss composition of UIDs. In Figure 5, we show a UID for the use case “find a CD given its title”, which belongs to the concern Product Information. In Figure 6 we show the UID for the use case, “sell one’s CD given its title”, from the Marketplace concern. In the first interaction of Figure 5 (indicated by an incoming arrow), the user has to enter the title of the CD (or part of it), denoted by a rectangle with a continuous border, the response of the system is a set (represented by “…”) of CDs, matching the user input; for each CD it shows some information. The user chooses one of them (represented by “1”), and the system returns the complete information on the CD (represented inside the third ellipse). Additionally the user can perform an operation, add to shopping cart, indicated by a line with a black bullet. Figure 6 depicts an excerpt of the UID for one of the requirements of the concern Marketplace, the possibility that the user sells his own CDs. First, the user identifies the CD to sell by searching it as in Figure 5. Once found, the user chooses one and selects the operation Sell my CD, following the transition. Afterwards he must enter the actual CD condition (new, used, etc.), and some optional comments. Afterwards, s/he has to enter the intended price, location of the user and shipping method (third ellipse). The store informs other contending prices. The user confirms his identity and finally (not shown in the figure) he enters additional information such as credit card, contact telephone, etc.
Figure 5: A simple UID: Finding a CD given its title
Figure 6: Selling a CD providing its title
The complete syntax for UIDs can be found in [9]. A UID is built for each use case involving meaningful interactions between the user and the system. UIDs provide a first insight about the information and linking structures that the application will manipulate, and an outline of the possible navigation flows that can be validated with stakeholders. Using simple heuristics described in [9]) conceptual and navigational models can be derived from UIDs. Some navigational concerns, such as authentication, or adaptivity, will encompass requirements that do not have an associated user interaction, e.g. by implying a system check against the user identity (authentication) or some pre -processing before a link is traversed (adaptivity). In this case, there will be no associated UIDs, though these concerns are also analyzed regarding crosscutting.
2.3 Identifying Crosscuttings
and
Characterizing
Composition of concerns is then realized at the UID level and is achieved in two steps: (1) identifying navigational units and building a crosscutting matrix between navigational units and navigational concerns; (2) Composing UIDs of concerns which crosscut, analyzing how navigational units must be composed. A navigational unit (NU) is the requirement counterpart of a navigational class (e.g. a node) in the navigational model and reflects an information structure that emerges from an interaction state in a UID (e.g. a CD, a shopping cart, etc). These information structures usually represent some data items presented to the user, and are generally the basis for performing the next interaction state in a UID, e.g. because some information is selected. A NU arises in a concern, which is called its dominant concern. Some requirements might give raise to more than one NU, such as the
sequence of information structures arising during check-out and similar NUs might appear in different concerns. In our example we derive a unit for Product Information (PI) and another for Marketplace (MP), both representing some information of the product to be bought or sold . Other units (whose UIDs are not shown) are: SC (shopping cart unit), NH (navigation history), CO (check-out unit), S (sales unit), etc. UIDs for some concerns such as Advising or Authentication might be too simple and thus we will not derive navigation units from them. In our example, when accessing the information of a CD (the CD NU), we may wish to have an operation or link for selling our copy of the CD (the Marketplace concern) or to other recommended CDs (Advising concern), meaning that the NU is tangled with the concerns represented by the outgoing links. Product Information is the dominant concern of the NU, and Marketplace (or Advising) is the crosscutting navigational concern. A closer look at UIDs in the Product Information and Marketplace concerns will reflect the fact that the central information units are similar or identical. Slight differences among the CD while accessed in different concerns (e.g. Marketplace and Product Information) might give a cue to designers for using advanced design structures (such as aspects, themes [5], or roles [15]), as discussed in Section 3. Crosscutting is represented in a matrix (see Table 1) of the form Navigational Unit X Concern . For each navigational unit we analyze if it needs to provide information or operations pertaining to other navigational concerns, i.e. if the navigational concerns are accessible from or impact in that navigational unit. This is marked with a tick in the corresponding cell. A crosscutting concern is defined as a concern that is scattered among several navigation units. This means that the navigation units are tangled, since they include the properties of the dominant concern that originated them, as well as the properties of this new navigation concern. For example, it is plausible that facilities related with Advising can be reached from units that implement Product Information, Shopping Cart, Gifts, etc. Table 2 summarizes some of the most relevant concerns in the example.
NUSC
P
NUCO
P
CO
R G MP
S
NH
R
A
P
P
P
P
P
P
P
P
P
P
P
P P P
NUG
P
NUMP
P
P
P
NUS
P
P
P
NUNH
P
P
P
NUR
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
2.4 Composing UIDs The second step is to analyze the impact of crosscutting concerns on navigational units. We do so by composing those UIDs which reflect these concerns. Navigational units serve as the base for our compositions. In some cases the identification of crosscutting navigational concerns will not imply the composition of UIDs but meaningful information to be used in subsequent development activities (i.e. for those crosscutting involving concerns not represented by UIDs such as authentication or adaptivity). We have defined a set of composition rules which allow creating composite UIDs. To define composition structures, we extended the UID notation to include an identifier number in each state which is then accessed by using the “.” notation as: To access a transition, we use the specific operators target and source applied to states as: Target(UID_name.state_id). To access a state element we can also use the dot notation: UID_name.state_id.elementName. On top of this, we need several operators: AddConnection to add a link to a UID state, AddOperation to add an operation to a state or a state element, Merge to merge two UID’s states (with the semantics of set union) and AddTransition which creates a new transition, connecting two states from different UIDs. Any composition rule has the form: Compose with { [Merge | AddTransion | AddConnection | AddOperation] [to | with ] }
(PI: Product Information; SC: Shopping Cart; CO: Checking out; R: Registration; G: Gifts; MP: Market place; S: Sales; NH: Navigation History; R: Reviews; A: Advising; At: Authentication) SC
P
NUR
Table 2. Navigational crosscutting concerns
PI
P
NPPI
At
}
In Figure 7 we show the composition between the Product Information and Marketplace concerns shown
in Figures 5 and 6, which is defined in the following composition rule: Compose Product Information with MarketPlace { ProductInformation.3 AddConnection to Marketplace}
Figure 7: A connection to Marketplace added to Product Information
Notice that at this level of abstraction we are only showing that there is a connection between both UIDs. If, on the other hand, we want to see the full picture, by merging the navigational unit and navigation concern UIDs together, a different composition would be required: Compose Product Information MarketPlace { ProductInfo rmation.3 Merge with MarketPlace.3}
with
The resulting UID is shown in Figure 8. Notice that the merge operation has yielded a navigation unit (for CDs) which results from the composition of the two different views (Information and Marketplace). Bes ides, the composed UID has two entry points, corresponding to the components UIDs’s entry points. A consequence of this finding can obviously be the need to provide a new interaction state in which the user decides if he wants to sell or buy.
By analyzing the compositions this early in the web application development process, the modeler has a feeling of how the design artifacts will be affected. For example, when the modeler merges two states, according to the way the Merge operator works, the modeler can discuss with the stakeholder how the CD navigation unit should look like “coming from” marketplace or “coming from” product information. Therefore, decisions and/or tradeoffs can be identified and discussed before the subsequent design models are derived (See Section 3). Different combinations of concerns can be composed and shown to the stakeholders for validation and, more importantly, for anticipated study of a “look and feel” of the navigational structure of the future system. The stakeholder is offered the opportunity to choose when and where the navigational concerns (some of which are usually strongly coupled with business policies) may appear in the base system navigation structure. Incremental and iterative compositions also support improved evolution as new concerns (e.g. volatile concerns) can be easily added to, and no more wanted concerns removed from, the existing system without having to change the definition of the already specified and implemented concerns. As a consequence of this process it is possible to get further insight about the nature of crosscutting (e.g. for deciding design alternatives).
3. Improving Design Models As discussed in the previous section, the information gathered while analyzing crosscutting navigational concerns and their compositions is useful to enhance (or even define) the application’s design models. Next we give an overview of the kind of improvements that we can obtain from the previously proposed requirement model.
3.1 Specifying Classes and Relationships
Figure 8: Weaving together Product Information and Marketplace
UIDs have been used so far to derive conceptual and navigational models. By u sing simple rules it is possible to elicit conceptual classes and relationships. These rules analyze the information structures which emerge in UIDs states to derive classes, their attributes, operations and relationships. The idea of functional dependencies between attributes allows obtaining an initial class model; the reader can find a complete definition of these rules in [9].
Our approach improves these rules by explicitly describing the information structures which appear in UIDs’ states as Navigation Units, which are further used to analyze crosscutting. As similar units might be defined in different concerns we can enrich the initial class diagram by: • Discovering hidden relationships (which are derived from crosscutting information). For example, the fact that the Product Information and the Sales concerns crosscut means that we will have a relationship between the product and another related product in sale (e.g., the “Better Together” option in Amazon). • Finding new operations. The example above (Product Information crosscutting Sales) might need an operation similar to BuyBoth in Amazon which does not emerge trivially by analyzing individual UIDs. This operation will be allocated into the conceptual class Product. Another example is the crosscutting between Product Information and Gifts which indicates that the class Product must support an operation to add the product to a Gift list as shown in Figure 1. Notice that this behavior is quite simple and can be easily generalized to different lists by just adding a parameter but can only be discovered by understanding the interweaving between these two concerns. We may also find that crosscutting indicates more complex structural and behavioral patterns as discussed in the following subsection.
interactions in different concerns. For example, products exhibit different features when accessed in the Product Information concern or in the Marketplace concern. While it makes no sense to derive completely different classes from the corresponding NUs (i.e., only one class supporting Products will be created), we can improve the design of class Product by defining two different roles: ToSell and ToBuy. Each role implements the corresponding variability and, at the same time, allows us to indicate which products can not be sold by users, i.e. they can not play the ToSell role. For example it is not reasonable that users sell food (e.g. the Gourmet Food store in Amazon is not involved in a Marketplace). Finally, the same conceptual class may have to implement different themes which is indicated by a crosscut that implies the addition of many non-trivial operations; for example when requirements corresponding to the Advising concern (which crosscut Product Information) have to be implemented, we could just add operations which implement these requirements into the corresponding class (Product). However, the effect of this design choice is that we are polluting the class with methods that vary in a different pace (e.g. the recommendation criteria changes often or new kind of recommendations are implemented). A better solution is to create a separate desig n artifact, called a theme in [5], and later weave it into Product. This solution is more modular and requires less computational effort than aspects in the weaving process (as it might only require the juxtaposition of operations).
3.2 Discovering Aspects, Roles and Themes 3.3 Improving Navigational Schemas Sometimes, when a concern crosscuts another one it might mean that to perform an action (or to show information) corresponding to the former concern we need to check if some condition, belonging to the latter is satisfied. The most usual example of a crosscutting concern is Authentication. For example, to initiate the checkout, the user must be authenticated; analogously, to enter a review we need to check the user’s identity. In this case, the best design solution is to encapsulate the authentication behavior in an aspect and then weave it [8] into the corresponding concern. Notice that if new concerns arise whose dominant NUs are crosscut by Authentication, we could simply weave the authentication behavior into corresponding modules by just tracing requirement information forward to design (e.g., with a tool like the one described in Section 4). Roles [15] meanwhile can be identified by analyzing the variability of similar NUs when involved in
UIDs have been also used to help the designer derive the navigational schema from the conceptual schema. By analyzing different compositions of UIDs , as discussed in Section 2.4, we can obtain additional information on suitable navigation design structure s. The most important ones are: • Finding hidden links and therefore improving also the conceptual model with new relationships or operations. For example, the fact that Advising crosscut Shopping Cart indicates that we must implement links from the shopping cart to recommended products (e.g. the “See more items like those in the Shopping cart” option in Amazon). • Preventing the definition of “dangerous” links . The fact that the Checkout NU is not crosscut by most concerns, indicates that while checking out we
should not provide further links (e.g. to avoid reaching inconsistent states when abandoning the checkout process). This absence of crosscutting might appear as an explicit business rule or might have to be derived by closely analyzing Table 2. • Discovering “pure” navigational aspects, i.e. those which apply to the navigation and not the conceptual schema (as in [2]). An interesting example is the Navigation History; as the process to compute the history and the behavior to show it in the current page is completely located in the navigation classes (scattered through all nodes and also tangled), we can improve the modularity of the navigation model by defining a navigational aspect: Navigation History, and weave it into the final design model.
4. Tool Support We have implemented a prototype tool to prove our concepts in action. The UIDRe tool allows specifying and editing concerns and requirements, both from scratch and as instantiations of a repository of metaconcerns. For each requirement that involves an interaction, it is possible to specify the corresponding UID using a full-fledged graphical editor. Figures 9 and 10 show the look and feel of the tool with respect to concerns and UIDs specification in the Amazon.com example. The tool offers support for identifying NUs by extracting those structures defined in UIDs’ interaction states. Once defined, the NUs can be checked against different requirements to identify crosscutting requirements. Composition rules can be specified for different UIDs and the tool generates partial navigation scenarios, with applications mockups. In this way, it is possible to confirm that the intended composition satisfies the user’s requirements. All information is stored in XML files under the XMI standard.
Figure 9: Definition of concerns in UIDRe
Figure 10: Creating a UID
Using the tool we can derive an initial class model by systematizing the application of rules described in [9]; it also provides trace information from classes to concerns (backwards traceability) and from concerns to design artifacts (forward traceability). Our tool has been built on top of the Eclipse platform [7] using EMF, GEF and RCP technologies [7]. The tool architecture follows the philosophy of plugins which allows further composition and reuse. Consequently, the information compiled by the tool can be easily injected into other existing motors, such as code generators (e.g. for Java), MVC frameworks (such as Struts and Tapestry), etc. In this way a complete system prototype can be obtained covering data, business and interface layers.
5 Related Work Several Aspect-Oriented Requirements Engineering (AORE) approaches have appeared lately, such as the one described in [1, 6, 12]. [1] presents an aspectoriented scenario modeling approach, to be used at the requirements level. Non-aspectual scenarios are modeled using sequence diagrams and aspectual scenarios are modeled using Interaction Pattern Specifications. [6] proposes Theme to provide support to the requirements analysis activity by defining an approach to identify base and crosscutting behaviors from a set of actions. An action is a potential theme, which is a collection of structures and behaviors that represent one feature. The results of analysis are mapped to UML models. [12] defines a multidimensional approach to separation of concerns in requirements engineering as well as a trade-off analysis of the requirements specification from such a multidimensional perspective. One of the key elements of the approach is the notion of a meta-concern space, a catalogue of typical concerns, functional and nonfunctional, that manifest themselves time and again in various software systems. The abstract concern definitions in this meta-concern space are used as a
basis to delineate requirements into concrete concerns. None of these approaches address navigational concerns explicitly. Given the specificity of navigational concerns, there is a need to tackle both the specification of such concerns, as well as their respective compositions. Here, we adapted a well known navigational modeling technique to support the specification and composition of crosscutting navigational concerns. The idea of navigational unit s has been inspired in the concept of navigation semantic unit in [3]. In their approach for navigation analysis, the authors derive navigation semantic units and navigation semantic links from use cases. Similarly, our navigation units are derived from UIDs (a graphical representation of use cases) and also represent a first step in the definition of navigation classes (nodes and links). Our approach can be used to improve navigation analysis by introducing concerns and concerns crosscutting. In [2] the authors use aspects to separate concerns in adaptive hypermedia. The UWE’s navigational meta-model has been extended to support the specification of different kinds of adaptive links aspects. Using our framework, adaptation would be considered a meta-concern; by analyzing the pattern of navigational cross-cutting in the concrete level (See Table 2), one can assess the need for an aspect-oriented solution for incorporating this cross-cutting concern. In [16] the authors propose a systematic means to elicit meaningful navigation relationships among application entities; this approach does not differentiate among the concerns which originate links or information needs, therefore yielding a somewhat monolithic model which might be difficult to maintain. The notion of crosscutting is not explored, thus producing less valuable information for the design stage.
6 Concluding Remarks In this paper we have presented a novel approach for modeling, analyzing and composing navigational concerns in Web Applications. While separation of concerns has been identified as a key strategy to improve modularity, it has not been used to model Web applications requirements so far. Similar to [12] we propose to group requirements that refer to the same application theme in concerns, by instantiating a metaconcern space. User Interaction Diagrams are later specified and concern crosscutting analyzed. Composition rules help to understand the interplay of these concerns and facilitate the interaction with stakeholders to early requirements validation. Our
approach also provides better information for designers to build modular and evolvable design models. The impact of early concerns and concerns crosscutting identification in the web application development process can be summarized as follows: • Improved separation of concerns (in this particular case, navigational concerns); • Incremental (and iterative) development through incremental composition; • Early identification of navigational concerns and crosscutting and tradeoff analysis before an architecture design is derived; • Better identification of design model features, such as non obvious links, roles and aspects . We are currently conducting research on: • Extension of the approach to handle other typical crosscutting concerns, such as security, availability, synchronization, etc. We are analyzing the interplay between navigational and application concerns, for example in order to derive non navigational crosscutting; as a consequence we are researching in how the information gathered during the process of UID composition can be used to improve application modeling. • Improvement of the UIDs semantics to allow the identification of every single element therein to be able to define a fully fledge composition language for UIDs. • Formal definition the heuristics which allow improving design models, extending the ones defined in [9]. • Comp letion of our software tool to cover the whole life cycle and acting as a concerns’ baseline, providing traceability forward and backwards of design decisions.
7. References [1] Araújo, J., Whittle, J., and Kim, D. Modeling and Composing and Validating Scenario-Based Requirements with Aspects in proceedings of the 12th International Requirements Engineering Conference (Kyoto, Japan, September 2004). [2] Baumeister H., Knapp A., Koch, N., and Zhang G. Modelling Adaptivity with Aspects. In Proceedings of the 5th International Conference on Web Engineering (ICWE2005) (Sydney, Australia), Springer Verlag LNCS. [3] Cachero, C., Koch, N.: Conceptual Navigation Analysis: a device and platform independent navigation specification. 2nd International Workshop on Web Oriented Software Technology. Málaga, Spain. June 2002.
[4] Chung, L., Nixon, B., Yu, E., Mylopoulos, J. NonFunctional Requirements in Software Engineering. Kluwer Academic Publishers, 2000. [5] Clarke, S., Baniassad, E. Aspect-Oriented Analysis and Design. The Theme Approach. Addison-Wesley, Object Technology Series, 2005. ISBN: 0-321-24674-8 [6] Early Aspects Home Page. In www.early_aspects.net [7] Eclipse Home Page. In www.eclipse.org. [8]Filman, R., Elrad, T., Clarke, S., Aksit, M. (eds.). AspectOriented Software Development. Addison-Wesley, 2004. [9]Güell, N., Schwabe, D., Vilain, P. Modeling Interactions and Navigation in Web Applications. ER (Workshops) 2000. (Utah,USA, October 2000) 115-127 [10]Jacobson, I.Object -Oriented Software Engineering. ACM Press 1996. [11]Koch, N., Kraus, A., Hennicker R. The Authoring Process of UML-based Web Engineering Approach. In st Proceedings of the 1 International Workshop on WebOriented Software Construction (IWWOST 01), (Valencia, Spain, June 2001) 105-119 [12]Moreira, A., Rashid, A., Araújo, J. Multi-Dimensional Separation of Concerns in Requirements Engineering in Proceedings of the 13th IEEE International Requirements Engineering Conference (RE 2005). (Paris, France, August 2005). IEEE Computer Society. [13]Pastor, O., Abrahão, S.M., Fons, J. An Object-Oriented Approach to Automate Web Applications Development in Proceedings of EC-Web 2001. (Munich, Germany, September 2001) 16-28. [14]Schwabe, D., Rossi, G. An Object-Oriented Approach to Web-Based Application Design. Theory and Practice of Object Systems (TAPOS). Vol 4 (1998) 207-225 [15] Steimann, F.: On the Representation of Roles in ObjectOriented and Conceptual modeling. Data and Knowledge Engineering 35 (2000) 83-106 [16] Yoo, J., Catanio, J., Paul, R., Bieber, M.: Relationship analysis in requirements engineering. Requir. Eng. 9(4): 238-247 (2004).
