Editorial Reviews
Jack Woehr
Patterns in Java, Volume 2, by Mark Grand, introduces patterns to the reader and applies them to Java. It is part of a projected three-volume series of which volumes one and two are now published. It is also part of a commendable Wiley Computer Publishing Java initiative of which several books (Graphics Programming for JFC, Programming Mobile Objects in Java, and so on) have already been reviewed on the ERCB and of which Advanced Techniques for Java Developers will be reviewed soon.
Although I haven't seen Volume 1, Patterns in Java, Volume 2 seems to restart at the beginning, describing the history of the Patterns metaphor in software design and introducing the reader to UML before proceeding to the patterns.
The book divides the discussion into the software life cycle, GRASP patterns, GUI design patterns, organizational coding patterns, coding optimization patterns, code robustness patterns, and testing patterns. There's also a brief bibliography devoted to sources of citations in the text and an appendix presenting an overview (or headline summary, rather) of patterns in Java with reference to the patterns contained in both Volume 1 and Volume 2.
While several of the Wiley Java series appear aimed both at intermediate programmers exploring programming through Java and at experienced software engineers looking for quick Java immersion, Patterns in Java, Volume 2 seems most suitable for programmers becoming seriously involved in Java early in their career. This assessment is occasioned by the book's attempt to shoehorn all of computer science into the Patterns metaphor.
Each new wave in programming brings with it the temptation to view all that has come before in terms of the new approach. This sort of thing in print is only entertaining to the enthusiast. When the author learnedly cites Jennifer Tildwell's "Interaction Patterns" pattern "Disabled Irrelevant Things" as authority that we should hide and disable GUI elements that are not relevant in the current context, it's hard not to think of Monty Python and the Theory of the Brontosaurus being Small at One End, Large in the Middle, and Small at the Other End.
And you must seriously question the value of the author's approach even for the novice when concepts such as lookup tables and loop optimization are presented in Patterns terms. Aren't these elements of the art more effectively viewed in classic terms and at a lower level? A discussion of the irrational, architecturally imposed, metaphor-free limitations of electronic computer programming as it has evolved from the von Neumann model in terms of Patterns is like trying to catch an elephant by looking at it through the wrong end of the telescope and grasping the tiny beast with tweezers.
It's good that the Patterns idea is catching on. Years ago, our team used the term "software cliches" for the same thing. And, yes, there can be a great deal of value in raking through extant praxis and experimentally notating the same in the new Patterns metaphor. You could infer from a reading of Patterns in Java, Volume 2 that the Patterns methodology has a lot of maturing to do, mostly along the lines of "de minimis non curat lex" ("the law does not concern itself with the trivial"). Still, Mark Grand is to be commended for his labor sowing what promises in time to become a capable design methodology in the fertile fields of Java.
— Electronic Review of Computer Books
Booknews
A sequel to the 1998 first volume that includes specialized rather than merely general purpose Java patterns that programmers can use for recurring tasks. Seven illustrate how to assign responsibilities to classes, twelve are for graphic interfaces, 13 are coding optimization, five are code robustness, and eight are testing patterns for software. A tutorial on writing designs in Unified Modeling Language is also included. The CD-ROM contains all the code in the text. Annotation c. Book News, Inc., Portland, OR (booknews.com)
Show More
Read an Excerpt
Chapter 3: The Software Life Cycle
This chapter first describes the software life cycle, then presents the object-oriented design portion of a case study. software. Figure 3.1 shows some of the activities that lead up to the deployment of a piece of business software.
during a software project. It merely shows some of the common activities for the purpose of understanding the context in which the patterns discussed in this book are used. The three volumes of this work describe recurring patterns that occur during the portion of the software life cycle labeled "Build" in Figure 3. 1.
practice, the boundaries are not always so discernible. Sometimes it is difficult to determine if a particular activity belongs in one box or another.
The precise boundaries are not important. What is important is to understand the relationships between these activities. analysis, determine the course of the activities that follow them, such as defining essential use cases or object-oriented design. However, in the course of those later activities, deficiencies in the products from earlier activities can emerge. For example, in the course of defining a use case, it may become apparent that there is an ambiguous or conflicting requirement. Making the necessary changes to the requirements generally results in the need to modify existing use cases or write new ones. You should expect such iterations. As long as the trend is for later iterations to produce fewer changes than earlier ones, consider such iterations part of the normal development process.
activities shown in Figure 3. 1. The purpose of these descriptions is to provide enough background information about these activities to understand how the patterns discussed in this book apply to a relevant activity. The case study that follows the descriptions provides deeper insights into these activities.
Business Planning This typically starts with a proposal to build or modify a piece of software. The proposal evolves into a business case. A business case is a document that describes the pros and cons of the software project and also includes estimates of the resources required to complete the project. If a decision is made to proceed with the project, a preliminary schedule and budget are prepared.
Define Requirements The purpose of this activity is to produce a requirements specification that indicates what the software produced by the project will and will not do. This typically begins with goals and high-level requirements from the business case. Additional requirements are obtained from appropriate sources to produce an initial requirements specification. As the requirements specification is used in subsequent activities, necessary refinements to the requirements are discovered. These refinements are incorporated into the requirements specification. The products of subsequent activities are then modified to reflect the changes to the requirements specification. Define Essential Use Cases A use case describes the sequence of events that occurs in a specific circumstance between a system and other entities. The other entities are called actors. Developing use cases improves programmers understanding of the requirements, analysis, or design that the use case is based on. As programmers develop better understanding of requirements, analysis, and design, they are able to refine them. domain. Use cases that describe events in terms of the internal organization of software are called real use cases. high level in the sense that they explore the implications of what they are based on, but do not try to add additional details. Create Prototype The purpose of this activity is to create a prototype for the proposed software. Programmers can use a prototype to get reactions to a proposed project. Programmers can use reactions to a prototype to refine requirements and essential use cases.
Define High-Level System Architecture
The purpose of this activity is to determine the major components of the system that are obvious from the original proposal and their relationships.
Object-Oriented Analysis
Object-oriented analysis is an analysis of the problem domain. The purpose of this activity is to understand what the software produced by the project win do and how it will interact with other entities in its environment. The goal of analysis is to create a model of what the software will do, but not of how to do it. The products of object-oriented analysis model the situation in which the software will operate, from the perspective of an outside observer. The analysis does not concern itself with what goes on inside the software.
Design User Interface
The purpose of this activity is to determine the nature of the interactions between the program and the user based on use cases. Once the nature of the interactions is identified, the user interface is designed and the details of how the user will interact with it are identified.
Object-Oriented Design
The purpose of this activity is to determine the internal organization and logic of the software. The products of the design effort- identify the classes that constitute the internal logic of the software. They also determine the internal structure of the classes and their interrelationships.
during any other activity. For this reason, the three volumes of this work include more patterns that apply to object oriented design than to any other activity.
Coding
The purpose of this activity is to write the code that makes the software work.
Testing
The purpose of this phase is to ensure that the software performs as expected. The artifacts of the development process are simplified and abbreviated. The details of deriving those artifacts are also abbreviated. The point of this case study is to illustrate the use of the different types of patterns that are covered in this volume.
Business Case
Here is an abbreviated business case that lays out the motivation and schedule for building an employee timekeeping system. Henry's Food Market operates five retail stores. To support these stores, it also operates a warehouse and a commercial bakery that produces the baked goods that the stores sell. Most of its employees are paid by the hour. A time clock system tracks employee hours. When employees begin work, go on break, return from a break, or leave work, they are supposed to slide their employee badges through a timekeeping clock that records their hours. Henry's Food Market wants to expand, increasing the number of its stores from 5 to 21 over the next 2 years at a rate of 2 stores every 3 months. One of the challenges the company faces is that if it continues to use the existing timekeeping system, it will have to hire more people to handle the administrative side of timekeeping. Currently, each location requires a person working half-time as a timekeeper to administer its timekeeping system. The activities the timekeeper is required to perform are as follows:
The timekeeper prints reports for supervisors that show the number of hours each employee worked the previous day. This allows supervisors to verify that their subordinates worked the stated number of hours. Some common errors that are uncovered by supervisors who review these reports are:
- Employees do not clock out when they go on break or leave work.
- Coworkers clock in employees who are late for work.
- Employees clock in before the start of their shift.
- The timekeeper enters corrections into the timekeeping system.
- The timekeeper prepares weekly reports that show the number of hours every employee in a location worked and sends those reports to the payroll department.
of a printed report. There is currently one person working full-time to enter employee hours into the payroll system and review the entered hours. This person costs the company $24,000 a year. If the company continues to use this system, it will have to hire an additional person to enter employee hours at an additional cost of $24,000 a year. The cost of having a person working half-time as a timekeeper in each location is $9,000 per person per year. The current cost of paying people to be timekeepers is $63,000 per year. The total current cost of labor for timekeeping is $87,000 per year. In two years, when the company's expansion is complete, that labor cost will have increased to $237,000. The proposed project is to build a replacement timekeeping system that will keep the labor cost of timekeeping at cur-rent or lower levels after the expansion. The timekeeping system will be expected to pay for itself in 18 months. Deployment of the system is expected within six months of the start of the project. . . .
Read More
