You have probably heard or read something about software agents; they have been a hot topic for some time now and agent-based commercial products are available. There are several schools of thought on what the term “agent” really means. For example, in the context of artificial intelligence, an agent is often described as an autonomous, intelligent entity: They can make decisions and perform actions based on perceived inputs in order to achieve some goal (Russell, S., and P. Norvig, Artificial Intelligence: A Modern Approach, 1995).

Mobility is a common characteristic of many agent definitions. A mobileagent is an active object that can move both data and functionality (code) to multiple places within a distributed system. It doesn't matter what the ultimate purpose of the agent is or whether or not it can be classified as “intelligent.”

A mobile agent should be able to execute on any machine within a network, regardless of the processor type or operating system. In addition, the agent code should not have to be installed on every machine that the agent could potentially visit; it should move with the agent's data automatically. Therefore, it is desirable to implement agents on top of a mobile code system, such as Java virtual machine (VM). The dynamic nature of Java classes and objects, combined with advanced networking capabilities, makes Java highly qualified for use as a mobile agent platform.

Java has rapidly emerged as an important tool for the development of cross-platform, distributed applications. While Java has been primarily associated with the Web, it is a much broader technology with applications far beyond the Internet. To take advantage of the capabilities of Java and its wide range of application programming services, an organization must enhance the skill base of its workforce in several critical areas, among them object-oriented programming, interactive and event-driven application development, distributed (client/server) systems architecture, and coming up rapidly, design and use of components (beans) for Java's component architecture, JavaBeans.

To create an effective and successful migration strategy for its development and project management staff, a company must consider several factors. These factors are discussed in detail in this article.

AUDIENCE

Each group of potential Java users will likely need a different migration strategy. While one group, such as software developers, may need in-depth knowledge of the Java programming facilities, another group, such as project managers, need only a superficial understanding of the language features but a strong understanding of the impact that the use of Java has on a project. The audience for a migration effort can be broken into five distinct groups:

• Software Developers

• Web Masters

• Software Architects

• Project Managers

• Business Analysts

1. Adhere to the style of the original.

2. Adhere to the Principle of Least Astonishment.

3. Do it right the first time.

4. Document any deviations.

5. Indent nested code.

6. Break up long lines.

7. Include white space.

8. Do not use “hard” tabs.

9. Use meaningful names.

10. Use familiar names.

11. Question excessively long names.

12. Join the vowel generation.

13. Capitalize only the first letter in acronyms.

14. Do not use names that differ only in case.

15. Use the reversed, lowercase form of your organization's Internet domain name as the root qualifier for your package names.

16. Use a single, lowercase word as the root name of each package.

17. Use the same name for a new version of a package, but only if that new version is stillbinary compatible with the previous version, otherwise, use a new name.

18. Capitalize the first letter of each word that appears in a class or interface name.

19. Use nouns when naming classes.

20. Pluralize the names of classes that group related attributes, static services, or constants.

21. Use nouns or adjectives when naming interfaces.

22. Use lowercase for the first word and capitalize only the first letter of each subsequent word that appears in a method name.

23. Use verbs when naming methods.

24. Follow the JavaBeans™ conventions for naming property accessor methods.

25. Use lowercase for the first word and capitalize only the first letter of each subsequent word that appears in a variable name.

26. Use nouns to name fields.

27. […]

THE THIRD SERIAL PHASE of the OOSP is the Deliver phase, commonly referred to as delivery or implementation in the structured world. This is where you verify and deliver the application to its users by:

• Testing in the large, an object-oriented version of integration and function testing, to verify that your application works as a whole and that it meets the needs of your users.

• Implementing the application, to put it in the hands of its users.

• Reviewing the project so that you can learn from both your successes and from your mistakes.

THIS book continues a new approach to understanding the key development issues that constantly distract important software projects from delivering effective software, because they aren't documented in most organizations. It has been known for many years that an effective software development lifecycle will deliver good software with fewer defects than the uncontrolled random iteration of code and requirement. The initial book defined the core development stages and lifecycle. The second volume provides the management, testing, and delivery phases of development.

The world of software and system development is changing. Tools and languages are starting to gain de facto standards that are allowing projects to develop the more complex systems being demanded by the business and end users. As more people join the software industry, experience is being stretched and it is becoming more difficult to find senior developers with more than three strong projects behind them. Communicating experience is becoming one of the most important success factors to most development teams. Quality systems are fine for defining the letter of the law and rules that must be obeyed to keep a project on track, but they often miss the guidance and explanation of why it is important to follow the steps outlined in their often hundreds of pages. These can make quality systems very unapproachable by the average developer.

Scott's book provides an intuitive and clearly written guide to the key issues, concepts, deliverables and processes needed to deliver a successful project.

THE FOURTH SERIAL PHASE of the OOSP is the Maintain and Support phase, commonly referred to as maintenance and support in the structured world. This is where you keep the application running and as up-to-date as possible by:

• supporting the efforts of users by providing training, answering their questions, and fixing any problems that they may encounter.

• identifying any possible bugs with the application, prioritizing those bugs, and then addressing those bugs in a future release.

• identifying any possible enhancements that can be made to the application, prioritizing those enhancements, and then making those enhancements in a future release of the application.

WHEN we left off in Process Patterns (Ambler, 1998b) I had taken you to the point where your software was written. Now in More Process Patterns I'll show you how to deliver, and then maintain and support applications built using object-oriented (OO) technology. Sadly, these are two topics that have been generally overlooked by the object community, until now. There is a lot more to OO development than writing code. There is also a lot more to it than creating use cases, CRC models, and class diagrams. OO development is about creating applications that solve the needs of your users. It's about doing this in such a way that the applications that are built are timely, accurate, and of high quality. This book is about helping you to accomplish these worthy goals.

In this chapter I summarize key concepts presented in Process Patterns. I explore common myths about object-oriented development; describe what process patterns are all about; discuss the object-oriented software process (OOSP) focusing on the serial phases, iterative stages, and the project and cross-project tasks that are vital to the success of your software efforts; and overview the Software Engineering Institute (SEI)'s Capability Maturity Model (CMM).

Exploring Object-Oriented Myths

One thing that you have likely read is that OO development by its very nature is iterative. As you saw in Process Patterns this is only partly true. The main components of OO development—modeling, programming, and testing in the small (formerly known as unit testing)—are in fact performed iteratively.

THE goal of the Maintain and Support phase, the fourth serial phase of the object-oriented software process (OOSP), is to keep your application running in production and to ensure that changes to the application are identified and acted on appropriately. Common forces applicable to this stage are the unwillingness of senior management to adequately fund maintenance and support efforts, the unwillingness of “hard-core” developers to perform maintenance activities (or to even recognize their importance), and the difficulty of finding and retaining support staff.

The process pattern depicted in Figure 7.1 shows that the Maintain and Support phase is comprised of two stages: the Support stage (Chapter 8) and the Identify Defects and Enhancements stage (Chapter 9). The Maintain and Support phase begins for an application after it has been successfully delivered to your customers—your user, support, and operations communities. The main output of this phase is a series of maintenance changes that have been allocated to the configuration items (CIs) that make up your application, changes that are accompanied by the software problem reports (SPRs), and software change requests (SCRs) from which they were generated.

The purpose of the Support stage is to respond to incoming support requests from users; to identify a resolution for the issue; and then to oversee the implementation of that resolution.