Enable JavaScript.

Rotten Applets AntiPattern

Just as a Pattern is a model for an arrangement of parts and a correct way of doing something, an AntiPattern tells you what to avoid. When I read a book on AntiPatterns1 for software development in 2002, I was working on a very large telecommunications project that consisted of a suite of small application programs, called applets, that each interacted with a central relational database. What I experienced as a programmer of an applet inspired me to write this AntiPattern. I had fun writing it, but the project was too far along to benefit from my insights. Besides, the project leaders weren't too happy with them.

Definition of a Rotten Applet

AntiPattern Name:
  • Rotten Applets - This name was chosen to convey the condition of a piece of fruit (an application system) after it has been attacked by patches of fungus (applets) and is well on its way to total decay. Just as a few rotten apples can spoil a whole barrel, so too can rotten applets spoil a whole application system.
Also Known As:
  • Client/Server - one of the many silver bullets that have plagued the software industry.
  • Stovepipe Systems. While all of the applets share a common database, each is a stovepipe, implemented for a single function and with a deliberate lack of coordination among them.
Most Applicable Scale:
  • Application. This AntiPattern describes applications whose basic architecture consists of a central database hard-wired to a set of applets (small independent applications with graphical user interfaces).
  • System. When multiple applications are developed with the same database, each a set of applets, the scale of the architecture extends to the system level, with correspondingly more severe consequences.
  • Enterprise. Ambitious attempts to model "the whole enterprise" can raise this AntiPattern to the enterprise level, with increasingly disasterous results.
Refactored Solution Name:
  • Layered Software Architecture. This AntiPattern attempts to apply a simplistic architecture to complex software design and development problems. The refactored solution is to design applications with separate, independent layers for the user interface, domain model, and persistence.
  • Domain Modeling. The domain model is the most important layer because all design decisions are governed by its classes, their states, relationships, behaviors and constraints. All applets that affect the domain should use the same domain object models (or identical copies of it).
Refactored Solution Type:
  • Software. This AntiPattern is about the creation and maintenance of software systems.
Root Causes:
  • Haste. Someone thinks they can take short-cuts and build systems quickly and cheaply. Unfortunately, this is encouraged by tool vendors who provide frameworks that wire GUI widgets directly to relational databases, without intervening domain object models, to show how "productive" their tools are. This is perhaps good marketing, but it is not good design.
  • Narrow-mindedness. Analysts trained only in EAR modeling and relational database technology fall prey to the Golden Hammer AntiPattern. To them, everything is an entity with attributes and relationships; business rules and processes are not considered.
Unbalanced Forces:
  • Management of complexity. This AntiPattern is an attempt to ignore complexity by adopting a deceptively simple architecture. As some seer once said, "For every complex problem, there is a solution that is simple, neat, and WRONG!"
  • Management of change. The life-cycle of a software system must include the long term, which is generally more expensive than initial development. The Rotten Applets AntiPattern ignores long term issues in favor of producing quick solutions to immediate business problems.
Anecdotal Evidence:
  • "Just build a GUI version of this form and use the information from it to update the database."
  • "If we can only get the database schema right, then everything else will be easy."

Background

In the Rotten Applets AntiPattern, a software system is developed as a set of applets (small applications), each of which supports a specific set of users. At the center is a relational database of interrelated tables that can be freely accessed and updated by each of the applets, and by ad-hoc users.

 

This architecture has certain advantages:

  • It alows the business to be modeled independently of the development of the applets. None of the messy aspects of programming, such as performance, maintenance and quality, need be considered.
  • The applets can be developed independently of each other. Small applets can be assigned to individual programmers, often with only minimum specifications; for example, "Just duplicate this form in a window and update the database."
  • The applets can be developed in parallel. This makes for very fast initial developments, especially of the initial set of applets, and that always impresses management.
  • The applets can be developed with a minimum of effort wasted on such things as user involvement, meetings, e-mail, specifications, reviews, documentation, or formal testing - a great time saver.
  • Standard query languages (i.e., SQL) can be used to perform ad-hoc queries and generate on-the-spot reports, bypassing the limitations imposed by applets written for less computer-literate users.

 

This architecture also has certain disadvantages:

  • Designing the database schema as a first step can lead to the Analysis Paralysis AntiPattern. In a large, dynamic organization, the schema is never complete. Changes are required as business realities change, and as knowledge of the business increases. In one case, business analysts developed a complex Enty/Attribute/Relationship (EAR) model consisting of several hundred tables. After more than a year, management became desperate to deploy badly needed applications, and accepted the simplistic solutions proposed by a database guru and his disciples.
  • Small, functionally-oriented applets can be rapidly developed against a central database, but they can only be as good as the analysis that created the database schema. In the preceeding example, applets were written, but rejected by their intended users because some necesary information was missing. The analysts had examined all of the forms used by the existing semi-manual system, but they failed to notice a hidden form that was rubber-stamped on the back of one of the official forms. This information was used to determine how the form was handled. Just examining the data artifacts of existing systems is not enough; how those artifacts are used is equally important.
  • The applets can have hidden dependencies through the database. One applet modifies tables that other applets access. When it is necessary to modify an applet, it is also necessary to determine and modify all other applets with which it may interact. As the number of applets grows, the number of interactions among them grows exponentially, and this makes long-term maintenance of the total system increasingly difficult. The database is essentially a collection of global variables; never a very good programming practice.
  • The applets also have hidden dependencies on each other. For example, if a set of applets each handle a single stage of a workflow process, each for a separate group of functional users, then the applets are actually nodes of a Finite State Machine. Transitions among the states must be handled correctly by each applet, based on knowledge of the overall workflow system. Recognition of the applets as state nodes may come about only when all applets have been completed and users complain that they are not able to easily change states.
  • Applets are often modal; that is, a user can be using only one applet at a time, and has only a limited view of the overall system. Users must navigate among applets, selecting the correct applet for each function to be performed. Ironically, this is completely out of phase with the database schema, which models relationships among entities. A better design is to eliminate this mismatch by allowing users to navigate among entities (at an appropriate level of abstraction), performing various operations on them as they go.
  • Beyond the limited integrity constraints supported by the DBMS, each applet must fully implement all necessary business rules, and the rules must be consistently enforced by all applets. This is very difficult to achieve when many applets are being developed concurrently, and it becomes virtually impossible, over time, as applets are modified. The use of stored procedures and triggers in the database can be a help, but they are often so hidden as to be forgotten elements of the system.

Symptoms and Consequences

  • A single, complex, and highly normalized database schema designed prior to the development of any of the applets.
  • A large number of small applets developed independently and intended to independently interact with the database.
  • A lack of consideration for the long-term maintenance and evolution of the overall system.
  • Functionally oriented, modal applets that control how the user interacts with the system. Applets with deeply nested dialogs are a key symptom.

Typical Causes

  • Data modeling instead of domain object modeling.
  • The analysts responsible for determining business requirements have used EAR methods, and focused on "what not how" because that is how they were trained and because EAR methods do not consider "how" (process) issues.
  • Lack of an Domain Object Model (DOM). While the applets may be written in a object-oriented language, their dependence on the non-object-oriented database schema forces the applets into a fundamentally procedural orientation. An intervening DOM is required to overcome this problem.
    "The domain layer is the program, and any other code in the system should border on the trivial. If you don’t have it that way, then you probably haven’t completely separated the domain layer from the rest of the system."2
  • Management panic. Desperate project managers and inexperienced architects fail to consider the long term implications of multiple applets interacting with each other and with a common database.
  • Bad advice from expensive database gurus. Experts in a particular technology often attempt to solve all problems using that technology (the Golden Hammer AntiPattern), and do so with great authority.

Known Exceptions

The Rotten Applets AntiPattern is appropriate only when quick, short-lived applications, based on data in an existing database, are required to solve immediate business problems. The danger, of course, is that such quickies tend to go into production.

Refactored Solutions

  • Fire the database guru and data modelers and hire object modelers in their place (or retrain the data modelers, if that is at all possible). A domain model must accommodate domain processes, as well as their attributes and relationships.
  • Use the Layers pattern [Buschmann, 1996] to separate the application into independent layers that each deal with a major aspect of the application, such as user interface, domain model and persistence.
  • Consolidate all business information, rules and processes in a single domain model that is used by all applets. This can be done using a 2-tier or a 3-tier connectivity architecture. Do not allow applets to access the database directly.
  • Reorient the way users interface with the application from functional navigation to object navigation.

Variations

Even when a domain object model (DOM) has been designed, it is still possible to fall into the Rotten Applets AntiPattern:

  • There is a tendency for object modelers to assume that getting the DOM right is all that matters, and that building applets for users is a trivial follow-on. These are essentially the same attitudes shown by data modelers. Designing and building appropriate Graphical User Interface (GUI) applets can be quite difficult. In some cases, additional support classes are required for implementation considerations not considered by the DOM. The GUI applets should be inspected for business logic, and that logic moved to the DOM.
  • A GUI orientation to system design can also lead to this AntiPattern. In this case, the system is functionally designed around the tasks that users need to perform. The DOM is primarily derived from the requirements of GUI applets. Business rules are added to the DOM as needed by the applets, and do not necessarily reflect the needs of the business. Coordination among the applets and the DOM is haphazzard, often with no clear owner of the DOM classes. Here also, business logic tends to accumulate in individual applet classes, instead of in the DOM.

A well designed architecture includes a Domain Object Model that accommodates business requirements, user interface requirements and persistence requirements.

References

  1. Brown,W. J., Malveau, R.P., McCormick, H. W., Mowbray, T. J., AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis,. John Wiley & Sons, 1998. AntiPatterns are by their nature somewhat negative and pejorative in tone. Their purpose is to call out practices and designs that often lead to failure, so that corrective or preventative measures can be taken. Design patterns help us to do things right; AntiPatterns help us to avoid doing things wrong!
  2. Pratt, Nevin, Separate Domain From Presentation, Smalltalk Chronicles.net, Volume 3, Number 2, August 2001. This article provides specific reasons for a domain model separate from presentation logic.

Les pourris microprogrammes AntiModèle

 

De la même manière qu'un "Pattern" disez-vous le bon moyen de faire quelque-chose, un "AntiPattern" dit ce que vous devez éviter.


>Désolé, pas encore traduit.