Featured Post

The great debacle of healthcare.gov

This is the first time in history when the president of the United States of America, or probably for any head of state around the world,...

Monday, October 29, 2007

Handle session time out issue in the Ajax application

If you invoke any serverside program in an Ajax call it doesn't refresh the entire page with the resoponse. So in the webapplication using ajax call needs special treatment to track the session time out and refresh the entire page to forward to login page.

Following is one special scenerio where an j2ee application using Struts framework implements the session time out issue.

1. Check if the session is valid for the user

2. If the session is timed-out, return to a particular action mapping forward (e.g. 'session-time-out')

if(session.isNew()) {
return mapping.findForward("session-time-out");
}


3. In the struts-config.xml, forward the session-time-out to a special jsp page (e.g. ajaxSessionTimeOut.jsp) which will contain a particular value that represents the session time out

<action>
<forward="session-time-out" path="/ajaxSessionTimeOut.jsp"/>
</action<

4. In the call back object/method of the ajax call, parse the value from the responseXML. If the parsed value is the value set in the forwarded page (i.e. ajaxSesssionTimeOut.jsp), set the action of the form to the login.do (the action mapping for the login in the application) and submit it

document.forms[0].action="/login.do";
document.forms[0].submit();


The similar technique, shown above, can be used in any other web applicatoin.

Sunday, October 28, 2007

Software Project Management

I had attended a 2 days workshop on ‘software project management’. This workshop was designed to be interactive with the participants. I learned different aspects of the project management in that two-days workshop. Here I'm going to share the highlights of that workshop.

At the very beginning of the workshop we, the participant, were divided into three groups. In each of the group there was a Designer and a Finance Manager. I was playing the role of the Designer. Three designers were then isolated from the groups and given a requirement to design a tallest tower that would have to stand in the natural calamities even in the tsunami. Then we, the designer, were advised to keep the requirements secret and send back to the teams with an art (hard) paper sheet and scotch tap to build the design and the tallest tower. So we got a hard paper sheet, scotch tap and 8 (eight) minutes in our hands. After 8 minutes trainer the found the following things:

Group One: They came up with the paper, divided into six pieces, and the given scotch tape but those pieces of paper didn’t joined together to be a tower at all.
Lesson: They designed it in such a way that might be good but unrealistic compare with the resource limitations (time and cost).

Group Two: We have built the tower in rounded shape with a strong base. We put the tower on the table. The trainer tested it with strong blow and it felt down. I was in this group.
Lesson: We have developed the tower in portable design that can be put on any place but it was not the requirement to be portable and didn’t test it much. We exceeded the client requirements (by providing the portability) but failed to fulfill the basic requirements.

Group Three: They also built the tower in rounded shape and used scotch tap to attach it with the table top. The trainer tested it with the strong blow and it passed.
Lesson: They have built exactly what the client asked for.

According to the Standish Group, world’s renowned software project research group, 12% of the total software projects were successful and 37% software projects failed in the year of 1994. But it has changed dramatically in the year of 2004, 36% of total software projects were successful and only 13% software projects failed. Here successful project indicates the completion of the project on time and on budget.

The workshop was mainly following the official certification program of the Project Management Professional (PMP) by the Project Management Institute (PMI). The trainer himself is the certified Project Manager from the PMI. The workshop contains the following course structures:
  1. Introduction to Project Management
  2. Project Integration Management
  3. Project Scope Management
  4. Project Time Management
  5. Software Estimation
  6. Project Cost Management
  7. Project Human Resources Management
  8. Project Risk Management
  9. Project Quality Management
  10. Project Procurement Management
  11. Project Communication Management
Here is the brief description of the key features on the above topics:

Introduction to Project Management
Project Management is the applications of knowledge, skills, tools and techniques to project activities in order to meet or exceed stakeholders’ expectations. Project can be defined as the temporarily organized set of operations to create a Unique Product or Service within the constraint of Time, Resources (budget) and scope that have a definite start and end times. Projects are progressively elaborated.
Project Management Process comprises the following processes
  1. Functional Process
    1. Core Processes
    2. Facilitating Project execution and Plans with changes requests
  2. Process Groups
    1. Initiating
    2. Planning
    3. Executing
    4. Monitoring & Controlling
    5. Closing
In the project management processes 3 Major Documents are to be developed:

Project Charter: Formally authorizes the project
Project Scope Management: States what work needs to be accomplished and what deliverables need to be produced
Project Management Plan: States how the work will be performed. Composed of the plans and documents generated by the various processes. These are the subsidiary plans


Project Integration Management

In the Project Integration Management the main focus lies on the Project Selection Methods. Project Selection Methods are:
1. Constrained Optimization Methods
2. Benefit Measurement Methods
a. Cost/Benefit Analysis
b. (Weighted) Scoring Model
c. Payback Period
d. Discounted Cash Flows
3. Net Present Value (NPV)
4. Internal Rate of Return (IRR)
In this process the Project Charter, Preliminary Project Scope Statement, Project Management Plan is developed. Integrated Change Control is also one of the concern of this process

Project Scope Management

Includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. The key focuses of the project scope management are Work Breakdown Structure (WBS), Responsibility Assignment Matrix aka RACI chart and SMART way of defining goal.
A project goal must be Specific, Measurable, Achievable, Realistic and Time-based (SMART).
WBS is a very important tool that defines the work of the project in a deliverables-oriented hierarchy. Accuracy and completeness are critical while developing the WBS.
Responsible, Approval, Consulted and Informed are the four keywords used in the RACI chart that is used to draw the responsibility assignment matrix to the project members

Project Time Management

Project Time Management includes the processes required to accomplish timely completion of the project. It comprises the following functions:
-Activity Definition
-Activity Sequencing
-Activity Resource Estimating
-Activity Duration Estimating
-Schedule Development
-Schedule Control








I have also learnt the Forward Pass, Backward Pass, What-If Analysis –Monte Carlo Approach, Critical Chain Technique, Gantt Chart in this chapter.

Software Estimation

Estimation comprises three phases:
-Size: Size estimate is a measure of the size of the final work product
-Effort: Effort estimate is the effort in person months/person days required to produce the work product
-Schedule: Schedule Estimate is the calendar time it would take to accomplish the effort.
The techniques that the workshop went through are Functional Point Analysis (FPA), Line of Code (LOC) estimation, COCOMO and Delphi’s Wideband Technique.
Function Pint Analysis is a standard method for measuring the size of a software development or software enhancement project for business application software based on the customer’s point of view. Function Point is a measure that describes a unit of work product suitable for measuring the size of a business application software. It is independent of the computer language, development methodology, technology or capability of the project team.
LOC is a technical measure as it measures the software from the developer’s point of view - not from the user’s point of view.
Delphi’s Wideband Technique basis are:
• When many experts independently come to the same estimate based on the same assumptions, the estimate is likely to be correct
• We need to make sure that experts are working on the same and correct assumptions
• Also find this technique in Risk Management tools and techniques.
Here are the best practices for the estimation techniques are:
• Avoid off-the-cuff estimates
• Allow time for the estimate and plan it
• Use data from the past projects
• Use developer based estimates
• Estimate by walkthrough
• Estimate at low level of detail
• Don’t omit common tasks
• Use tools, models for estimation
• Use at least two techniques, and compare the results.

Project Cost Management
Project Cost Management includes the processes involved in planning, estimating, budgeting and controlling costs so that the project can be completed within the approved budget. The key focuses of the cost management processes are
• Cost Estimating
• Cost Budgeting and
• Cost Controlling.

Earned Value Management (EVM) is one of the key performance evaluation analysis techniques that are widely used in the cost management process. It has three major components:
Planned Value (PV) is the budgeted costs of the work scheduled. It only changed when baseline is changed. Cost baseline is a time-phased budget that is used to measure and monitor cost performance on a project. Actual Costs (AC) is the actual cost of the work performed. It is based on the actual completion of work packages. Earned Value (EV) is the budgeted costs of the work performed. It is also based on actual completion of work packages. When EV is higher than AC, it is a good indicator of the project cost and vice versa.

Human Resources Management

Project Human Resources Management (HRM) includes the processes that organize and manage the project team. Proper HRM can turn a group of individuals into a team. The key focuses of the project HRM are
• Human Resource Planning
• Acquire Project Team
• Develop Project Team and
• Manage Project Team

Develop a project team to improve skills of team members in order to increase their ability to complete project activities and to improve feelings of trust and cohesiveness among team members in order to raise productivity through greater team work.
Attributes of effective project teams:
• Clear goals and objectives
• Cohesiveness
• Understanding of Interdependence
• Potency and
• Trust
It also includes the techniques to analyze performance, different types of motivation model (e.g. Hawthrone Effect, Herzberg’s Motivators and Hygiene factors, Maslow’s Hierarchy of Needs etc.) and conflict management

Project Risk Management

The objectives of Project Risk Management is to increase the probability and impact of positive impact and decrease the probability and impact of events adverse to the project
Risk Management consists of the following processes:
• Risk Management Planning
• Risk Identification
• Qualitative Risk Analysis
• Quantitative Risk Analysis
• Risk Response Planning and
• Risk Monitoring and Control

In the Risk Identification different information gathering techniques were demonstrated that includes Brainstorming, Delphi Wideband technique, Nominal group technique, SWOT analysis and Ishi-Kawa/Fish-Bone diagram. In the Risk Analysis process the Probability Impact Matrix, Sensitivity Analysis/Tornado Diagram, Expected Monetary Value (EMV) and Decision Tree Analysis were discussed.
When we need to response to risks there are several strategies. Those are:
• Strategies for negative risks
o Risk avoidance
o Risk transference
o Risk mitigation
• Strategies for positive risks
o Exploit
o Share
o Enhance
• Strategy for both threats and opportunities
o Risk acceptance
o Contingent response strategy

Project Quality Management

Project Quality Management processes include all the activities of the performing organization that determine quality policies, procedures and processes of quality planning, quality assurance and quality control, with continuous process improvement activities conducted throughout, as appropriate.
Performing Quality Assurance is the application of the panned, systematic quality activities to ensure that the project employs all processes needed to meet requirements but performing Quality controlling is involves the monitoring of specific project results to determine whether they comply with relevant quality standards and identifying ways to eliminate causes of unsatisfactory performance. Quality Controlling may uses the following tools and techniques: Inspection, Control Charts, Pareto diagrams, Statistical sampling, Trent analysis, Flow-charting etc.

Total Quality Management (TQM) is a common approach to implementing a quality improvement program within an organization.

Project Procurement Management

Project Procurement Management includes the processes to purchase or acquire the products, services or results needed from outside the project team to perform the work.
Key focuses of this management process are:
• Plan Purchase and Acquisitions
• Plan Contracting
• Request Seller Responses
• Select Sellers
• Contract Administration
• Contract Closure

Project Communication Management

Includes the processes required to ensure timely and appropriate generation, collection, dissemination, storage, and ultimate disposition of the project. The following communication management aspects were discussed in the workshop:
Outputs of Information Distribution comprise:
-Project Records
o Memos, correspondence, etc.
-Project Reports
o Includes status reports, minutes of meeting, etc.
-Project Presentations
o Presentations to stakeholders and other relevant parties
o Format and informal

A team meeting needs to have the following attributes:
- Goal Oriented
- Right people
- Expectation clarified
- Agenda in advance
- Time sensitivity and in this way a team meeting needs to be GREAT.

Finally, in a software company the primary assets are the processes that it develops and practices. The software project management tries to give us a picture so that we can develop and effectively practice the software standard processes that will enable us to efficiently manage a software project to complete it on time on budget.

    Java 5: Tiger @ a glance

    New Features of Java 5, the Tiger
    The code name Tiger for the Java 1.5 which is officially recognized as Java 5, comes with lot of new features. Those features enrich the capability of Java and also overcome some limitations of faster programming. There are some features those also changed some core beliefs of Java such as Compile time error handling rather Runtime surprising.

    Note: This gist is mostly taken from Java 1.5 Tiger: A Developers Notebook from Oreilly

    Generics
    This is the feature that existed long before in the C++ language, known as Template. This feature provides Java the capability to tag a Collection to a specific Object types so that the Collection can only handle the tagged Object type. The main benefits to the programmer are the type safe Collection and avoiding unnecessary type casting.

    Type safe Collection

    Generic let you to trust the Collection contains a specific type by limiting the type that a particular Collection will accept. You don’t need to cast to the specific object again.

    List example:

    List myList = new LinkedList();
    String str = myList.iterator().next();

    Map example:

    HashMap myMap = new HashMap();


    Limitation: There is a limitation in the Generic Type Safety. This can be broken by using reflection.


    Writing Generic types
    You can write your own Generic type Collection.

    Public class Box
    {
    private List list;

    public Box()
    {
    this.list = new ArrayList();
    }
    // Other methods implementation….
    }
    Miscellaneous

    Arrays

    Tiger has provided some very useful static method for this type of objects. Those are:
    deepToString():This method takes an Array object and prints out it’s contents
    deepEquals(): provided to compare multidimensional arrays.

    Queues

    Two cool methods have been provided: offer() and poll() methods are best alternatives add() and remove() methods respectively. The later method throws exception when the Queue is full (for add()) or it is empty (for remove()) but the former method pair returns false and null respectively.

    PriorityQueue collection has been given as an alternative to FIFO. This Queue uses a Comparator object to filter; otherwise it works just like a Queue.

    The following code is used to print lowest to highest for even and odd numbers.

    PriorityQueue pq = new PriorityQueue (20, new Comparator( )
    {
    public int compare(Integer i, Integer j)
    {
    int result = i%2 - j%2;
    if (result == 0)
    result = i-j;
    return result;
    }
    }
    );

    for (int i=0; i<20; i="0;" string=""> antMessages = new EnumMap(AntStatus.class);

    antMessages.put(AntStatus.INITIALIZING, “Initializing Ant…..);
    ………
    String theMsg = antMessage.get(AntStatus.INITIALIZING)

    EnumSet has similar uses. See EnumSet JavaDoc API for details

    Adding Methods in Enum
    You can add methods in an enum just like any other class.

    Public enum GuiterFeatures{
    ROSEWOOD(0),
    MAHOGONY(4),
    ZIRICOTE(3)
    …..


    private float upCharge;

    private GuiterFeatures(float upCharge)
    {
    this.upCharge = upCharge;
    }

    public String getDescription()
    {
    switch(this){
    case ROSEWOOD: return “Rosewood back and side”;
    ….
    …..
    }

    }
    }

    Manipulating Enum
    Autoboxing and Unboxing
    Convertion of Primitives and Wrappers
    You can now create any Wrapper class (Integer, Float, Double etc.) without concerning the manual conversion of primitives to wrapper object. Both of the following statements are true:

    Integer value = new Integer (10)
    Integer newValue = 10;

    It is also hassle free to convert the object to primitive type:

    int primValue = newValue;

    Method overload resolution
    Method overloading seems bit confusing in the new Java environment due to the auto boxing and unboxing features. Which overloaded method should be invoked when convert (10) is called if the overloaded method signatures are like follow:

    Public int convert(Integer value)
    Public int convert(int value);

    Tiger has three-pass process to resolve the issue:
    i. The compiler attempts to locate the correct method without any boxing, unboxing, or vararg invocations. This will find any method that would have been invoked under Java 1.4 rules.
    ii. If the first pass fails, the compiler tries method resolution again, this time allowing boxing and unboxing conventions. Methods with varargs are not considered in this pass.
    iii. If the second pass fails, the compiler tries method resolution one last time, allowing boxing and unboxing, and also considers varargs methods.
    Varargs
    This relatively simple feature aides you to write simple, cleaner and more flexible code

    Creating and iterating

    Public void addInstrument(String id, String version, String… features)
    {
    this.id = id;
    this.version = version;
    // here features is the String[] type. You can also convert varargs to List using Arrays.asList(..)
    this.features = features
    }

    The above method signature accepts variable length of features for the instrument. Those three dots (…) are the syntax of declaring varargs. The following code shows hot it is called:

    addInstrument(“1”, “2.2”, “Cool GUI”, “Slow refresh”, “medium startup time”);
    addInstrument(“1”, “2.2”, “Cool GUI”, “Slow refresh”);
    addInstrument(“1”, “2.2”, “Cool GUI”);

    All the above method call will hit the previously declared method with varargas. Great!

    Avoiding automatic Array conversion
    Loop
    The loop has gone through a dramatic change in the new release. It is more easy to code now to iterate through collection and string. The new syntax is:

    for (declaration : expression)
    statement

    Example for collection:

    For( Object obj : myList)
    {
    System.out.println((String)obj);
    }

    Advantages of new loop:
    i. You can ditch the usage of Iterator as it is done by the Compiler during byte code conversion

    Compiler convert the for loop in the following fashion for an collection (in the expression)

    for ( Iterator #i = (expression).iterator( ); #i.hasNext( ); )
    {
    declaration = #i.next( );
    statement
    }

    ii. Unnecessary type casting can be avoided by directly using the reference

    List wordList = new ArrayList();
    for(String word : wordlist)
    {
    System.out.print(word + " ");
    }


    Apart from above, the new for loop structure (foreach) reduces code in the control structure (you don't need to assign new variable to count and loop through and also another line of code to retrieve the object from the collection 

    There are some further points about the syntax of the for/in loop that you should be aware of:
    1. Expression must be either an array or an object that implements the java.lang.Iterable interface. The compiler must be able to ensure this at compile-time—so you can't use a List cast to Object, for example, and expect things to behave.

    2. The type of the array or Iterable elements must be assignmentcompatible with the type of the variable declared in the declaration . If the assignment won't work, you're going to get errors.

    3. The declaration usually consists of just a type and a variable name, but it may include a final modifier and any appropriate annotations (see Chapter 6 on Annotations). Using final prevents the loop variable from taking on any value other than the array or collection element the loop assigns. It also emphasizes the fact that the array or collection cannot be altered through the loop variable.

    4. The loop variable of the for/in loop must be declared as part of the loop, with both a type and a variable name. You cannot use a variable declared outside the loop as you can with the for loop.

    Import
    Static import
    Now on you can use the static method name without showing its Class name in every instance through the use of static import.

    import static java.lang.System.out;
    import static java.util.Math.*;

    These following codes are valid now in the class:

    out.println(“Whatsoever”);

    double x = sqrt(y * PI)

    You can even use the same name in the static import.
    Importing multiple members with the same name

    Annotations
    Standard annotation types
    There are three standard annotation types:
    i. Deprecated
    ii. Override
    iii. SuppressWarning
    There are three categories of annotation:
    i. Marker annotation
    ii. Single-value annotation
    iii. Full annotation
    You can create your own annotations by using the @interface. The ‘@’ symbol is used to indicate the Interface class to Annotation class.

    Yet to cover

    Threading
    Handling uncaught exception
    Using Thread safe Collection
    Queues blocking
    Separating Thread logic from execution logic
    Using callable objects
    Executing tasks without and ExecutorService
    Scheduling Tasks
    Advance Synchronization

    HTTPS configuration in JBoss/Tomcat

    1. Create the Keystore using keytool. It creates the private key and public key.
    2. copy the private key. Get the security certificates from the commercial SSL certificate provider (like Verisign Inc.).
    3. Import the certificates provided by the commercial vendors. Follow the sequence while importing. The sequence is - import the site specific certificate, domain specific certificate and root certificate. WHILE IMPORTING ROOT CERTIFICATE use the option to override the public key that was generated while creating the keystore. Otherwise it won't work. We had hardtime with this problem and almost 3/4 days wasted

    -------------Sample Certification from Verisign------------
    MIIBqzCCARQCAQAwbDELMAkGA1UEBhMCdXMxFjAUBgNVBAgTDW1hc3NhY2h1c2V0d
    HMxDzANBgNVBAcTBmJvc3RvbjEUMBIGA1UEChMLc3RhdGVzdHJlZXQxDjAMBgNVBAs
    TBWJhc2VsMQ4wDAYDVQQDEwVtYXN1ZDCBnjANBgkqhkiG9w0BAQEFAAOBjAAwgYgCg
    YBRbqxofvLkEFjrUSy0Z56+ZIIQIuHD84rhD0uGHN0FrM8B0Ssl8okN8eQIYf+5/tQrfZDZ+
    q86ZDA5YcvNc1QnGMboKAIt8WKZnSAmrUxNZ9AJ+CblmN575ygOpHjygY9o8RLYbJmPOl
    VZMaDano9rQwjyp8G3jnW4Fn6T5+Qm1QIDAQABoAAwDQYJKoZIhvcNAQEEBQADgYEAS
    B0buuQp9IG4Cg+05S/YOD30YC0NXO3gzZED0Z8ik5js/TGt9LlYQtiPG9Gki9IjBhLEmYtJaz
    26qXrbqXBYqx5eG/ItLp+TFRdC4qAuVOiaGzHDx0eqEx7w5OOt6EkVHVhfKK3YYqevTY3ll
    4WyL0F6ASaTLrem/0F75Zwqx4o=
    -----END NEW CERTIFICATE REQUEST-----

    keytool -import -alias intermediateCA -keystore test.keystore -trustcacerts -file intermediateCA.cer

    Enter keystore password: foobar

    Owner: CN=VeriSign Trial Secure Server Test CA,
    OU=Terms of use at https://www.v/erisign.com/cps/testca (c)05,
    OU="For Test Purposes Only. No assurances.",
    O="VeriSign, Inc.",
    C=USIssuer: CN=VeriSign Trial Secure Server Test Root CA, OU="For Test Purposes Only. No assurances.", O="VeriSign, Inc.",
    C=USSerial number: 63b1a5cdc59f78801da0636cf975467b
    Valid from: Tue Feb 08 19:00:00 EST 2005
    until: Sun Feb 08 18:59:59 EST 2015Certificate fingerprints:
    MD5: 8D:E9:89:DB:7F:CC:5E:3B:FD:DE:2C:42:08:13:EF:43
    SHA1: D0:A5:BB:56:9E:CE:BE:B3:65:14:00:DE:BF:24:8B:A4:86:8C:7B:D8Trust this

    certificate? [no]: yes
    Certificate was added to keystore

    keytool -import -alias test -keystore test.keystore -trustcacerts -file Cert.cerEnter keystore password: foobar

    keytool error: java.lang.Exception: Failed to establish chain from reply

    Integrating Apache webserver with Tomcat

    This article is intended to provide a step by step description of the integration of two popular servers, Apache web server and Tomcat application server. There are at least thousands of documents that can be found on the web that describes the integration of these two servers. I read few of those to while doing the integration in my project. Though the downloaded documents helped me a lot to understand the steps but I found that most of those are effected by the same mistake- the generalization to support wide range of servers' versions and preconception that readers know the details before starting reading their articles. Here I’ll try to emphasize the exact steps without keeping any preconceptions.

    There are some limitations of this article and those are - it describes a specific scenario along with specific versions of Apache web server, Tomcat app server and Operating system. If your need is to configure any other version, that is not mentioned, don't blame me that you were not warned beforehand. My suggestion to you is to browse for more appropriate articles.

    Prerequisites

    To start the integration you’ll need to collect some tools and file(s) that will be required to reach the success point

    Servers version

    The following tools will be required:
    i. Web Server: Apache HTTPD 2.0.46 ( I collected it from www.apache.org/dist/httpd/ location)
    ii. Application Server: Jakarta Tomcat 4.1.18 (I collected it from http://jakarta.apache.org/site/binindex.cgi location)
    iii. Tomcat connector: mod_jk-1.2.8-apache-2.0.52.so (I collected it from http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/win32/ location)

    Operating System

    While doing the integration I worked on the following configurations of the operating system:
    i. Windows XP.
    ii. XP Service pack II

    Servers configuration

    You’ll have to configure both servers so that these can talk to each other. At first take a brief why you have to configure both of the servers:
    This is the sole responsibility of Apache to find out the Tomcat to connect with. For this, Apache needs a connector that can talk to Tomcat and that is the connector. There are several types of connector you can use. I used the JK connector to be connected with the Tomcat. The connector needs to know the port of the Tomcat server where to send data (the JK listening port of Tomcat). So the Apache needs to configure itself to find out the Tomcat and the Tomcat needs to configure itself to be found by the Apache.

    Apache WebServer

    The apache configuration steps are as follows:

    i. copy the Tomcat connector file (rename mod_jk-1.2.8-apache-2.0.52.so to mod_jk.so) to the APACHE_HOME/modules/ location

    ii. Create the workers.properties file in the APACHE_HOME/conf location and copy the following
    lines and paste in the above properties file:

    # Define 1 real worker using ajp13
    worker.list=worker1

    # Set properties for worker1 (ajp13)
    worker. worker1.type=ajp13
    worker. worker1.host=localhost
    worker. worker1.port=11009
    worker. worker1.lbfactor=50
    worker. worker1.cachesize=10
    worker. worker1.cache_timeout=600
    worker. worker1.socket_keepalive=1
    worker. worker1.socket_timeout=30000

    iii. Edit the APACHE_HOME/conf/httpd.conf file as follows:
    a. Add the following lines at the end of the LoadModule statements:

    LoadModule jk_module modules/mod_jk.so
    JkWorkersFile conf/workers.properties
    JkLogFile logs/mod_jk.log
    JkLogLevel debug
    JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

    b. Add the following lines at the end of the DocumentRoot directive statement:

    JkMount /webapp_name worker1
    JkMount /webapp_name/* worker1

    Tomcat
    Uncomment the tag (if already commented out) and change the port to 11009 (the value might be 8009) in the TOMCAT_HOME/conf/server.xml file

    Test the integration

    Do the following:
    i. Start the Tomcat Server
    ii. Start the Apache Web Server
    iii. Open a browser and type the URL in the Address bar http://host/webapp_name
    iv. Enjoy your application through the Apache Web Server.

    Unified Modeling Language in 5000 words

    1. Overview Designing is the most significant part of the software development process that requires the ability to view the real world problem in it's abstract form. The designers analyze the problem domain and sketch a possible solution to the problem by breaking the domain up in to different objects and their relationships. The designers design the system but the challenge is how they would communicate their thoughts to the programmers who eventually will write code to build the system. We need some sort of norms or protocols to represent the design of a software which is unambiguous in nature and has uniform meaning to everyone. Here the significance of standard notations comes into the picture. The most renowned and widely accepted solution to overcome this communication challenge is the Unified Modeling Language (UML), a non-proprietary, object-modeling and specification language used in software engineering. UML includes a standardized graphical notation that may be used to create an abstract model of a system: the UML model. The UML has quickly become the de-facto standard for building object-oriented software.

    The OMG specification states:

    "The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components."

    The important point to note here is that UML is a 'language' for specifying and not a method or procedure. The UML is used to define a software system; to detail the artifacts in the system, to document and construct - it is the language that the blueprint is written in. The UML may be used in a variety of ways to support a software development methodology (such as the Rational Unified Process) - but in itself it does not specify that methodology or process. Nevertheless, the following factors have led to UML’s rapid and widespread acceptance in the object-oriented design community:
    • The language is based on experience
    • The language is expressive
    • The language has been adopted by the Object Management Group (OMG), a consortium of companies in the object business. As a result, numerous Computer Aided Software Engineering (CASE) tools support it.

    As stated earlier, there are a bunch of CASE tools that support the UML specifications; some of those are:
    • Rational Rose from Rational
    • TogetherJ from Together Soft
    • ArgoUML, from open source community etc.
    When you are finished reading you will not have enough knowledge to put UML on your resume, but you will have a solid starting point for digging more deeply into the language. UML 2.0 is the basis that I followed through out the article. You'd learn the followings:
    • UML concepts
    • Highlighted distinctions of UML 2.0
    • Various diagrams of the language those includes Use Case diagram, Class diagram, Sequence diagram, State chart diagram, activity diagram, component diagram, deployment diagram etc.
    • Some criticism of UML
    • Basic installation and setup of ArgoUML and drawing of basic UML diagrams using it
    • Some best practices of UML uses
    Resource Reference
    Find the following links and reference to learn more details on this subject:

    Links:
    http://www.omg.org
    http://www.argouml.tigris.org
    http://www.javaworld.com
    http://www.sparsxsystems.com.au
    http://www.agilemodeling.com

    Reference:
    1. Designing Flexible Object-Oriented Systems with UML by Charles Richter
    2. ArgoUML Quick Guide: Get started with ArgoUML 0.18.1
    3. ArgoUML User Manual: A tutorial and reference description

    2 UML
    As mentioned earlier, one of the purposes of UML was to provide the object-oriented developers community with a stable and common design language that could be used to develop and build computer applications. UML brought forth a unified standard modeling notation that IT professionals had been wanting for years. Using UML, IT professionals could now read and disseminate system structure and design plans – just as construction workers have been doing for years with blueprints of buildings.

    UML defines the notations and semantics for the following domains:

    • The Use Case Model, describes the systems boundaries and its functionalities under analysis
    • The interaction model, describes how the objects interact with each other to form the system
    • The dynamic model, describes the states that classes assumes over time. Activity graphs describe the workflows the system will implement
    • The Logical or class model, describes the classes and objects and their relationships that will make up the system
    • The physical component model, describes the software components that make up the system
    • The physical deployment model, describes the physical architecture and the deployment of components on that physical architecture

    Although this is out of scope of this article to explain the design process but a simple design process might help the reader to map the modeling language with their usual software development life. Let’s look into the following example to explore the exact places where different models/diagrams fit:

    Define the high-level business activities and processes that occur in an organization. These provides the foundation of the Use Case model
    Complete the use cases by including requirements, constraints, complexity and scenarios. Also define the relationships among Use Case, if any.
    From the scenario texts, develop the sequence diagram, collaboration diagram etc.
    From the scenario diagrams develop the static view of the system: the class model. This is a precise specification of the objects in the system, their data or attributes and their behaviors or operations. Scenario diagrams messages shall typically map to class operations.
    As the class model develops it may be broken into discrete packages and components. A Component represents a deployable chunk of software that collects the behavior and data of one or more classes. So from the class model a component model is built to define the logical packaging of the classes.
    As the analysis and design progresses, the deployment model is developed to define the physical architecture of the system.

    2.1 UML 2.0
    As experience with UML grew and the issues and needs of software modeling became better understood, new requirements for UML emerged. This led to the issuing of format request for the first major revision of standard. Although the UML 2.0 has been introduced a few years back, in October 2004, but it won’t be redundant or excessive to describe some of the features of the newer version of the language.

    The following aspects most clearly distinguish UML 2.0 from earlier versions:
    • An increased level of precision in describing the basic modeling concepts in the language and, in particular, their semantics.
    • An improved capability to model large-scale software systems. This includes the ability to model entire system architectures – in effect, to use UML as an architectural description language.
    • Enhancements to allow modeling of complex network-based business processes and other functionally oriented applications
    • Nested Classifiers, an extremely powerful concept.

    In UML, almost every model building block you work with (classes, objects, components, behaviors such as activities and state machines, and more) is a classifier. In UML 2.0, you can nest a set of classes inside the component that manages them, or embed a behavior (such as a state machine) inside the class or component that implements it. This capability also lets you build up complex behaviors from simpler ones, the capability that defines the Interaction Overview Diagram.

    2.2 Diagrams
    According to the latest version of UML, there are 13 types of diagrams. To understand them, it is sometimes useful to categorize them in the following three groups based on their characteristics:

    Structure Diagrams emphasize what things must be in the system being modeled:
    • Class diagram
    • Component diagram
    • Object diagram
    • Composite structure diagram
    • Deployment diagram
    • Package diagram

    Behavior Diagrams emphasize what must happen in the system being modeled:
    • Activity diagram
    • Use Case diagram
    • State Machine diagram

    Interaction Diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:
    • Sequence diagram
    • Collaboration (UML 1.x)/Communication diagram (UML 2.0)
    • Interaction overview diagram (UML 2.0)
    • Timing diagram (UML 2.0)
    2.2.1 Structural
    2.2.1.1 Class Diagram
    In the Unified Modeling Language (UML), a class diagram is a type of static structure diagram that describes the structure of a system by showing the system's classes and the relationships between them. Class is the blueprint of the objects that, with its attributes and behaviors, constructs the system in the Object-Oriented design through the use of associations and relations.

    The Class Model is at the core of object-oriented development and design - it expresses both the persistent state of the system and the behavior of the system. A class encapsulates state (attributes) and offers services to manipulate that state (behavior). Good object-oriented design limits direct access to class attributes and offers services which manipulate attributes on behalf of the caller. This hiding of data and exposing of services ensures data updates are only done in one place and according to specific rules - for large systems the maintenance burden of code which has direct access to data elements in many places is extremely high.

    Figure 1: Class model

    The class has three distinct areas:
    1. The class name
    2. The class attributes i.e. the internal data structure
    3. The class operations to manipulate its data

    Attributes and operations may be marked as one of the followings:
    • Private (using “—“), indicating they are not visible to callers outside the class
    • Protected (using “#”), they are only visible to children of the class
    • Public (using “+”), they are visible to all

    Relationships:
    UML has basically two types of relationships for the class diagram and these are:

    Specialization
    Specialization and Generalization is the relationship between classes showing is-a-kind-of relationship, in which specialization is the subclass, or subtype and the generalization is the superclass, or supertype; the notation for class specialization and generalization is depicted in the below figure:
    Figure 2: Specialization or Generalization

    Association
    An association describes the logical relationship or dependencies between classes. The association includes cardinality constraints on its end and might have the following values:
    • If the end of an association is plain, the cardinality is unspecified
    • A non-negative integer indicates that specific value
    • An asterisk (*) means many
    • A range is denoted using two ellipsis pings (..). hence, 1..* indicates one or more.
    • An asterisk (*) alone is shorthand for 0..* i.e.,. zero or more
    • Commas separate discrete values. For example, 3, 5 means 3 or 5

    The following figure depicts the associations and its cardinality:

    Figure 3: Associate with cardinality

    Aggregation:
    The aggregation relationship is a special form of association used to model the whole-part or part-of relationship. It is drawn with all of the diagrammatic conventions of associations except that a diamond symbol appears next to the whole element. The following figure indicates that an OBJECT1 is a whole with any number of OBJECT2 items as parts.

    Figure 4: Aggregation association

    Composition:
    UML provides a second form of aggregation with very specific and strong semantics, which is the composition relationship. Filling in the diamond specifies it. The composition relationship indicates “strong ownership and coincident lifetime of part with the whole”. The whole must therefore create the part when the whole is created, and it must delete the part as it is deleted. This also implies that a part can belong only to a single whole.


    Figure 5: Composition association

    Best practice for designing class diagram:
    1. Increase Cohesiveness: It is a measure of the diversity of an entity’s features. The less diverse its features are, the more cohesive the entity is. In other words, a highly cohesive entity represents a single concept or engages in just one general type of activity.
    2. Reduce Coupling: Coupling in an object-oriented design is a measure of how much a class or an object knows about the world around it. If an object knows about another object more than the first object’s implementation might be affected by the change of the second object’s behavior.
    3. Avoid Concrete Super class: The Super class object should not have the instantiation capability. It should be characterized as abstract to keep the place for flexibility.
    4. Make the properties of superclasses meaningful in all subclasses. You generally do not want subclasses to inherit things they don’t need.
    5. Use specialization only when you have an “is-a-kind-of” relationship.
    6. Use aggregation more than specialization: Though specialization seems much more object oriented than aggregation, but aggregation shall keep your design more flexible and less prone to change. Also avoid deeper level of specialization (e.g. more than 3 level)
    2.2.1.2 Package Diagram
    A package diagram is used to show the logical groupings and the relationships among the groups of a system. The package diagram has the following implications:

    • It draws the logical dependencies among the packages. It is a best tool for the software manager to distribute the work packages to the developers effectively.
    • The dependency can be measured from the relations among the packages. This is best use by the Change Control Board (CCB) to find out the impact of a proposed change.
    • Helps to see the overall logical view of the system

    Figure 6: Package diagram

    2.2.1.3 Deployment Diagram
    The deployment diagram defines the hardware architecture of a system or application. Its purpose is to show where the different components of the system will physically run and how they will communicate with each other. Since the diagram models the physical runtime, the implementation team will make considerable use of this diagram.

    The diagram includes a set of nodes, shown as three-dimensional cubes. Each node represents a class of hardware processor and is labeled with the type of the node. The relationships between nodes represent physical connections between the corresponding processors. Both the nodes and relationships can include cardinality constraints. The cardinality constraint of a node usually appears in the upper right corner of the node.

    Figure 7: Deployment diagram
    2.2.1.4 Composite Structure
    The composite structure diagram is used to show the objects involved in collaboration. This is a good tool for describing design pattern, broadly believed by the strong supporter of the latest release of the language. But the developers are greatly familiar with the combination of Class diagram and Sequence diagram while developing a design pattern.

    2.2.1.5 Component Diagram
    Philippe Kruchten provides two complementary characterizations of a component:

    A component is a non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A component conforms to and provides the physical realizations of a set of interfaces.

    Components offer one or more interfaces and are dependent only on the interfaces of other components

    A component diagram provides a physical view of how a system is split up into physical components (e.g. files, headers, link libraries, modules, executables, and packages) and shows the dependencies among these components. Its purpose is to show the dependencies that the software has on the other software components (e.g. software libraries) in the system.

    <<Diagram: Sample Component diagram>>


    2.2.1.6 Object Diagram
    An object diagram is a diagram that shows a set of objects and their relationships at a point in time. Graphically, an object diagram is a collection of vertices and arcs.

    An object diagram commonly contains Objects and Links and may contains notes and constraints. Object diagram may also contain packages or subsystems, both of which are used to group elements of your model into larger chunks.

    You use object diagrams to model the static design view or static process view of a system just as you do with class diagrams, but from the perspective of real or prototypical instances. This view primarily supports the functional requirements of a system – that is, the services the system should provide to its end uses. Object diagrams let you model static data structures.

    2.2.2 Behavioral
    2.2.2.1 Use Case Diagram
    A Use Case illustrates a unit of functionality provide by the system. The main purpose of the use-case diagram is to help development teams visualize the functional requirements of a system, including the relationship of “actors” (human or any other system that interacts with the system) to essential processes, as well as the relationships among different use cases.

    The use case diagram contains three basic components:

    System: The system is depicted as a rectangle, labeled with the name of the system

    Actor: Each actor is shown as a stick figure

    Use Case: Each use case is shown as a solid-bordered oval labeled with the name of the use case


    Figure 8: Use Case diagram showing the three notations>>

    Use Case Relationships
    Use Case diagrams can include relationships between actors and use cases as well as between the use cases themselves. There are two types of relationships: Uses and extends


    The UML Notation Guide states uses relation as:

    A uses relation from use case A to use case B indicates that an instance of the use case A will also include the behavior as specified by [use case] B.

    The notation is a closed-headed arrow annotated with the stereotype name uses. See Figure 8 for the uses relationship

    The UML Notation Guide states extends relation as:

    An extends relationship from use case A to use case B indicates that an instance of use case B may include (subject to specific conditions specified in the extension) the behavior specified by [use case] A

    The notation is the enclosed-headed arrow directed away from the extension (that is, toward the use case that is being extended) with the “extends” stereotype annotation. See Figure 8 for the extends releationship

    2.2.2.2 Activity Diagram
    An activity diagram is a workflow view. It depicts a set of activities that must be carried out, together with the temporal sequencing of those activities and the conditions under which they occur. It says nothing about what objects are involved. It, therefore, can be used for everything from showing the sequencing of use cases to flow charting an individual method.

    Figure 9: Activity diagram

    You can refine a use case into an activity diagram that “flowcharts” the steps in the use case. Following is the brief description of the notations of an activity:

    1. An activity is modeled as a capsule (that is, as a rectangle with rounded corners) with the activity name enclosed. The activity diagrams starts with a solid circle connected to the initial activity. The end activity is drawn by a small circle, containing another little smaller filled circle

    2. The simplest relationship between two activities occurs when one must follow the other. It also contains the cardinality like class diagram.

    3. You can indicate that one activity conditionally follows another. The diamond shape (same one is used in the flow chart notation) is used includes condition in the activity diagram

    4. Parallelism is an unique notation that helps the designer to draw the multi threaded software.

    5. The activities are sometimes organized into different swimlanes which are used to indicate the object actually performs the activity.

    2.2.2.3 State Machine Diagram
    A state transition diagram is used to show the state-based behavior of a class of instances across all scenarios. Whereas the scope of an interaction diagram is a single scenario, a state machine is tied to one class. It specifies the states through which an instance of that class may pass, the messages to which that instance will respond in each of those states, and the conditions that cause the instance to pass from one state to another

    Figure 10: State chart diagram

    A state is an abstraction of an object’s state. It is depicted in UML as a capsule with a name and/or a set of actions.
    A transition is the movement of an object from one state to another. It is assumed to take almost no time. In a state machine, a transition is depicted as a directed edge between the source and destination states. There are various transitions:

    a. Transitions may be triggered by events. There may be a condition (known as a guarding condition) towards a state.

    b. A state machine can execute actions while taking a transition.

    c. An important grouping feature of State charts is the composite state. A composite state is composed of a collection of lower-level sub-states that share semantics. For example, all of the sub-states may have the same outgoing transition. The states outside the composite states in some cases may ignore the internal details of the composite state and interact with it is as a single state.


    2.2.3 Interaction2.2.3.1 Sequence Diagram
    An interaction/sequence diagram indicates the sequencing of object interactions in one scenario. It shows exactly which objects respond to which requests, as well as the results of those requests, in that scenario. On the other hand, the internal state of an object, as well as how that state may change during the scenario, is not shown.

    A sequence diagram has two dimensions: The vertical dimension shows the sequence of messages/calls and optionally returns of messages/calls in the time order that they occur; the horizontal dimension shows the object instances to which the messages are sent.

    A sequence diagram is very simple to draw:
    • Across the top of your diagram, identify the class instances (objects) by putting each class instance inside a box.
    • In the box, put the class instance name and class name separated by a space/colon/space (e.g. myTask:Task).
    • If a class instance sends a message to another class instance, draw a line with an open arrowhead pointing to the receiving class instance; place the name of the message/method above the line.
    • Optionally, for important messages, you can draw a doted line with an arrowhead pointing back to the originating class instance; label the return value above the dotted line. It is a good practice to include the return value lines because it makes it easier to read.


    Figure 11: Sequence Diagram

    2.2.3.2 Communication Diagram
    Communication diagrams are equivalent to UML sequence diagram and are typically used when you need a bird’s-eye-view of collaborating objects.

    2.2.3.3 Timing Diagram
    Timing diagrams, for exploring the changes in state an object or component, have been added in the UML 2.0 release. This has a little use with business application developers but might found very useful for the real-time community.

    2.3 Criticism
    UML has some criticisms those are not baseless though the notations has the wide range of acceptance in the field of software engineering:
    • The semantics are imprecise to subjective interpretation and difficulties in the format test phases of development.
    • It has weaknesses to design distributed system
    • The User Interface design is not specifically covered by any of the UML diagrams.
    3 Best Practices

    During the design phase of the Software Development Life Cycle (SDLC) the following practices might help you avoid the pitfall usually faces in a development team:

    • Use the UML notations from the very beginning of your designing phase otherwise it will cost extra boring hours to convert your own invented notations to the UML diagrams.
    • Don’t try to fit UML diagrams to your design rather fit your design thoughts to UML diagrams.
    • In the brainstorming session of designing it is best to use paper-pencil rather UML tools. It would give you a room to trace back your design if anything goes wrong
    • Don’t be perfectionist while designing but complete your tasks in the stipulated time with what you came out with your present knowledge level. Remember that it is the iterative process and you can easily refine your design at the time of development. If you have to redesign your software more that 20% in the coding phase, you need to be careful in the next design.
    • Always keep your design up-to-date with the coding though it costs some extra hours of the designer; it will make your life easy in the bug fixing phase and reduce the dependency on the original coder.
    • Use separate engineer to code rather than the original designer of that module; it is helpful to keep the sanity of the design document

    5 SummaryI’ve tried to describe all of the diagrams those are used in UML 2.0 release. Some of those are used heavily by the designer community and some are not that much popular. You might notice that the descriptions are lengthened for the diagrams those are widely used; those are:
    • Use Case diagram
    • Class diagram
    • Sequence diagram
    • State chart diagram and
    • Activity diagram

    The fewer used diagrams are sometimes just defined and then left to the reader if he is interested on that topic.

    Although this article provides only a brief introduction to Unified Modeling Language, I encourage you to start applying the information you have learned here to your own projects and to dig more deeply into UML. There are several software tools that help you to integrate UML diagrams into your software development process, but even without automated tools, you can use markers on a whiteboard or paper and pencils to draw your UML diagrams and still achieve benefits.

    Startup

    This is the startup of my blog writing. This posting has been created just to see the effect