The two approaches use model-to-model transformations to accelerate modeling tasks, by taking the information already modeled at the time the transformation is performed and generating new views (called Models in UWE, and Views in XIS2). These transformations reflect how those views would typically be modeled, and the designer is free to change the generated views to suit the application’s needs (e.g., showing an extra field in the UI, or adding an extra step in an activity diagram).
F – Generated application is complete. Of the analyzed approaches, only the Agile Platform considers that source code should not be edited manually: only the model itself can be edited, and generated code and databases are always kept out of the developer’s reach. All the other approaches consider traditional programming (i.e., the manual editing of generated source code artifacts) as an activity to occur during the development life cycle, in order to account for particular requirements that may not be expressible by the approach’s modeling language.
G – Independent from deployment environment. Except for the Agile Platform, all approaches are actually independent of the deployment environment. Because of their usage of high-level elements, WebML, UWE, and XIS2 can generate code for any web-oriented platform (e.g., ASP.NET, Apache Tomcat); XIS2 can also generate code for desktop-based platforms. The web-oriented version of Sketchflow generates a Silverlight application which, although requiring the Silverlight plugin installed on a web browser, can be considered as cross-platform because it is available for the Microsoft Windows, Linux, and Mac OS X platforms. Finally, models created in the OutSystems Agile Platform can only be deployed to OutSystems’s deployment stacks, which use either (1) the JBoss application server and Oracle database, or (2) Microsoft’s IIS application server and SQL Server Express database. Although in this aspect the Agile Platform is apparently more limited than the other approaches, this is what allows it to automate most of the web application development life cycle, namely deployment and application upgrade/rollback scenarios.
4.2
Additional Related Work
Besides the web modeling approaches analyzed in this section, we have also found other work regarding development of modeling languages for web-based systems.
The work presented in [WSSK 07] describes the authors’ results in defining a metamodel that is common to both WebML and Object-Oriented Hypermedia (OO-H)6; the authors
6
plan to support UWE in the near future. The objective is to (1) define a set of model-to- -model transformations that enable bidirectional transformations between the supported languages, and (2) ultimately define a web-oriented modeling language, which the authors designate as Unified Web Modeling Language, that unifies all of the contemplated web modeling languages. However, there are some semantic mismatches between these different metamodels. An immediate example is the definition of the user interface (based on typical HTML elements), which in UWE is performed in the Presentation Model, while in WebML such details are derived (when defining pages, the focus of WebML is on defining data manipulation workflows, and not the interface that will support those workflows). The authors do not specify how they plan to handle such mismatches, namely regarding the possible loss of information during transformations between models of different languages.
On the other hand, the work described in [Wri 09] also proposes a web modeling language, called Internet Application Modelling Language (IAML). However, instead of trying to define generic web concepts and adapting them to a set of specific contexts, the author uses RIA (Rich Internet Application) concepts to shape IAML into a RIA-oriented modeling language. In our perspective, the results of this work could be used to complement the results of our research work (namely the modeling languages that we defined, which are presented in Chapters 7–8), as the research domains are connected in the sense that they both deal with model-driven web application development. Nevertheless, such an integration would be beyond the scope of this dissertation, which is why we consider this only as possible future work.
Summary
Although currently most web applications are still developed in a manual fashion (i.e., through typical programming tasks), the concept of developing web applications in a model-driven manner is rapidly growing in popularity. Examples of this growth trend can be found in the number of web application modeling languages, such as those analyzed in this chapter and further detailed in Appendix A.
In this chapter, we have presented an analysis of a select set of web application-oriented modeling approaches and languages. This analysis, in turn, was focused primarily on aspects that are relevant to this kind of modeling languages. Figure 4.1 provides a simple mindmap overview of the analyzed aspects.
From this analysis, we have also extracted a set of problems (which will be presented in Chapter 6), as well as some considerations that should be taken into account when proposing a solution.
4.2. ADDITIONAL RELATED WORK
Figure 4.1: Overview of aspects and problems regarding web application modeling lan- guages.
In the next chapter, we provide an analysis of Content Management System (CMS) systems, another important topic of this dissertation. These systems, besides providing their users (not only content administrators but also consumers) with a useful set of features like modularity or access management, also present some characteristics that make them suitable for the development of web applications, namely the extensible architecture with which they are usually built.
Chapter 5
Content Management Systems
A bad website is like a grumpy salesperson.
Jakob Nielsen Although the idea of managing content has been around since the dawn of the Inter- net, it was only in the last years that we have begun witnessing an explosion of CMS systems [Boi 01, SATE 03]. A Content Management System (CMS) is a particular kind of web application that is oriented toward the management and publishing of content (which can be almost anything, like a blog post, a forum entry, some HTML text, or a video). These systems typically endow content administrators and consumers (i.e., regular users that just browse the website) with a set of relevant aspects such as (1) modularity, (2) in- dependence between content and its presentation, (3) access management, (4) user control, or (5) configurable visual appearance and layout of content. Furthermore, development of CMS-based web applications is a topic that has only recently been proposed, as most CMS systems did not provide developers with an adequate set of features until a short time ago.
In this chapter we analyze the following CMS systems, which we consider relevant to our research work:
1. DotNetNuke1 [HRW 09];
2. Drupal2 [BBH+ 08]; 3. Joomla3 [SC 09];
4. Vignette Content Management4; and 5. WebComfort5 [SS 08 b].
1
http://www.dotnetnuke.com (accessed on March 15th, 2012)
2
http://drupal.org (accessed on March 15th, 2012)
3
http://www.joomla.org (accessed on March 15th, 2012)
4
http://www.vignette.com (accessed on March 15th, 2012)
5
Although there is a constantly increasing number of CMS systems available6, these
were selected for analysis because of the significant differences that they exhibit among themselves. Other CMS systems (e.g., WordPress7, a very popular blogging system that is
nevertheless considered by the community as a CMS system), although just as suitable for analysis as the ones previously mentioned, would yield very similar results – for example, an analysis of WordPress would result in nearly the same values as Joomla –, making their inclusion into this analysis redundant.
5.1
Comparative Analysis
In this section, we present our analysis of these CMS systems. Like in Chapter 4, we start by introducing the analysis criteria, and then proceed to the results that have been obtained from this analysis. Furthermore, the analysis of these CMS systems is further detailed in Appendix B.
5.1.1
Analysis Criteria
This analysis is mostly focused on characteristics obtained from (1) our own experiences with using these systems during our research, and (2) the knowledge acquired while developing the WebComfort CMS [SS 08 b] and some web applications that are supported by it, such as WebC-Docs [SS 09 b, SS 11 a]. More specifically, the criteria used covers aspects that range from administrative capabilities (such as configuration of the website’s structure or multi-tenancy support) to developer-oriented features like extensibility or providing a specific approach for the development of CMS-based web applications.
A – Management approach. CMS systems typically use one of two management approaches [Vignette 09]: page-centric and content-centric. A page-centric approach considers that the website’s structure (i.e., a set of pages and components) must be defined first, and afterward content is defined within the context of that structure. On the other hand, a content-centric approach dictates that the content itself must be defined, and afterward the administrator can specify a structure of pages that will show some of that content. This aspect analyzes which of these management approaches is used by the CMS.
B – Customizable website structure. This aspect determines whether the CMS system allows its administrator users to customize the website’s structure, in such a way
6
An extensive list of existing CMS systems is available at http://www.cmsmatrix.org and http://www. opensourcecms.com.
7
5.1. COMPARATIVE ANALYSIS
that effectively allows visitors to perceive the website’s organization as a (structured) hierarchical set of pages. Although this aspect might seem irrelevant (as it appears to favor CMS systems with a page-centric management approach), it is actually used to indicate whether the CMS supports the specification of a website structure; this structure, in turn, is often fundamental to help visitors when navigating the website and accessing published content.
C – Customizable visual layout of page. Besides the possibility of customizing the website’s structure, administrators should also be able to customize the website’s visual layout (i.e., the website’s look-and-feel, such as the colors used, or the relative location of each container that pages will use to show content). This aspect determines whether the CMS supports any such visual mechanism.
D – Supports multi-tenancy. Multi-tenancy consists of whether it is possible for someone to create a logical set of websites within the same CMS installation. In other words, this aspect determines whether a single physical CMS installation can support the definition of multiple logical websites (e.g., a personal website and an eCommerce website), each of which is usually accessible via a different URL (Universal Resource Locator).
E – Multiple kinds of persistence. A CMS system, due to its dynamic nature, must persist (i.e., store) its information somewhere (e.g., a database, or even the file system). Although at first sight this aspect might only seem to be a technology-related detail, it is important to note that the importance of this aspect is derived from the decoupling of the web application logic and the persistence mechanism, which in turn introduces the notion that domain modeling in a CMS-oriented language should not depend on – or even assume – technology-specific details (such as database views).
F – Can be extended by third-parties. This aspect scrutinizes the mechanisms that are provided by the CMS system for its extension by third-parties (e.g., whether the CMS provides an API to develop new features). This analysis is particularly focused on the following items: (1) what languages (programming languages or otherwise) can be used; (2) whether it is possible to use the security features provided by the CMS to constrain
possible actions (or show further information); (3) whether changing the CMS system’s default behavior is allowed; and (4) if it is possible to add new behavior (e.g., new CMS components, or additional code to run when specific events occur) to the system.
G – Development approach. This final aspect analyzes the kind of approach (if any) that the CMS supports for the development of web applications based on it (even if the
web application consists just of customizations, extensions, or anything that changes the system’s default behavior). More specifically, we determine: (1) if the CMS does consider any particular approach for the development of such web applications; and, if it does consider such an approach, (2) whether it is model-driven or if it is performed in a more traditional, source code-driven, manner.
5.1.2
Analysis Results
The analysis of these CMS systems, according to the previously listed criteria, has resulted in the values presented in Table 4.1.
Table 5.1: Relevant characteristics of the analyzed CMS systems. DotNet-
Nuke Drupal Joomla Vignette
Web- Comfort A. Management approach Page-
-centric Content- -centric Content- -centric Content- -centric Page- -centric B. Customizable website structure ! ! ! ! !
C. Customizable visual layout of
page ! ! ! ! !
D. Supports multi-tenancy ! ! # ! #
E. Multiple kinds of persistence # ! # # !
F. Can be extended by third-parties ! ! ! ! ! Programming language(s) C#/ VB.NET PHP PHP Java C#/ VB.NET
Provides security features ! ! ! ! !
Can change default behavior ! # # # !
Can add new behavior ! ! ! ! !
G. Development approach Tradi- tional Tradi- tional Tradi- tional Tradi- tional Tradi- tional
A – Management approach. Regarding the management approach that is used by the analyzed CMS systems, we notice that both approaches (page-centric and content-centric) are used. More specifically, the DotNetNuke and WebComfort systems use a page-centric approach, in which the website’s structure (i.e., a set of tabs and modules) is defined first, and afterward content is specified in modules. Nevertheless, these two CMS systems
5.1. COMPARATIVE ANALYSIS
support the sharing of content between modules, via DotNetNuke’s module copy feature and WebComfort’s module copy and module reference features. On the other hand, the Drupal and Joomla systems use a content-centric approach, in which the administrator first defines the content that will be displayed to the user, and then defines a structure of pages that will show certain parts of the available content. The Vignette system itself can be considered as a mix of these two approaches, because content are defined independently and presented to the user by means of Vignette’s templating mechanism, which uses a predetermined website structure to present the existing content. Nevertheless, we consider Vignette as being mainly content-centric, due to the fact that it places greater emphasis on the definition of content instead of on the website’s structure definition.
B – Customizable website structure. All of the analyzed CMS systems allow ad- ministrators to customize the website’s structure as a hierarchical set of pages or nodes (combined with linking mechanisms such as Joomla’s menus [SC 09]), depending on the
management approach used by the CMS.
C – Customizable visual layout of page. The ability to customize the website’s visual layout (i.e., the website’s look-and-feel, such as the colors used, or the relative location of each container that pages will use to show content) is supported by all of the analyzed CMS systems.
D – Supports multi-tenancy. Multi-tenancy is supported in some of the analyzed CMS systems. More specifically, only Joomla and WebComfort lack support for multi- -tenancy, although in both cases this is an aspect which the developers are currently
working on. Nevertheless, we have observed that the CMS systems that do support this feature typically do so by defining a different database table prefix for each website, which means that the various logical websites are often completely independent from each other.
E – Multiple kinds of persistence. Regarding the persistence mechanisms used, only some CMS systems (namely Drupal and WebComfort) support multiple kinds of persistence mechanisms. More specifically, this feature comes in the shape of support for different kinds of DBMS (Database Management System), such as MySQL, PostgreSQL, or Microsoft SQL Server.
F – Can be extended by third-parties. All of these CMS systems allow extension by third-party developers. The aspects that can be used or extended by developers vary between systems, although some are common, such as security features (user and role
management). However, as with the supported persistence mechanisms, the technology- -specific details (such as the programming languages used) vary between different CMS systems, which further attests to the fact that CMS-oriented languages should be as technology-independent as possible. Also, all of these systems support adding features and behavior, but only some support changing the existing default behavior; in the latter case, this is typically done by using the Strategy design pattern [GHJV 95] (or a variant of it), and using the default built-in behavior only if no other strategy is available.
G – Development approach. None of the analyzed CMS systems consider an approach for customization or the development of extensions. Although, as mentioned in the previous paragraph, each of these systems provides some developer support – in varying forms, but typically consisting of an API for developing source code – the development approach itself is left for developers to determine, in an ad hoc manner.
5.2
Additional Related Work
Besides the CMS systems analyzed in this section, we have also found some recent work regarding development approaches for CMS-based web applications.
The work presented in [Car 06] defines a generic CMS metamodel that can be applied to most of the CMS systems that are available nowadays (including the ones analyzed in this chapter). Although this metamodel is highly focused on the structure of a CMS, we reuse parts of this metamodel in our own research work that is presented in this dissertation.
On the other hand, [Sch 08] describes the creation of a model interpreting web appli- cation (which the authors call Integration Generator) that interacts with the Limestone CMS8. The Integration Generator application receives an XML file (which, in turn, results from the XSLT transformation of a UWE model file, specified in the XMI format), and is responsible for configuring the target CMS system, namely by (1) interacting with the backing data store (such as a database server), and (2) generating the necessary support artifacts (e.g., ASP.NET pages and user controls).
Furthermore, [VVP 08] analyzes the suitability of the Object Oriented Web Solution (OOWS) method to the development of CMS-based web applications, and suggests some improvements derived from Situational Method Engineering. However, the approach only deals with high-level aspects, which leads to a lack of expressiveness when dealing with low-level details (such as specifying particular CSS classes).
8
This CMS’s address, http://www.limestoneweb.co.uk/Solutions/ContentManagement, was offline at the time of the writing of this dissertation.
5.2. ADDITIONAL RELATED WORK
Finally, the MDE approach presented in [SK 09] also aims to support business-users. This is done by defining a modeling language that addresses only high-level details (based on parts of other existing languages), and a conversion mechanism that takes a model and generates a CMS Configuration File (an XML file that will be interpreted by the CMS). This approach also suffers from some shortcomings of other MDE approaches, namely the lack of expressiveness to deal with low-level details; developers can change the generated CMS Configuration File using an XML editor, but this file only carries information regarding the high-level concepts that have been modeled (e.g., the steps of a certain business process), not details that are specific to the CMS domain (such as role, user, visual theme, or module). We consider that this is because the authors have also tried to restrain themselves to a single language, which ultimately brings the typical compromise between low-level details that can be modeled and ease of learning and using