Modeling Web Applications Using Java and XML ... - Semantic Scholar
Modeling Web Applications Using Java And XML Related Technologies Sam Chung Computing & Software Systems Institute of Technology University of Washington Tacoma Tacoma, WA 98402. USA [email protected] Abstract The purpose of this paper is to propose visual models for a web application using Java and XML related technologies. We consider a web application that uses 3tier architecture and each tier is distributed onto web, application, and data base servers. In the web applications, various Java and XML related technologies are employed in the form of different languages: clientside script language, server-side script language, objectoriented programming language, markup language, style sheet language, data language, schema definition language, etc. When diverse technologies are applied to a web application, software engineers need to understand how the components using the technologies are interrelated in terms of software architecture. By applying the RUP with UML to the web application, we show how visual models can be constructed for the web application. Even, we show that we can model components in the web application using non objectoriented languages such as script, markup, style sheet, schema definition, and data languages. In order to compare the modeling complexity of components, we propose a degree of modeling complexity based upon two criteria - the degree of language dependency and the degree of location dependency. Through the comparison criteria, we try to quantify how relatively difficult it is for us to model which components. Based upon the degree of modeling complexity, it is relatively difficult to model XHTML among components using non object-oriented languages. Among Java related technologies, since JSP has a higher degree of language dependency and a higher degree of location dependency, it is more difficult for us to model the JSP components.
1. Introduction Since the advent of the Internet and World Wide Web (WWW) in the early 1990’s, many organizations have developed their own web applications by integrating WWW and their existing business logics. Due to two
Yun-Sik Lee Computer Engineering & Graduate School of Venture Hoseo University Asan, Chungnam 366-795. Korea [email protected] strong benefits of web, “any time anywhere,” the size and the number of web applications have been very rapidly increased. However, the maintenance of a web application is getting difficult due to the inherent complexity of the system [1, 2, 5, 8]. In this paper, we consider a web application that uses various Java and XML related technologies. The web application employs 3-tier architecture – presentation, business logic, and data access tiers. For the presentation tier, eXtensible Hyper Text Markup Language (XHTML), Cascading Style Sheet (CSS), JavaScript, eXtensible Markup Language (XML), XML Schema Document (XSD), and Java Server Page (JSP) are used. For the business logic tier, JavaBean is used. For the data access tier, MySQL Database Management System (DBMS) and its type-4 Java Database Connectivity (JDBC) driver are employed. Each tier is distributed onto an Apache web server, a Tomcat JSP server, or a MySQL database server on a Linux platform, respectively. When diverse technologies are applied to a web application, software engineers need to understand how components using the technologies are interrelated in terms of software architecture. In this paper, a component means a physical and replaceable part of a system that confirms to provide the realization of a set of interfaces according to [2]. In order to explain software architecture, a visual modeling technique has been used in software industry. However, the previous modeling efforts have been limited to how to use a modeling language with a software development process in order to develop software architecture of a software system [2, 8] and have focused on systems using specific markup languages such as HTML or XML [3]. To model a web application using various languages and diverse technologies, we are interested in the following questions: • •
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
How can we construct visual mode for a web application using Java and XML technologies? How can we model components in the web application using different language types such as
•
script, markup, style sheet, schema definition, and data languages, in addition to object-oriented language? How can we compare the models of the components, based upon what criteria?
The purpose of this paper is to propose visual models for web applications using Java and XML related technologies and analyze the models based upon our novel criteria for relative model comparisons. For this purpose, a distributed computing environment for web application using Java and XML technologies is built and a web application is implemented in the environment. We consider a web application that uses 3-tier architecture and each tier is distributed onto web, application, and data base servers, respectively. By applying the Rational Unified Process (RUP) with Unified Modeling Language (UML) to the web application, we show how visual models can be constructed for the web application that uses objectoriented or non object-oriented languages. In order to compare the modeling complexity of components, we propose two criteria – the degree of language dependency and the degree of location dependency. Through the comparison criteria, we try to quantify how relatively difficult it is for us to model which components. This paper starts with previous efforts in modeling web applications in Section 2. In Section 3, a modeling process using UML, RUP, is described [2, 8]. In Section 4, a simple web application, which employs Java and XML technologies, is proposed as an example. In Section 5, based upon the approach in Section 3, we explain how visual models of the web application in [4] are built. In Section 6, the visual models are analyzed in terms of deployment, implementation, and design models. Also, for comparing different technologies, we propose two criteria and compare the technologies based upon the criteria. Finally, in Section 7, conclusions of this paper and future areas of investigation are presented.
2. Previous Efforts Since the Object Management Group (OMG) accepted the UML as the standard modeling language in 1997, many software companies have adapted the UML to visualize, specify, construct, and document their software products. Much information of UML modeling has been published in [2]. Most of the information was related to how to use UML with or without a software process. Also, some researchers applied the modeling techniques to web sites, Java applets, and database. Conallen introduced an approach for modeling web application specific elements with UML [5]. By using
UML extension mechanism, Conallen showed class diagrams of specific web elements of HTML such as forms, tables, etc. However, Conallen's approach is limited to design models of web pages that strongly depend upon design/logical view and class diagrams. Booch and et al in [2] used class and sequence diagrams to model a simple Java applet. They showed a component diagram for a simple web page, which consists of the applet and an image file. However, their main concern was to show an example of models with UML. Recently, Carlson modeled XML by using a schema of the XML [3]. The XML schema was relatively easily modeled by using the well-defined tree structure of the XML. Also, for modeling database systems, UML has been used instead of Entity-Relationship (ER) modeling. Gornik showed how UML could be used for data modeling in [7]. However, to the author’s knowledge, all previous efforts were limited to an application using a specific language, not the whole web application, in which many different languages are used.
3. RUP with UML There are several different software development processes [6]: extreme programming (XP), crystal family, open source, adaptive software development, scrum, feature driven development, dynamic system development method, Rational Unified Process (RUP), etc. Among them, since the RUP supports different views for a software system and its artifacts are more than source codes [8], it is chosen in this paper. By applying the RUP to a software system, we can show architectural views of models. In the RUP, models are the artifacts of workflows. The RUP has six core workflows – requirements, analysis, design, implementation, test, and deployment. The artifacts of each workflow, visual models, are generated in an iterative and incremental manner through four phases – inception, elaboration, construction, and transition. The artifacts of each workflow in the RUP, the models, are visualized by using UML [2, 4]. Visual modeling is a process to visualize, specify, construct, and document work products in standardized diagrams. Since the advent of UML in 1997, software industries have rapidly accepted UML as a standard modeling language for software intensive systems. UML supports nine diagrams: use case, class, object, component, deployment, sequence, collaboration, state chart, and activity diagrams. Some of the nine diagrams are fully or partially used to represent the model. The artifacts of each workflow are represented in a visual model to show an architectural view of the workflow. Each model consists of 4+1 views (use case
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
view, logical view, process view, component view, and deployment view). However, among the 4+1 views, the process view is integrated into use case and logical views within a UML supporting Computer Aided Software Engineering (CASE) tool. Therefore, only 4 views, which are use case, logical, components, and deployment views, are practically shown in the CASE tool. Table 1 shows the relationships among models, views, and diagrams of each workflow.
4. A Simple Web Application Considering the distinct characteristics of a web application, we propose a simple web application with the following guidelines. • The implementation of the system should not be hard but shows the typical architecture of a web application. • The client-side scripting languages, server-side scripting languages, and application languages are similar to reduce the language learning time of software developers. • The cost of the development environment should almost be zero to make the software developers free from software licenses. Based upon the guidelines, we consider a simple web application: A client can create his or her user e-mail account through the Internet by entering a text e-mail name and a numeric e-mail name. The double e-mail accounts are detected when the client tries to enter the same text and numeric email names. The entry is stored into a database. Internally, the system creates e-mail addresses for all clients by combining a text e-mail name, its numeric e-mail name, and the prefixed email extension. The results are displayed in XML format to the system administrator to be transferred to other systems. To implement the demo system according to the given guidelines, first we consider three tier architecture – presentation, business logic, and data access tiers. For each tier, we select proper technologies, languages, and open source (or free) software components. We assume Linux platforms are used. For client-side script programming, JavaScript is selected. For server-side script programming, JSP is chosen. For developing server-side applications, JavaBean is used. To design an input web page, XHTML is used with CSS and the input data is validated with JavaScript. For displaying an
output, XML is employed. For validating the XML, an XML XSD is implemented and published at a platform. To host web pages, an Apache web server is used. To support JSP and JavaBean, Tomcat JSP server and Java Standard Development Kit (SDK) are used. For data storage, MySQL DBMS and its JDBC are chosen.
5. Modeling a Web Application In this paper, since we assume that the simple web application was already developed and the source codes of the system are only available, we do reverse engineering on the system. A visual model is generated at each workflow and the model is expanded at next workflow. The workflow starts from deployment and ends with requirement. Among the six workflows in Section 3, we consider three workflows that are strongly related to software developers - deployment, implementation, and design workflows in order.
5.1. Building and analyzing the deployment model First, we start to build a deployment model, which is the artifact of deployment workflow. In the deployment workflow, we are interested in the following questions: • • •
The questions of system deployment can be answered by showing an architectural view of a deployment model. The deployment model in Figure 1 shows that the web application is deployed onto a Linux platform called turing. The Linux platform consists of three servers: an Apache web server shown as the httpd package, a Tomcat JSP server shown as the jakarta-tomcat-4.0.1 package, and a MySQL DBMS server shown as the mysql package. Two shell script files, java.sh and tomcat.sh, are used for Tomcat and Java SDK, respectively. For web-based input interface, email_info_entry.html is used. The HTML file uses a CSS file for display format, email_info_entry.css, and a JavaScript file for input data validation, email_info_entry.js. The email_info_display.html component calls email_info_insertion.jsp to store the given e-mail names into the Email_Info table in the HICSS database through a JDBC API, mm.mysql-2.0.11-bin.jar file. For webbased output interface, email_list_in_xml.jsp is used. The
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
What workstations are employed to deploy the system? What packages and/or components are deployed onto the workstations? Where are the components located at the workstations?
email_list_in_xml.jsp displays the list of e-mails of all users in XML format. Figure 1 shows how components using different languages are represented in the deployment diagram by using file extension and/or file location information. By using the .html file extension, the email_info_entry.html shows that HTML is used. The Email_info_entry.js shows that JavaScript is used. The Email_Info_Entry.css means that it is an external CSS file. The jsp extensions of both the email_info_insertion.jsp and the email_list_in_xml.jsp show that JSP is used for them. The EmailBean.class means that JavaBean has been used. The location of HTML component is determined according to the web server’s configuration. The HTML component is located at a special directory, public_html that can be recognized by the Apache web server. The locations of JavaScript and CSS components are dependent upon how HTML components call. The JSP and JavaBean components need to be located in the Tomcat JSP server to be recognized. The relational database HICSS and its table Email_Info is recognized by their locations. MySQL DBMS includes the HICSS database and it has Email_Info table.
5.2. Building and Analyzing the Implementation Model In addition to components that are deployed for the web application, there are different types of components such as source code files, library, and documents. In the implementation workflow, we are interested in the following questions: • • •
What components are used for implementing the system? How are the components interrelated to the components that were deployed in the deployment diagram? Where are the components located?
These implementation issues can be explained by using the architectural view of the implementation model. The implementation model in Figure 2 shows that a Java program, EmailBean.java, was implemented on another different platform, lovelace Windows workstation, and its compiled version, EmailBean.class, was deployed onto the Linux workstation, turing. Since the source program does not have to be deployed onto the production system called turing Linux server, it is found from a development system called lovelace Windows workstation. It shows that Java technology is platform
independent and the JavaBean source code exists on a different machine.
5.3. Building and Analyzing the Design Model Third, we start to build a design model with UML. Although UML is a good modeling language, its foundation comes from object-oriented modeling concepts. A component can be implemented in either a non-object oriented language or multiple different languages. In the design workflow, we are interested in the following questions: • • •
The questions of component design can be answered by showing an architectural view of a design model. First, JavaBean is considered. A JavaBean is a reusable general-format component in Java that can be handled by JSP action tags. All attributes of a JavaBean are private. The values of the attributes are accessed through accessor methods of the JavaBean. Since all properties of JavaBean follow the ones of Java and the UML supports object-oriented design, the modeling of a JavaBean can be done easily by using class notation in UML. EmailBean.java is modeled in the class diagram of Figure 3. Second, a database and tables of the database are considered. Instead of using the ER modeling on a relational table, a class in UML is used to represent the table. Attributes of the class represent columns. Operations of the class show entity integrity, referential integrity, or other constraints. A database is represented as a package in the class diagram. In Figure 4, the database HICSS package shows the HICSS database, in which there is only one table, Email_Info. Also, Figure 4 shows the directory structures org/gjt/mm/mysql and a class Driver for JDBC. Third, a CSS component is modeled by using a class diagram. A CSS component consists of style rules. Each style rule consists of a rule name and a rule definition. The rule name represents one or more system-defined class i.e. HTML tags or user-defined class names. (The class in CSS does not mean the class in object-oriented concept.) Each rule definition consists of attributes and their values. In Figure 5, we assign each style rule to a class in UML. The class name shows a style rule name. Its attributes consist of the rule definitions. Its operations are always empty. Fourth, a JavaScript component is modeled with a class. The class name of a JavaScript component comes
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
How are the components designed? What packages are used? What classes of which packages are used?
from the logical interpretation of its physical file name. A class for JavaScript may not have any attributes. Only the operations, which are function definitions in the JavaScript component, can be shown. Figure 9 shows a class diagram for a JavaScript Component. Fifth, an XHTML component is modeled in Figure 10. The predefined XHTML tags are defined as classes under xhtml package. The name of the XHTML component is represented as the name of the class. The names of forms or tables are represented as attributes of the class. By making separate components for CSS and JavaScript and saving them into separate packages, the XHTML modeling can be done on only XHTML tags. Sixth, an XML component is modeled in Figure 8. Instead of modeling an XML format directly, the schema definition of the XML format is modeled as Carlson used in [3]. From the given XML schema definition of the XML format for displaying the e-mail list, the type names of elements are used as class names. Seventh, JSP is modeled in Figure 9. Since various language types can be used in implementing a JSP component, a class diagram of a JSP component is generally complicated. A general structure of JSP is modeled in Figure 9. A directive in JSP is considered as a class with only attributes. The action tags are considered as operations in the JSP class. The class name of a JSP component comes from the logical interpretation of its physical file name. Also, many packages for JSP, java, and javax, are employed in the class diagram of a JSP component.
degree of location dependency shows how much the component needs to be located at a predefined directory. The degree of language dependency has more effects on the degree of modeling complexity than the degree of location dependency does since the location dependency does not need specific modeling techniques, except for creating packages and showing their relationships. Table 1. Components and their file extensions
Email_Info_Entry.html Email _Info_Entry.css Email _Info_Entry.js email _info_insertion.jsp email_list_in_xml.jsp EmailList.xsd EmailBean.class EmailBean.java
Degree of Lang. Depend.
Low
Medium
High
Linux Linux Linux Linux Linux Linux Windows
Degree of Loc. Depend.
Degree of Modeling Complexity
Low
0
Medium
1
High
2
Low
3
Medium
4
High
5
Low
6
Medium
7
High
8
Each degree can have low, medium, and high values as shown in Table 2. The values are determined relatively. If a component A uses more languages than another component B for implementation, the degree of language dependency of the component A is relatively higher than one of the component B. If two components use only one language and the language of a component is an object-oriented language, its degree of language dependency is relatively lower to the other component. If
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
Platform s Linux
Table 2. The degree of modeling complexity
6. Discussions on Models The deployment and the implementation models show distinct characteristics of a web application. First, instead of one type of component, many different types of components are deployed. Through the extensions of each component in Table 1, we can guess how many different technologies are used. Second, components are distributed onto different platforms through the network. In this example, the source code of a JavaBean and the XML schema document are developed at a Windows platform. However, their (executable) components are deployed at the Linux platform. In order to compare design models of each component, we propose the degree of modeling complexity. The degree of modeling complexity represents how much the component is complicated for building its design model. The degree is measured by the combination of the degree of language dependency and the degree of location dependency. The degree of language dependency denotes how many different languages are used to implement the component. The
File Extension Definition XHTML Cascading Style Sheet JavaScript Java Server Page Java Server Page XML Schema Document Java Class Java
Components
a component A uses more languages than another component B for implementation, the degree of language dependency of the component A is relatively higher than one of the component B. If the component A’s location needs to be predefined, its degree of location dependency is higher than others. The value of the degree of modeling complexity is determined by the combination of the degree of language dependency and the degree of location dependency. Each degree has a relative value from low, medium, to high. From the two criteria, there are nine combinations. If the combination of two degrees is low and low, the lowest rank 0 is assigned to the degree of modeling complexity. If the combination of two degrees is high and high, the highest rank 8 is assigned to the degree of modeling complexity. Since the modeling of components using objectoriented languages are relatively easier than one of components using non object-oriented languages, the degree of modeling complexity is applied to the two different groups: one uses object-oriented languages. The other one uses non object-oriented language. Table 3. Comparisons of modeling components using non-object oriented languages Languages Used
CSS XHTM L
XML SQL
Style sheet Markup Style sheet Objectbased Markup Schema definition Database
Degree of Lang. Depend.
Degree of Loc. Depend.
Low
Low
High
Medium
modeling XHTML components since XML support hierarchical concepts through a schema definition language and is represented by XML language. However, modeling an XHTML component is complicated since many different languages can be used for a web page implementation. For example, in-line or embedded styles and functions can be implemented by using CSS and JavaScript, respectively. In order to reduce the degree of the language dependency, we can use modular design concepts. Each module uses only one language and can be imported or referenced from the XHTML file. Also, some XHTML components need to be placed at a special place according to web server configuration. Table 4 shows the degree of modeling complexity for components using Java technologies with the values in Table 2. A JavaBean component can be modeled easily compared to a JavaScript component since it uses an object-oriented language Java. JavaBean and JSP components depend on the location of the components since the JSP sever needs to recognize them. Since a JSP component can use different languages, its degree of language dependency is high. Therefore, the modeling of a JSP component is harder than other components. Table 4. Comparisons of modeling components using java technologies
Degree of Modeling Complexit y 0 7
Languages Used Java Script JSP
Medium
Low
3
Low
High
2
Table 3 shows the measurements for components using non-object oriented languages with the values of the degrees of modeling complexity in Table 2. Based upon the degree of modeling complexity, we can say that modeling a CSS component is relatively the easiest one among the four components. Since each rule in a CSS component is described in only one language and its location is not predefined, a CSS component can be easily modeled by using a class diagram. Modeling a component using SQL is relatively easier but harder than the CSS component since the tables are located within a database and the location of database is defined by the given DBMS. Modeling XML is relatively easier than
Java Bean
Degree of Loc. Depend.
Degree of Modeling Complexit y
Medium
Low
3
High
High
7
Low
High
2
7. Conclusions and Future Researches We show how we can model the architecture of a web application using Java and XML related technologies. By applying the RUP to the system, we follow workflows of the RUP. The results of each workflow are represented in a model to show how the architecture of the system looks like. A visual model consists of four different views – use case, logical, component, and deployment views. Each view consists of some of the nine UML diagrams. By incrementally and iteratively integrating the models of workflows into a model, which we call a base model, the whole architecture is represented.
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
Objectbased Objectoriented Markup Style sheet Objectoriented
Degree of Lang. Depend.
Second, we show that we can model components in the web application using non object-oriented languages such as script, markup, style sheet, schema definition, and data languages. By using UML and its customization notation, we can also model components using non object-oriented languages. Third, in order to compare the modeling complexity of components using either object-oriented or non objectoriented languages, we propose the degree of modeling complexity based upon two criteria – degree of language dependency and degree of location dependency Fourth, by using the degree of modeling complexity, we can quantify how relatively difficult it is for us to model which components. Based upon the criteria, it is relatively difficult to model XHTML among components using non object-oriented languages. Among Java related technologies, since JSP has a higher degree of language dependency and a higher degree of location dependency, it is more difficult for us to model the JSP components. The modeling of components using non-objectoriented languages needs more researches. By using more examples of the components, more modeling techniques need to be discussed. Also, by expanding the application of modeling to more web applications, design patterns among the models need to be recovered to understand design ideas for other implementations. The design patterns can be used for reasoning better web application design.
8. References
[1] Brereton, P., Budgen, D., and Hamilton, G. (1998). Hypertext: The Next Maintenance Mountain. IEEE Computer. December 1998. pp. 49-55. [2] Booch, G., Rumbaugh, J., and Jacobson, I. (1999). The Unified Modeling Language User Guide. AddisonWesley, Menlo Park: CA. [3] Carlson, D. (2001). Modeling XML Applications with UML: Practical e-Business Applications. AddisonWesley, Menlo Park: CA. [4] Coleman, D. and et al. (1998). UML: the language of blueprints for software? OOPSLA, 1998. pp. 201-205. [5] Conallen, J. (1999). Modeling Web Application Architectures with UML. The Communications of the ACM. October 1999. Vol. 42. No. 10. pp. 63-70. [6] Fowler, M. (2001). New Methodology. ThoughtWorks, Inc. http://martinfowler.com/articles/newMethodology.html [7] Gornik, D. (2002). UML Data Modeling Profile. Rational Software White Paper. http://www.rational.com/media/whitepapers/tp162.pdf [8] Jacobson, I., Booch, G., and Rumbaugh, J. (1999). The Unified Software Development Process. AddisonWesley, Menlo Park: CA.
Figure 1. Deployment model
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
Figure 2. Implementation model
Figure 3. A class diagram for the EmailBean.java component
Figure 4. A class diagram for the HICSS database and MySQL JDBC
Figure 5. A class diagram for the email_info_entry.css component
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
Figure 6. A class diagram for the email_info_entry.js component
Figure 7. A class diagram for email_info_entry.html component
Figure 8. A class diagram for user_email_info.xsd component
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
(a) A class diagram for JSP
(b) A class diagram for email_info_insertion.jsp component
(c) A class diagram for email_list_in_xml.jsp component Figure 9. Modeling a .jsp component
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
1. Introduction Since the advent of the Internet and World Wide Web (WWW) in the early 1990’s, many organizations have developed their own web applications by integrating WWW and their existing business logics. Due to two
Yun-Sik Lee Computer Engineering & Graduate School of Venture Hoseo University Asan, Chungnam 366-795. Korea [email protected] strong benefits of web, “any time anywhere,” the size and the number of web applications have been very rapidly increased. However, the maintenance of a web application is getting difficult due to the inherent complexity of the system [1, 2, 5, 8]. In this paper, we consider a web application that uses various Java and XML related technologies. The web application employs 3-tier architecture – presentation, business logic, and data access tiers. For the presentation tier, eXtensible Hyper Text Markup Language (XHTML), Cascading Style Sheet (CSS), JavaScript, eXtensible Markup Language (XML), XML Schema Document (XSD), and Java Server Page (JSP) are used. For the business logic tier, JavaBean is used. For the data access tier, MySQL Database Management System (DBMS) and its type-4 Java Database Connectivity (JDBC) driver are employed. Each tier is distributed onto an Apache web server, a Tomcat JSP server, or a MySQL database server on a Linux platform, respectively. When diverse technologies are applied to a web application, software engineers need to understand how components using the technologies are interrelated in terms of software architecture. In this paper, a component means a physical and replaceable part of a system that confirms to provide the realization of a set of interfaces according to [2]. In order to explain software architecture, a visual modeling technique has been used in software industry. However, the previous modeling efforts have been limited to how to use a modeling language with a software development process in order to develop software architecture of a software system [2, 8] and have focused on systems using specific markup languages such as HTML or XML [3]. To model a web application using various languages and diverse technologies, we are interested in the following questions: • •
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
How can we construct visual mode for a web application using Java and XML technologies? How can we model components in the web application using different language types such as
•
script, markup, style sheet, schema definition, and data languages, in addition to object-oriented language? How can we compare the models of the components, based upon what criteria?
The purpose of this paper is to propose visual models for web applications using Java and XML related technologies and analyze the models based upon our novel criteria for relative model comparisons. For this purpose, a distributed computing environment for web application using Java and XML technologies is built and a web application is implemented in the environment. We consider a web application that uses 3-tier architecture and each tier is distributed onto web, application, and data base servers, respectively. By applying the Rational Unified Process (RUP) with Unified Modeling Language (UML) to the web application, we show how visual models can be constructed for the web application that uses objectoriented or non object-oriented languages. In order to compare the modeling complexity of components, we propose two criteria – the degree of language dependency and the degree of location dependency. Through the comparison criteria, we try to quantify how relatively difficult it is for us to model which components. This paper starts with previous efforts in modeling web applications in Section 2. In Section 3, a modeling process using UML, RUP, is described [2, 8]. In Section 4, a simple web application, which employs Java and XML technologies, is proposed as an example. In Section 5, based upon the approach in Section 3, we explain how visual models of the web application in [4] are built. In Section 6, the visual models are analyzed in terms of deployment, implementation, and design models. Also, for comparing different technologies, we propose two criteria and compare the technologies based upon the criteria. Finally, in Section 7, conclusions of this paper and future areas of investigation are presented.
2. Previous Efforts Since the Object Management Group (OMG) accepted the UML as the standard modeling language in 1997, many software companies have adapted the UML to visualize, specify, construct, and document their software products. Much information of UML modeling has been published in [2]. Most of the information was related to how to use UML with or without a software process. Also, some researchers applied the modeling techniques to web sites, Java applets, and database. Conallen introduced an approach for modeling web application specific elements with UML [5]. By using
UML extension mechanism, Conallen showed class diagrams of specific web elements of HTML such as forms, tables, etc. However, Conallen's approach is limited to design models of web pages that strongly depend upon design/logical view and class diagrams. Booch and et al in [2] used class and sequence diagrams to model a simple Java applet. They showed a component diagram for a simple web page, which consists of the applet and an image file. However, their main concern was to show an example of models with UML. Recently, Carlson modeled XML by using a schema of the XML [3]. The XML schema was relatively easily modeled by using the well-defined tree structure of the XML. Also, for modeling database systems, UML has been used instead of Entity-Relationship (ER) modeling. Gornik showed how UML could be used for data modeling in [7]. However, to the author’s knowledge, all previous efforts were limited to an application using a specific language, not the whole web application, in which many different languages are used.
3. RUP with UML There are several different software development processes [6]: extreme programming (XP), crystal family, open source, adaptive software development, scrum, feature driven development, dynamic system development method, Rational Unified Process (RUP), etc. Among them, since the RUP supports different views for a software system and its artifacts are more than source codes [8], it is chosen in this paper. By applying the RUP to a software system, we can show architectural views of models. In the RUP, models are the artifacts of workflows. The RUP has six core workflows – requirements, analysis, design, implementation, test, and deployment. The artifacts of each workflow, visual models, are generated in an iterative and incremental manner through four phases – inception, elaboration, construction, and transition. The artifacts of each workflow in the RUP, the models, are visualized by using UML [2, 4]. Visual modeling is a process to visualize, specify, construct, and document work products in standardized diagrams. Since the advent of UML in 1997, software industries have rapidly accepted UML as a standard modeling language for software intensive systems. UML supports nine diagrams: use case, class, object, component, deployment, sequence, collaboration, state chart, and activity diagrams. Some of the nine diagrams are fully or partially used to represent the model. The artifacts of each workflow are represented in a visual model to show an architectural view of the workflow. Each model consists of 4+1 views (use case
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
view, logical view, process view, component view, and deployment view). However, among the 4+1 views, the process view is integrated into use case and logical views within a UML supporting Computer Aided Software Engineering (CASE) tool. Therefore, only 4 views, which are use case, logical, components, and deployment views, are practically shown in the CASE tool. Table 1 shows the relationships among models, views, and diagrams of each workflow.
4. A Simple Web Application Considering the distinct characteristics of a web application, we propose a simple web application with the following guidelines. • The implementation of the system should not be hard but shows the typical architecture of a web application. • The client-side scripting languages, server-side scripting languages, and application languages are similar to reduce the language learning time of software developers. • The cost of the development environment should almost be zero to make the software developers free from software licenses. Based upon the guidelines, we consider a simple web application: A client can create his or her user e-mail account through the Internet by entering a text e-mail name and a numeric e-mail name. The double e-mail accounts are detected when the client tries to enter the same text and numeric email names. The entry is stored into a database. Internally, the system creates e-mail addresses for all clients by combining a text e-mail name, its numeric e-mail name, and the prefixed email extension. The results are displayed in XML format to the system administrator to be transferred to other systems. To implement the demo system according to the given guidelines, first we consider three tier architecture – presentation, business logic, and data access tiers. For each tier, we select proper technologies, languages, and open source (or free) software components. We assume Linux platforms are used. For client-side script programming, JavaScript is selected. For server-side script programming, JSP is chosen. For developing server-side applications, JavaBean is used. To design an input web page, XHTML is used with CSS and the input data is validated with JavaScript. For displaying an
output, XML is employed. For validating the XML, an XML XSD is implemented and published at a platform. To host web pages, an Apache web server is used. To support JSP and JavaBean, Tomcat JSP server and Java Standard Development Kit (SDK) are used. For data storage, MySQL DBMS and its JDBC are chosen.
5. Modeling a Web Application In this paper, since we assume that the simple web application was already developed and the source codes of the system are only available, we do reverse engineering on the system. A visual model is generated at each workflow and the model is expanded at next workflow. The workflow starts from deployment and ends with requirement. Among the six workflows in Section 3, we consider three workflows that are strongly related to software developers - deployment, implementation, and design workflows in order.
5.1. Building and analyzing the deployment model First, we start to build a deployment model, which is the artifact of deployment workflow. In the deployment workflow, we are interested in the following questions: • • •
The questions of system deployment can be answered by showing an architectural view of a deployment model. The deployment model in Figure 1 shows that the web application is deployed onto a Linux platform called turing. The Linux platform consists of three servers: an Apache web server shown as the httpd package, a Tomcat JSP server shown as the jakarta-tomcat-4.0.1 package, and a MySQL DBMS server shown as the mysql package. Two shell script files, java.sh and tomcat.sh, are used for Tomcat and Java SDK, respectively. For web-based input interface, email_info_entry.html is used. The HTML file uses a CSS file for display format, email_info_entry.css, and a JavaScript file for input data validation, email_info_entry.js. The email_info_display.html component calls email_info_insertion.jsp to store the given e-mail names into the Email_Info table in the HICSS database through a JDBC API, mm.mysql-2.0.11-bin.jar file. For webbased output interface, email_list_in_xml.jsp is used. The
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
What workstations are employed to deploy the system? What packages and/or components are deployed onto the workstations? Where are the components located at the workstations?
email_list_in_xml.jsp displays the list of e-mails of all users in XML format. Figure 1 shows how components using different languages are represented in the deployment diagram by using file extension and/or file location information. By using the .html file extension, the email_info_entry.html shows that HTML is used. The Email_info_entry.js shows that JavaScript is used. The Email_Info_Entry.css means that it is an external CSS file. The jsp extensions of both the email_info_insertion.jsp and the email_list_in_xml.jsp show that JSP is used for them. The EmailBean.class means that JavaBean has been used. The location of HTML component is determined according to the web server’s configuration. The HTML component is located at a special directory, public_html that can be recognized by the Apache web server. The locations of JavaScript and CSS components are dependent upon how HTML components call. The JSP and JavaBean components need to be located in the Tomcat JSP server to be recognized. The relational database HICSS and its table Email_Info is recognized by their locations. MySQL DBMS includes the HICSS database and it has Email_Info table.
5.2. Building and Analyzing the Implementation Model In addition to components that are deployed for the web application, there are different types of components such as source code files, library, and documents. In the implementation workflow, we are interested in the following questions: • • •
What components are used for implementing the system? How are the components interrelated to the components that were deployed in the deployment diagram? Where are the components located?
These implementation issues can be explained by using the architectural view of the implementation model. The implementation model in Figure 2 shows that a Java program, EmailBean.java, was implemented on another different platform, lovelace Windows workstation, and its compiled version, EmailBean.class, was deployed onto the Linux workstation, turing. Since the source program does not have to be deployed onto the production system called turing Linux server, it is found from a development system called lovelace Windows workstation. It shows that Java technology is platform
independent and the JavaBean source code exists on a different machine.
5.3. Building and Analyzing the Design Model Third, we start to build a design model with UML. Although UML is a good modeling language, its foundation comes from object-oriented modeling concepts. A component can be implemented in either a non-object oriented language or multiple different languages. In the design workflow, we are interested in the following questions: • • •
The questions of component design can be answered by showing an architectural view of a design model. First, JavaBean is considered. A JavaBean is a reusable general-format component in Java that can be handled by JSP action tags. All attributes of a JavaBean are private. The values of the attributes are accessed through accessor methods of the JavaBean. Since all properties of JavaBean follow the ones of Java and the UML supports object-oriented design, the modeling of a JavaBean can be done easily by using class notation in UML. EmailBean.java is modeled in the class diagram of Figure 3. Second, a database and tables of the database are considered. Instead of using the ER modeling on a relational table, a class in UML is used to represent the table. Attributes of the class represent columns. Operations of the class show entity integrity, referential integrity, or other constraints. A database is represented as a package in the class diagram. In Figure 4, the database HICSS package shows the HICSS database, in which there is only one table, Email_Info. Also, Figure 4 shows the directory structures org/gjt/mm/mysql and a class Driver for JDBC. Third, a CSS component is modeled by using a class diagram. A CSS component consists of style rules. Each style rule consists of a rule name and a rule definition. The rule name represents one or more system-defined class i.e. HTML tags or user-defined class names. (The class in CSS does not mean the class in object-oriented concept.) Each rule definition consists of attributes and their values. In Figure 5, we assign each style rule to a class in UML. The class name shows a style rule name. Its attributes consist of the rule definitions. Its operations are always empty. Fourth, a JavaScript component is modeled with a class. The class name of a JavaScript component comes
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
How are the components designed? What packages are used? What classes of which packages are used?
from the logical interpretation of its physical file name. A class for JavaScript may not have any attributes. Only the operations, which are function definitions in the JavaScript component, can be shown. Figure 9 shows a class diagram for a JavaScript Component. Fifth, an XHTML component is modeled in Figure 10. The predefined XHTML tags are defined as classes under xhtml package. The name of the XHTML component is represented as the name of the class. The names of forms or tables are represented as attributes of the class. By making separate components for CSS and JavaScript and saving them into separate packages, the XHTML modeling can be done on only XHTML tags. Sixth, an XML component is modeled in Figure 8. Instead of modeling an XML format directly, the schema definition of the XML format is modeled as Carlson used in [3]. From the given XML schema definition of the XML format for displaying the e-mail list, the type names of elements are used as class names. Seventh, JSP is modeled in Figure 9. Since various language types can be used in implementing a JSP component, a class diagram of a JSP component is generally complicated. A general structure of JSP is modeled in Figure 9. A directive in JSP is considered as a class with only attributes. The action tags are considered as operations in the JSP class. The class name of a JSP component comes from the logical interpretation of its physical file name. Also, many packages for JSP, java, and javax, are employed in the class diagram of a JSP component.
degree of location dependency shows how much the component needs to be located at a predefined directory. The degree of language dependency has more effects on the degree of modeling complexity than the degree of location dependency does since the location dependency does not need specific modeling techniques, except for creating packages and showing their relationships. Table 1. Components and their file extensions
Email_Info_Entry.html Email _Info_Entry.css Email _Info_Entry.js email _info_insertion.jsp email_list_in_xml.jsp EmailList.xsd EmailBean.class EmailBean.java
Degree of Lang. Depend.
Low
Medium
High
Linux Linux Linux Linux Linux Linux Windows
Degree of Loc. Depend.
Degree of Modeling Complexity
Low
0
Medium
1
High
2
Low
3
Medium
4
High
5
Low
6
Medium
7
High
8
Each degree can have low, medium, and high values as shown in Table 2. The values are determined relatively. If a component A uses more languages than another component B for implementation, the degree of language dependency of the component A is relatively higher than one of the component B. If two components use only one language and the language of a component is an object-oriented language, its degree of language dependency is relatively lower to the other component. If
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
Platform s Linux
Table 2. The degree of modeling complexity
6. Discussions on Models The deployment and the implementation models show distinct characteristics of a web application. First, instead of one type of component, many different types of components are deployed. Through the extensions of each component in Table 1, we can guess how many different technologies are used. Second, components are distributed onto different platforms through the network. In this example, the source code of a JavaBean and the XML schema document are developed at a Windows platform. However, their (executable) components are deployed at the Linux platform. In order to compare design models of each component, we propose the degree of modeling complexity. The degree of modeling complexity represents how much the component is complicated for building its design model. The degree is measured by the combination of the degree of language dependency and the degree of location dependency. The degree of language dependency denotes how many different languages are used to implement the component. The
File Extension Definition XHTML Cascading Style Sheet JavaScript Java Server Page Java Server Page XML Schema Document Java Class Java
Components
a component A uses more languages than another component B for implementation, the degree of language dependency of the component A is relatively higher than one of the component B. If the component A’s location needs to be predefined, its degree of location dependency is higher than others. The value of the degree of modeling complexity is determined by the combination of the degree of language dependency and the degree of location dependency. Each degree has a relative value from low, medium, to high. From the two criteria, there are nine combinations. If the combination of two degrees is low and low, the lowest rank 0 is assigned to the degree of modeling complexity. If the combination of two degrees is high and high, the highest rank 8 is assigned to the degree of modeling complexity. Since the modeling of components using objectoriented languages are relatively easier than one of components using non object-oriented languages, the degree of modeling complexity is applied to the two different groups: one uses object-oriented languages. The other one uses non object-oriented language. Table 3. Comparisons of modeling components using non-object oriented languages Languages Used
CSS XHTM L
XML SQL
Style sheet Markup Style sheet Objectbased Markup Schema definition Database
Degree of Lang. Depend.
Degree of Loc. Depend.
Low
Low
High
Medium
modeling XHTML components since XML support hierarchical concepts through a schema definition language and is represented by XML language. However, modeling an XHTML component is complicated since many different languages can be used for a web page implementation. For example, in-line or embedded styles and functions can be implemented by using CSS and JavaScript, respectively. In order to reduce the degree of the language dependency, we can use modular design concepts. Each module uses only one language and can be imported or referenced from the XHTML file. Also, some XHTML components need to be placed at a special place according to web server configuration. Table 4 shows the degree of modeling complexity for components using Java technologies with the values in Table 2. A JavaBean component can be modeled easily compared to a JavaScript component since it uses an object-oriented language Java. JavaBean and JSP components depend on the location of the components since the JSP sever needs to recognize them. Since a JSP component can use different languages, its degree of language dependency is high. Therefore, the modeling of a JSP component is harder than other components. Table 4. Comparisons of modeling components using java technologies
Degree of Modeling Complexit y 0 7
Languages Used Java Script JSP
Medium
Low
3
Low
High
2
Table 3 shows the measurements for components using non-object oriented languages with the values of the degrees of modeling complexity in Table 2. Based upon the degree of modeling complexity, we can say that modeling a CSS component is relatively the easiest one among the four components. Since each rule in a CSS component is described in only one language and its location is not predefined, a CSS component can be easily modeled by using a class diagram. Modeling a component using SQL is relatively easier but harder than the CSS component since the tables are located within a database and the location of database is defined by the given DBMS. Modeling XML is relatively easier than
Java Bean
Degree of Loc. Depend.
Degree of Modeling Complexit y
Medium
Low
3
High
High
7
Low
High
2
7. Conclusions and Future Researches We show how we can model the architecture of a web application using Java and XML related technologies. By applying the RUP to the system, we follow workflows of the RUP. The results of each workflow are represented in a model to show how the architecture of the system looks like. A visual model consists of four different views – use case, logical, component, and deployment views. Each view consists of some of the nine UML diagrams. By incrementally and iteratively integrating the models of workflows into a model, which we call a base model, the whole architecture is represented.
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
Objectbased Objectoriented Markup Style sheet Objectoriented
Degree of Lang. Depend.
Second, we show that we can model components in the web application using non object-oriented languages such as script, markup, style sheet, schema definition, and data languages. By using UML and its customization notation, we can also model components using non object-oriented languages. Third, in order to compare the modeling complexity of components using either object-oriented or non objectoriented languages, we propose the degree of modeling complexity based upon two criteria – degree of language dependency and degree of location dependency Fourth, by using the degree of modeling complexity, we can quantify how relatively difficult it is for us to model which components. Based upon the criteria, it is relatively difficult to model XHTML among components using non object-oriented languages. Among Java related technologies, since JSP has a higher degree of language dependency and a higher degree of location dependency, it is more difficult for us to model the JSP components. The modeling of components using non-objectoriented languages needs more researches. By using more examples of the components, more modeling techniques need to be discussed. Also, by expanding the application of modeling to more web applications, design patterns among the models need to be recovered to understand design ideas for other implementations. The design patterns can be used for reasoning better web application design.
8. References
[1] Brereton, P., Budgen, D., and Hamilton, G. (1998). Hypertext: The Next Maintenance Mountain. IEEE Computer. December 1998. pp. 49-55. [2] Booch, G., Rumbaugh, J., and Jacobson, I. (1999). The Unified Modeling Language User Guide. AddisonWesley, Menlo Park: CA. [3] Carlson, D. (2001). Modeling XML Applications with UML: Practical e-Business Applications. AddisonWesley, Menlo Park: CA. [4] Coleman, D. and et al. (1998). UML: the language of blueprints for software? OOPSLA, 1998. pp. 201-205. [5] Conallen, J. (1999). Modeling Web Application Architectures with UML. The Communications of the ACM. October 1999. Vol. 42. No. 10. pp. 63-70. [6] Fowler, M. (2001). New Methodology. ThoughtWorks, Inc. http://martinfowler.com/articles/newMethodology.html [7] Gornik, D. (2002). UML Data Modeling Profile. Rational Software White Paper. http://www.rational.com/media/whitepapers/tp162.pdf [8] Jacobson, I., Booch, G., and Rumbaugh, J. (1999). The Unified Software Development Process. AddisonWesley, Menlo Park: CA.
Figure 1. Deployment model
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
Figure 2. Implementation model
Figure 3. A class diagram for the EmailBean.java component
Figure 4. A class diagram for the HICSS database and MySQL JDBC
Figure 5. A class diagram for the email_info_entry.css component
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
Figure 6. A class diagram for the email_info_entry.js component
Figure 7. A class diagram for email_info_entry.html component
Figure 8. A class diagram for user_email_info.xsd component
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
(a) A class diagram for JSP
(b) A class diagram for email_info_insertion.jsp component
(c) A class diagram for email_list_in_xml.jsp component Figure 9. Modeling a .jsp component
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
