Requirements Reuse by Aspect Weaving in Storyboards

Create a storyboard library with a J-CASE Tag Library

Apr. 9, 2009 01:30 PM

I wrote in my previous article, "Interactive Storyboarding with JSP," that interactive storyboarding is an effective way to define better requirements by eliciting actual business user needs. And I proposed to describe the requirements inJSPs with the J-CASE tag library, which enables business to experience conceptual pages to get a better understanding of the proposed system. As a next step, this article proposes to create a storyboard library that can be reused among projects. This article also shows that aspect weaving makes customization of the library easier to describe application-specific requirements.

Storyboarding with J-CASE
Before discussing requirements reuse, I will briefly explain how J-CASE creates storyboards.

It's very hard for business users and engineers to clearly recognize all the requirements early on. Even if we carefully define use cases, we often find something missing or wrong when we access the system that was developed. Since XP (Extreme Programming) encourages short iteration cycles and frequent releases, we need to show business the actual system earlier to get proper feedback. If we just want feedback, it would be enough to create conceptual screens and flows on storyboards rather than implementing the actual logic.

J-CASE provides JSP custom tags to define the conceptual screens and interactions happening between the user and the system. And by accessing the JSP pages, business can see how the screen looks and what happens on each screen. Figure 1 shows a sample screen in a Search Keyword use case that displays a search form and possible actions on the screen.

In this sample, two actions are defined. The "Search" action represents the main flow in which the user enters a keyword and submits a form. The second action, "Empty keyword," represents an alternative course, entering an invalid value. Below is part of the JSP code to generate the page

<c:screen id="screen_searchForm" align="center">
Keyword <input size="30"/> 
<input type="submit" value="Search"/>
</c:screen>
 
<c:actions>
<c:action id="action_search" name="Search"
link="SearchResults.jsp">
The user enters a keyword and submits it.
</c:action>
<c:action id="action_empty" name="Empty keyword">
The user submits the form with empty keyword. 
The system displays an error message.
</c:action>
</c:actions>

The c:screen is the tag to define the conceptual screen of the search form using HTML tags. C:actions and c:action are the tags that define the actions, Search, and Empty keyword. When you access the JSP, you'll see the page shown in Figure 1, and you can see the next screen, the search results page, when you click on the Search link.

Requirements Reuse
By reusing the existing requirements, you can expect to improve the quality and productivity of your requirements because they've already been tested and refined in other projects. However, most of the reused asset in software development today is "code" using components and frameworks. Requirements aren't commonly reused because they are written in a natural language and are difficult to reuse. So, description in a formal language is one solution, but this article takes another approach that allows describing requirements in natural language using HTML and J-CASE tags, because natural language is an intuitive way to share ideas and needs on requirements with business.

The basic concept of requirements reuse by J-CASE is the same as code reuse, which compiles and makes a distributable file. Since J-CASE means describing requirements in JSPs, each JSP can be compiled into a servlet class just like a regular Java application. J-CASE also provides a tool to generate servlet code that doesn't depend on a specific servlet container to be able to run on any servlet containers. By pre-compiling and making a jar file, you can easily distribute your storyboards and share the requirements with other projects.

Aspect Weaving
Making a distributable file is only half-way to requirements reuse. It should also be easy to customize based on application-specific requirements. Otherwise, no one would want to reuse it, because requirements are commonly unique to each project. Even if the logic behind the UI is completely the same, we can see many differences on storyboards. For example, a "Log In" use case typically uses "User ID" for the user ID field, but some projects may want to say "Email Address."

To express such a variety of requirements for higher reusability, I propose to use aspect weaving, which inserts another tag representing the application-specific requirements into the parent tag. J-CASE and HTML tags in the JSP are marked as joint points to enable to weave an aspect when you generate the servlet code from the JSPs. The following aspect types are available in J-CASE (see Table 1).

J-CASE also enhances the JSP syntax of the page directive to enable it to inherit from an existing JSP, providing "extends" and "urlPattern" attributes.

<%@ page
[ extends= { "JSP path" | "package.class" } ]
[ urlPattern="URL pattern" ]
%>

The "extends" is already defined in a JSP syntax, but J-CASE also uses it to specify a path for a parent JSP file as well as servlet class. The urlPattern is used to map the specified URL to the JSP. When you inherit a JSP, you may want to use the parent URL to access the new JSP because other existing pages point to the parent JSP. By specifying the urlPattern, you don't have to modify other pages to let them access the inherited JSP instead of the parent JSP, as shown in Figure 2.

J-CASE also allows you to describe the following attributes in J-CASE and HTML tags to specify where and how to insert the aspect (see Table 2).

Go back to Figure 1 for a moment. Let's say that business made a request to add a help link on the search form. To save your work, J-CASE provides a feature to inherit from the existing page, so you just need to define the additional requirements, as shown below:

<%@ page extends="jcase.jsp.SearchForm_jsp"
urlPattern="/SearchForm.jsp" %>

Help

<c:action parentId="action_search" advice="after"
name="Display help" link="SearchHelp.jsp">
The user selects the help link to see search instructions. 
</c:action>

This JSP has three parts: the page directive, P tag, and c:action tag. The "extends" attribute of the page directive represents the JSP inherited from the SearchForm_jsp class, which is the servlet class compiled from the SearchForm.jsp. And J-CASE maps this JSP to the URL, /SearchForm.jsp, specified in the urlPattern attribute. So you'll see the customized page shown in Figure 3 instead of the parent JSP when accessing the SearchForm.jsp in your browser.

The P tag where the Help link is described is the aspect to be inserted at the inside top of the search form screen and to do so the screen ID is specified in parentId and top advice is specified. The c:action inserts the additional action for the Help link in the action table in the parent JSP.

Sample Customization
To see more closely how aspect weaving works in storyboards, let's look at the following sample code, TestA.jsp:

<%-- TestA.jsp --%>
<html><body>
News
Video
</body></html>

This JSP displays two texts with an underline, which represents a hyperlink for the service, as shown in Figure 4 - TestA.jsp.

Let's say we got a request to add a new service called Mail and that the business wants to insert a new link for the service between News and Video. To reuse the requirements defined in the TestA.jsp, create a JSP child. Then insert a U tag that represents the Mail link, using the advice shown in the TestB.jsp below:

<%-- TestB.jsp --%>
<%@ page extends="/TestA.jsp" urlPattern="/TestA.jsp" %>
Mail

Now, you'll see the three links: "News," "Mail," and "Video" when accessing the page.

After that, if you get another request from business, say, to display the links with emphasized text using a STRONG tag, weave another aspect against the TestB.jsp, as shown below:

<%-- TestC.jsp --%>
<%@ page extends="/TestB.jsp" urlPattern="/TestA.jsp" %>
<c:parent/>

In the parentId of the STRONG tag, a regular expression that matches IDs ending with "_service" is specified. In this sample, since the three links defined in Test A and B are matched, the around advice is applied for all the links. When you access the page, you'll see the three emphasized links, as shown in Figure 4 - TestC.jsp.

Customize Without Aspect Weaving
As you can see the sample code in TestA.jsp, where we described the original requirements, we don't have to think what customizations will be required down the road. This is one of most beneficial features of aspect weaving. Without the aspect technique, you have to code your application-specific requirements in TestA.jsp. For example, you may add a c:if tag for inserting the Mail link, as shown below:

News
<c:if test="${enableMail}">
Mail
</c:if>
Video

However, this code tells us that we have to predict if someone wants to display the Mail link between News and Video. What if someone else wants to display it after Video? What if someone else wants to delete News? There are too many future possibilities; we can't predict all of them beforehand. With this approach, the customization variations would be limited.

Weave an Aspect into Multiple JSPs
So far the aspects in the sample code were woven into a specific JSP (using JSP inheritance), but of course, J-CASE lets you weave aspects into multiple JSPs like AOP languages. The code below is a sample JSP that weaves footer content into all JSPs.

The c:tag itself doesn't do anything. It's usually used to group multiple tags and texts. The parentClass is a key attribute in this sample so you can describe cross-cutting requirements in one place. Since the value ".*" that matches any classes is specified, this aspect is tested against all JSPs and servlet classes. Then the parentId "^html_body_tag_.*" and aspect attributes represent the weaves at the bottom of the each page. So when you execute the storyboards, you'll see footers on all pages.

Separation of Requirements
The samples in this article also show that we can separate application-specific requirements from common ones. Look at TestB.jsp again; it only defines the additional requirement of a Mail link in the TestA page that business wants to add. This means that we can manage application-specific requirements in a separate library.

For example, imagine company B, which uses an authentication component (auth-lib), such as login, forgot password, register user use cases, provided by company A, as shown in Figure 5.

Company B has some web application projects that require authentication to see the protected pages. So it establishes a SSO project to provide a single sign-on solution and develops a SSO component (sso-lib) based on the authentication component of company A for the existing applications.

In this scenario, company A and B can create their own storyboard libraries and share requirements. The SSO project can reuse the authentication use cases defined in auth-lib.jar and focus on defining SSO-specific requirements. Likewise, the application teams at company B can reuse SSO use cases defined in sso-lib.jar. Even if company A or SSO projects find errors in their storyboards, they just need to correct and provide the jar file for the client companies or projects. The application projects will see the corrections and replace them with a new jar. They don't have to modify or recompile their JSPs. This is the same approach as code reuse.

Conclusion
J-CASE is a JSP tag library that lets us create interactive storyboards for gaining a clear understanding of the proposed requirements. To refine requirements, this article proposes using the following features in J-CASE:

Create a distributable storyboard library that is servlet container-neutral.
Enable customizing the library using Aspect weaving.

In this article, we saw that the aspect technique lets us focus on very generic requirements that can be woven later in each application project without considering application-specific requirements. It also helps us manage the application-specific requirements separated from common ones.

J-CASE provides us higher reusability in defining requirements like code reuse. I expect J-CASE to encourage you to reuse more requirements and helps you define your requirements better.

Resources

About Masayuki Otoshi
Masayuki Otoshi develops Web applications for a manufacturing company as a senior developer.