INCEPTION

USER REQUIREMENTS

Description 7-1 gives a brief description of the application.

More on User Requirements

The following are detailed requirements of the application. Most of these will be more useful during the design stage and serve to shape the object model.

INCEPTION

USER REQUIREMENTS

Description 5-1 gives a summary of the user requirements, and Description 5-2 lists a glossary of terms.

AN OVERVIEW OF PROCESS MODELS

Several process models were discussed and developed to provide a set of activities that permits the development of software systems from user requirements. Almost all processes follow the development of software through the following phases: analysis, design, and implementation, in addition to system testing.

Analysis is the phase during which user requirements are determined and requirement specifications are documented. User requirements are typically collected in a language that is familiar to the user, where a user in this context could mean a real user, the company, or a vendor that requests the software to be developed to automate certain services. The requirements describe what the system is requested to deliver as automated services. Requirements are documented in a specification language that is understood by the designers and developers and that steps away from the user, creating, more or less, a gap between the language and requirements expressed by the user and language and tools applied by analysts, designers, and implementers. The output of this phase is a requirement specification document.

The design phase follows analysis. During design a system designer relies on system specifications reached during the analysis phase to lay out the design of the system.

INCEPTION

USER REQUIREMENTS

Detailed Description of Stages

When starting the application, the student has two choices:

1. 1. The user chooses to take consecutive lessons. The user will start from the lowest level (level 1) and go consecutively through all the lessons of each of levels 1 and 2. In this case, the user will not receive any prize.

2. […]

In Chapter 2, we have discussed components and described their benefits. The software architecture that supports the operation of components is called the component “container.” It provides the environment in which a particular type of component can be run and manipulated.

Components come in many different forms, from the ubiquitous JavaBean to Web services, and at many different levels of scale. At the small-scale level, components with a visual aspect, such as drop-down boxes, tree lists, and buttons, are assembled into a single form. At the high-scale level, entire services such as order entry, billing, and inventory update are combined into a complete application.

All levels of components, however, have one thing in common: they all operate within some specific component container. Often, this container is one of the services provided by a framework.

A framework is not only a component deployment environment, but also it is used throughout the development of an application and its components. It is a part of both the development and the run-time life of your application.

In this chapter we explore frameworks in more detail. We describe the features you will likely find, and the benefits they provide to your development project.

We also include what application development frameworks provide in broad terms and how they relate to APIs (e.g., JavaMail). We discuss the common elements found in many Web applications, and how appropriate components and frameworks can be used to provide these elements.

In this chapter we summarize the discussions in the previous chapters to highlight the most significant points and discuss the future of frameworks and components. We look briefly at the trends that are leading the way to the future of application development, and how frameworks and components fit in.

EMERGING FRAMEWORK/COMPONENT TECHNOLOGIES

Frameworks are gradually expanding their reach into other areas of Web-application development. Combined with Java's advances with new and extended standard libraries, it means future Web applications will use some exciting new technologies.

The fastest growing segment of the Web-application community is the area of mobile and wireless application. Although some frameworks already focus on this market segment (Roaming Media Framework and Java Micro Framework), others also provide services to both desktop and mobile clients, such as Cocoon with its advanced WML support.

New Interface Paradigms and Frameworks

We have already discussed in previous chapters the importance of Web applications having highly flexible user interfaces. With the wealth of new devices being connected to the Internet today, your application will be called on to interact with everything from devices with effectively no visual interface at all (such as appliances, and even the fridge) to mobile devices with a functional but limited interface (such as Web-enabled televisions, cell phones, pagers, and other wireless clients), all the way to devices with extremely rich interface capabilities, such as full-blown desktop browsers with scripting support.

COMPARING FRAMEWORKS

Now that we have seen a number of different frameworks, we can make some comparisons of what we have seen and draw a few conclusions. It is important to realize that there is no “better” framework in absolute terms.

Comparisons

It is important to realize, as we look at different frameworks and their methods of solving the problems of Web-application development, that no one specific approach is “right” or “wrong.” They all have their advantages and disadvantages. Also, do not think that if we have not covered a particular framework in detail that it is not potentially a good choice for your project. We have just looked at a few of the more well-known examples, and there are many others. New frameworks are created frequently, particularly application-specific ones.

We saw in Chapter 4 the wide variety of services provided by frameworks. Now that we have seen different examples of frameworks, we can contrast their approaches, and compare the advantages and disadvantages of those approaches. We will examine each of the most common services provided by frameworks, and see what kinds of approaches the frameworks we have examined use to handle these services, and what are the pros and cons of that approach for different kinds of projects. As we proceed, you will see a number of “themes” that come up repeatedly – some of these are the design patterns that are common to frameworks, which we will examine in Chapter 8 in detail.

FRAMEWORKS AND METHODOLOGIES

A software methodology is a set of guidelines, rules and, practices used in development projects. Some methodologies have more rules than others, and have a greater impact on the development process. As software development evolves, and comes closer to being recognized as an engineering discipline than an art, practices that work well are discovered through experience, and these practices are formalized over time into methodologies. Simply adding more rules and procedures, however, does not necessarily result in better methodology, in the same way that adding new functionality to a framework does not necessarily result in a better framework. Methodologies that are “lightweight,” but highly effective, are often the easiest to apply and the best in practice, as they impose relatively few burdens on the development process – and are therefore more likely to be actually used!

There are many parallels between development methodologies and frameworks, and we explore here how the two interrelate, and how your development methodology has an impact on your choice of framework, and vice versa.

Use of a framework does not necessarily imply that you have to work with a particular development methodology. Some frameworks have, however, been created with such methodologies in mind – a good example is the JUnit unit test framework. It was developed with the Extreme Programming methodology in mind, and is in fact ideally suited for use with this technique. Other frameworks were designed with Aspect Oriented Programming, or another similar methodology.

INTRODUCTION

Welcome, I would like to introduce myself, and discuss the explorations that I would like to take you on in this book. I am a software developer, specifically, an application developer. I build software that people use to get their jobs done – practical, everyday software that is being used.

As part of building applications, in some cases I have also had to build some of the tools I needed including components and an application framework. My programming language of choice for the last several years has been Java. My applications have been targeted for Internet/Intranet uses.

In my exploration, I will examine the nature of software development. It is a complex and demanding process, and developers can use all the tools that are available to them to make it easier and more efficient. We also explore how and why developers resist using those very tools, and how you can make the right decisions in your development projects. It has been a long road, and my hope is to impart some knowledge of its many potholes to you.

I think that I have spent a fair portion of my career in the field resisting the “jargonification” of software development. I am convinced that development can be discussed in plain English, as has been done in this book. It is, however, important to understand the basic terminology used to describe frameworks and components, so we will do this first.

In this chapter, we will take a brief look at a number of more popular and extensive Web application frameworks. It is not our intention to reproduce the frameworks' own documentation here: you may refer to the appropriate website for each framework for technical and user documentation. What we want to do is observe the frameworks as examples of Web application building frameworks in general, and to outline their major capabilities. Each framework has its strengths and weaknesses, which we will explore in detail later when we compare frameworks in Chapter 6.

Many of these frameworks would take an entire book to fully explore, so what we discuss here is just an outline of what they have to offer. A large number of frameworks are open-source projects, and are actively under development – so it is important to see what has changed and what is new when you review the framework yourself.

You will not find here an evaluation of the framework. It is not possible to judge the suitability of a framework for your particular task without the knowledge of a great many factors, some of which we will explore in Chapter 6, where we will show how to match up the problem with the potential solutions and choose a suitable framework for your task. There are no absolute measures by which we can say this framework is “better” than some other one – you must decide that based on your requirements.

In this chapter, we look at the differentiating factors of frameworks, and give you a set of techniques for choosing frameworks. We also look at how you can determine whether a particular framework fits your needs. We concentrate on the practical job of choosing the right pieces to get the job done, and give you the information you need to choose the right tool.

OVERVIEW

Let us say that you are convinced that the benefits of frameworks are real, and that it would make good business sense for you and your organization to adopt an appropriate framework. Now what? Where do you go to find frameworks, and how do you go about evaluating them? When you first start evaluating frameworks, there are some high-level observations you can make right away. Let us examine them first and then get into more details.

Identification

There is sometimes a fine line between a component library and an application framework. Some products are oriented more toward providing a set of application elements, rather than providing the backbone to build an entire application. Often, component libraries are more focused, concentrating on a particular area of the application, such as file access, visual presentation, or middle-ware elements. In general, a component library is defined as a collection of fully-developed components, and may include capabilities for generating your own components.