Saturday, October 08, 2016

DTA'S-Developers Turned Analysts

DTA’s – Developers-Turned-Analysts


I was a developer (by title) for 15 years before I got my first position as an Analyst.  I was warned that being an Analyst meant that I didn't have to program and that I had to change my mindset from the technical side to the business side.  I thought this would be an easy transition, however, it proved to be anything but.  My first Detailed Functional Requirements (DFR) document was full of technical jargon and implementation language.  Another analyst pulled me aside and gave me the same advice I recently had to give a new developer-turned-analyst, heretofore known as DTA's.  The DTA asked me to review his first DFR and to give him some advice. 

The DFR 

To be fair his document was more technical in nature than your typical DFR because it was detailing a process that involved more than one program on more than one platform.  I decided to use the document as a teaching tool for him by also giving him a copy of Ivy Hooks "Writing Good Requirements" article from 1993.  I then tied in the recommendations that I made to him to that document as much as possible. 

Abstracting from Technical to Business Level

When I first started writing requirements I did the same thing, including technical info instead of abstracting to a higher more ‘business’ language level.  The thing to remember is that this document (and all ‘Requirements’ documents) is a ‘contract’ between the business and the developer.  If we put in our ‘contract’ that a developer utilize COBOL (for instance) then the developer’s hands are tied and he must use COBOL.  That is why we tend not to use implementation language in requirements.  This gives the developer the freedom to use whatever he wants (COBOL, Java, etc).

Thinking in terms of Testing

Another thing to keep in mind as an Analyst is that testers will be reviewing our requirements to determine if the program is meeting the ‘terms of the contract’ so to speak.  So the requirements also have to be testable.  When I think about whether a requirement I wrote is testable, I think, ‘Yes or No’.  This means can the result of this requirement results in a ‘Yes, it worked’ or ‘No, it didn’t work’ answer.  Some of the suggestions I made in the document will help drive this home.  I then reworded some of his requirements to make them testable.  For example, he had a requirement that stated: “Set and export a variable called ORACLE_HOME.”  I suggested the following: It might be easier to specify what the value of the variable is, rather than its name.  Also, with this being a requirement, you are telling the programmer that he has to name the variable ‘ORACLE_HOME’.  Remember, requirements are like a contract between the business and the developer.  Ask yourself, what does ‘ORACLE_HOME’ contain?  Then I suggested that he try saying something like “The system shall set the environment name”.

The advice was well-received and my manager asked that I save it to our team drive for other new analysts to refer to.  Transitioning from Developer to Analyst can be difficult.  It is not just giving up the coding part of your job, it is having to think at a less technical level and still conveying your message, not always an easy job.

Saturday, September 24, 2016

Struts Overview

Struts Overview


This will be the first in a series of articles about the way that Struts is used and the use of open-source components.

Framework Overview (Theoretical)

Struts is a development framework that simplifies some of the more challenging aspects of Java web development. Struts is based on the Model-View-Controller pattern.

  • The Model represents the data model and business logic
  • The View is the interface (UI)
  • The controller acts as a director controlling the flow

Struts is a Free Framework based on the collaboration of a community of developers. They abstracted common characteristics that exist in all web applications, but lead with the controller.

  • Controller
  • Actions-Model
  • View-Result/Presentation

What you need

To use Struts, you need the following jar files:

·         struts-core-1.3.10.jar

·         struts-taglib-1.3.10.jar

Getting it to work with Struts

A traditional Struts application used in my experience has the basic three elements; the Form Bean, the Action and the Java Server Page or JSP.  Their interaction is orchestrated by the Struts-config.xml.  Let’s see an example.

The Players


The super-simple “Start Here” part of our application will do the following:

1.   Display greeting

2.   Display a list of links to other sample applications

To accomplish this we will need the following:



·         Step1.jsp

They reside here:

This simple java bean is the setter and getter for our greeting.

This java program passes the greeting to and returns “success” to Struts to let it know where to go next.


Displays our greeting and a list of links.


SSA’s use of Struts-Config.xml relies on the use of wildcards in their action mappings.  The following example explains how it is used.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE struts-config PUBLIC
     "-//Apache Software Foundation//DTD Struts Configuration 1.3//EN"
  <!-- ========== Form Beans Definitions ========================== -->
  <!—- The form bean definition is required so that Struts can know -->
  <!—- where to get the information. -->
    <form-bean name="StartHereForm" type="forms.StartHereForm" />
  <!-- ========== Global Exceptions Definitions =================== -->
  <!-- ========== Global Forwards Definitions ===================== -->
    <!-- These "forwards" direct STRUTS to perform the actions associated with these URL's.
    For example, when someone has http://localserver/thisApp/, it triggers
    the launch of and, if the Action returns “success”, it will display
    <forward name="StartHere" path="./" /><!-- Maps to /StartHere action -->
  <!-- ========== Action Mapping Definitions ====================== -->
  <!-- The /StartHere in the path attribute allows the mapping to match the request.       
  <!-- As redirected from the "StartHere" forward (above). This will show our Main Menu. -->
      <forward name="success" path= "./WEB-INF/StartHere/Step1.jsp" />
  <controller nocache="true" /> 

In short it is kind of like saying to Struts:

When someone types in, find the matching action. When you find the action, use the form bean that will have the information we will need to process this request. Once you have it use the java program labeled as type to perform the functionality on that bean. When you are done, if the application returns the word “success”, display the jsp associated with “success”.

All of that in one little xml doc…cool.

And here is the code

Has getters and setters for the greeting.

package forms;
import com.organization.ocelot.forms.BaseForm;
public class StartHereForm extends BaseForm {
    private static final long serialVersionUID = -6688708519508889724L;
    private String GREETING;
      public String getGREETING() {
            return GREETING;
      public void setGREETING(String greeting) {
            GREETING = greeting;

…and it gets the greeting from

package actions;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
import forms.StartHereForm;
import com.organization.common.environmentManager.EnvironmentException;
import com.organization.common.environmentManager.EnvironmentManager;
import com.organization.common.environmentManager.IEnvironmentHandler;
import com.organization.common.propertyManager.IPropertyHandler;
import com.organization.common.propertyManager.PropertyException;
import com.organization.common.propertyManager.PropertyManager;
public class StartHereAction extends GSOBaseAction {
    private static final long serialVersionUID = 1L;
    public static HttpServletRequest req;
    public static HttpServletResponse res;
    //This section is merely our property handler and environment handler settings.
    //ideally, they will not be in individual pages, but this is strictly for
    //use as an example.
    static {
        IPropertyHandler pm = null;
        try {
           IEnvironmentHandler env = EnvironmentManager.getEnvironmentHandler();
           String envProp = env.getEnvironmentPrefix();
           pm = PropertyManager.getPropertyHandler();
        catch (PropertyException propEx) {
           String msg = "Unable to get Property Manager";
           System.out.println(msg + " for " + pm);
        }catch (EnvironmentException envEx) {
            String msg = "Unable to get Environment Manager";
            System.out.println(msg + ":" + envEx);              
     // This is our code the system.out stuff is just for reference in case you want  
     // to see what is happening.
      public ActionForward execute(ActionMapping mapping, ActionForm form,
                  HttpServletRequest request, HttpServletResponse response) {
            System.out.println("ActionMapping is: " + mapping);
            System.out.println("ActionForm is: " + form);
            System.out.println("HttpServletRequest is: " + request);
            System.out.println("HttpServletResponse is: " + response);
            //create an instance of the form
            StartHereForm shf = (StartHereForm) form;
            System.out.println("ActionForm is: " + shf);
            //Send it the greeting
            shf.setGREETING("Getting Started with Ocelot");
            //Pass control back to the Struts-config.xml which should run the jsp
            // associated with "success"
            return mapping.findForward("success");


Will display our greeting…

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
    <%@ taglib uri="" prefix="bean"%>
    <%@ taglib uri="" prefix="s" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "">
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Step 1</title>
<!—- This code is used to pull the value “GREETING” from our StartHereForm form.-->
<h1><bean:write name="StartHereForm" property="GREETING"/></h1>
<s:link action="">Available Hours</s:link>
            <div><font size="3">The Available Hours component provides functionality
            for an application to specify available hours and generates warnings
            if a session is started close to the cut-off times.</font></div>
<s:link action="">User Experience Framework</s:link>
            <td>Helps make fancy-shmancy looking SSA web pages. This example also includes examples of <b>Navigator</b> and <b>Struts
<s:link action="">Data Propagation</s:link>
            <td>Helps communication between applications using keys and cookies...all very cool</td>

I have created an index.jsp page that immediately redirect to, which you will recall triggers the StartHere action.

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
<%@ taglib uri="" prefix="logic" %>
<logic:redirect forward="StartHere"/>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "">
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Welcome 2 Ocelot</title>
Welcome 2 Ocelot (Struts 1)!

So when we run the program:

I hope this gives you a good understanding of how Struts is used and how beneficial it is in building flexible, un-tightly coupled web applications.