EMTM 600 Software Development

1
EMTM 600Software Development

• Spring 2007
• Lecture Notes 1

2
Website http//www.cis.upenn.edu/val/EMTM60
0Assignments for next time

• Read the handout Anchor Machinery Case Study.
  Then, from Elements of a Case Study used in EMTM
  600 in 2006 read about the actors, the use cases
  and the domain model. Based on these readings,
  write a critique of the description of the use
  cases and of the domain model design. Suggest
  improvements or extensions. About 1.5 pages long.
  Groups of 3-4 students OK.
• Read the portion of Lecture Notes 1 not discussed
  in class, especially the slides about
  antipatterns. Write a half-page description of
  another antipattern, ideally based on your
  experience. Groups of 3-4 students OK.
• Read chapter 2 of the textbook. Two days before
  the next lecture email me ONE QUESTION about
  something you didnt understand. Each student.

3
Bibliography

• Core J2EE patterns
  
  by Alur et al., Prentice Hall 2003.
  Our
  textbook.
• Patterns of enterprise application architecture
  by Fowler,
  Addison Wesley 2003.
  More
  general than Java EE, begins with a very good
  discussion.
• Enterprise Java Programming with IBM WebSphere,
  second edition, by Brown, K. et. al., Addison
  Wesley 2003.
  Very thorough, good discussions, but totally
  WebSphere-specialized.
• Enterprise integration patterns
  
  by HohpeWoolf, AddisonWesley 2004.About
  messaging solutions. Complements our course to
  some extent.

4
Bibliography

• Design patterns
  
  by Gamma et al., Addison
  Wesley 1995. Classic. But not the clearest.
• Pattern-oriented software architecture a system
  of patterns by
  Buschman et al., Wiley 1996.One of the best on
  software design patterns.
• Refactoringby Fowler et al., Addison Wesley
  1999.Excellent for the developer. Force your
  programmers to read it!
• AntiPatterns Refactoring Software,
  Architectures, and Projects in Crisis
  
  by Brown, W. et
  al., Wiley 2001.
  Fun and excellent
  as a management companion.
• Software testing in the real world
  
  by Kit, ACM Press/Addison-Wesley 1995.
  Not a topic in
  this course but excellent.

5
Enterprise Applications

• Most software development are spend on
  enterprise applications.
• Definition (M. Fowler) they focus on the
  display, manipulation, and storage of large
  amounts of (often complex) data and support the
  automation of business processes with that data.
• Examples Customer Relationship Management,
  Supply Chain Management, Sales Force Automation,
  Enterprise Resource Planning, reservation
  systems, etc.

6
Enterprise Applications, contd

• Technological challenges
• Lots (gt1GB) of persistent data
• Accessed concurrently
• Lots (dozens) of user interface screens
• Integration with other enterprise applications
• Scalability
• Security
• Business challenges
• Inconsistencies among business concepts and
  processes
• Capturing the business logic
• Speed-to-market
• Acceptance

7
Enterprise Applications, contd

• Solutions
• Mainframe era CICS-like systems
• Client-server era CORBA/C (late 80s---gt
  present??)
• CORBA/Java (mid
  90s---gt present?)
• Web/server-side era Java EE (late
  90s---gtpresent)
• .NET (early
  00s---gtpresent)
• Important remark
• CORBA, J2EE, .NET are all component
  frameworks

8
Various Definitions of Component

• 1. "A component is a nontrivial, 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 realization of a set
  of interfaces." (PhilippeKrutchen?,
  RationalSoftware?)
• 2. "A runtime software component is a
  dynamically bindable package of one or more
  programs managed as a unit and accessed through
  documented interfaces that can be discovered at
  runtime." (GartnerGroup?)
• 3. "A software component is a unit of
  composition with contextually specified
  interfaces and explicit context dependencies
  only. A software component can be deployed
  independently and is subject to third-party
  composition." (Clemens Szyperski,
  ComponentSoftware)
• 4. "A business component represents the software
  implementation of an autonomous business concept
  or business process. It consists of the software
  artifacts necessary to express, implement, and
  deploy the concept as a reusable element of a
  larger business system." (WojtekKozaczynski?,
  SSA)

From the Portland Pattern Repository
9
More Definitions of Component

• 5. "A component is a unit of distributed
  program structure that encapsulates reuse by
  decoupling components from their operating
  environment." (Steve Crane. See
  http//www-dse.doc.ic.ac.uk/np2/pubs.html)
• 6. "A component is an object in a tuxedo. That
  is, a piece of software that is dressed to go out
  and interact with the world." -- MichaelFeathers
• 7. "Software components enable practical
  reuse of software parts and amortization of
  investments over multiple applications. There are
  other units of reuse, such as source code
  libraries, design, or architectures. Therefore,
  to be specific, software components are binary
  units of independent production, acquisition, and
  deployment that interact to form a functioning
  system." (Clemens Szyperski, ComponentSoftware
  Preface)

From the Portland Pattern Repository
10
Even More Definitions of Component

• 8. "A component is a physical and replaceable
  part of a system that conforms to and provides
  the realization of a set of interfaces...typically
  represents the physical packaging of otherwise
  logical elements, such as classes, interfaces,
  and collaborations." (GradyBooch, JimRumbaugh,
  IvarJacobson, The UML User Guide, p. 343)
• 9. "Components are self-contained instances of
  abstract data types (ADTs) that can be plugged
  together to form complete applications."
  (DougSchmidt, How to Make Software Reuse Work for
  You, Jan. 1999 C Report, p. 51)

From the Portland Pattern Repository
11
I asked EMTM 600 students which one they prefer!

• The students liked the following definitions
• 4 - 3 votes
• 8 - 2.5 votes
• 7 - 1.5 votes
• 6 and 2 - 1 vote each
  Which one do YOU prefer?
• 
  Email me!
• The explanation for the half-votes is that
  Rama Pothineni liked half of 7 and half of 8,
  thus producing the following
• A component is a physical and
  replaceable part of a system that conforms to and
  provides the realization of a set of interfaces.
  It typically represents the physical packaging of
  otherwise logical elements, such as classes,
  interfaces, and collaborations. To be specific,
  software components are binary units of
  independent production, acquisition, and
  deployment that interact to form a functioning
  system

12
Favorite definitions for Component

• Sankaran Namboodiri liked 7 but found a related
  definition by Bachmann in an article at
  http//www.sei.cmu.edu
• A component is (1) an opaque
  implementation of known! functionality, (2)
  subject to third-party composition, and (3)
  conformant with a component model such as Java
  EE!.
• Charles Snyder preferred to formulate his own
• A system is an assemblage of related
  subsystems, components and elements, which work
  together to enable the flow of information. A
  system can be defined as any assemblage which
  accepts an input, processes it, and produces and
  output. Starting at the lowest building block
  level, an element is a self contained package of
  code whose size and complexity is arbitrary. The
  only constraint is that is serves no real
  function in isolation. A component is an
  assemblage of elements that are assembled such
  that they do serve a specific, well defined
  function within the system. Components are
  defined not only by the elements that the
  component comprises, but by the characteristics
  of the component at their interfaces. Components
  are assembled into a system, such that the system
  serves a well defined business need.
• Simon Storm found his favorite definition at
  www.sabc.co.za/manual/ibm/9agloss.htm
• A reusable object or program that
  performs a specific function and is designed to
  work with other components and applications.

13
From the Portland Pattern Repository
Component Framework

• A component framework defines a set of abstract
  interactions that define the protocols by which
  components cooperate -- each component takes on
  roles in various abstract interactions.
• The component framework also defines the
  packaging for components so that they can be
  instantiated and composed into legal
  configurations.
• To help framework users, a component framework
  provides prebuilt functionality, such as useful
  components or automated assembly functions that
  automatically instantiate and compose components
  to perform common tasks.

14
Are Components Reusable?

• The short answer is YES! But its a
  question of degree.
• Coxs Pipe Dream In 1986, Brad Cox
  argued that software objects could be produced
  like integrated circuits out of components. (And
  thus capture the benefits of Moore's law - the
  number of components on a silicon integrated chip
  doubles every year.)
• Obviously, its not the same kind of
  component! An IC component has much simpler (and
  easier to specify in excruciating detail)
  interfaces than a software component. But there
  is a similarity the key to reuse is modularity
  through well-defined interfaces

Component B1
Component A1
or
or
swap (different versions)
swap (different vendors)
interface
Component B2
Component A2
15
Reusability in component frameworks

• Component frameworks such as Java EE
  promote more reuse because they are structured
  around many OO interfaces. This is primarily
  horizontal reuse (i.e. across applications)
• Several applications can share
• The same Web server (eg., MS IIS, Apache,
  Tomcat)
• The same RDBMS (relational database management
  system) (eg,
  Oracle, DB2, SQL Server)
• The same Java EE server (eg., JBoss, Orion,
  IBM WebSphere, BEA WebLogic, SAP Java EE Engine,
  Oracle JDeveloper)
• The same ORB (object request broker) (eg.,
  IONA Orbix, Borland VisiBroker)
• The same transaction processing monitor (eg.,
  BEA Tuxedo, IBM CICS)
• The same messaging system (eg., Sun ONE MQ)
• This works provided the applications are
  vendor-neutralized through the use of the
  component framework interfaces (eg., the ones
  used with Java EE JDBC, J2C, JTA, JMS, Java IDL,
  etc. More about JAS (the Java Alphabet Soup)
  later!!
• Vertical reuse within an application harder to
  achieve, but domain beans help!

16
A third kind of reusability?
J2EE App Server Vendor UU

Web Server Vendor ABC

Edge Network Dispatcher Vendor QQ
Web Server Vendor XYZ
J2EE App Server Vendor VV
Purpose load-balancing
17
A component framework
Java Enterprise Edition

• Open specification, open architecture!
• A combination of design patterns architectural
  and more detailed
• Layers
• Model-view-controller
• Proxy
• Adapter, etc
• An end-to-end philosophy
• User interfaces
• Business logic
• Interfaces to EIS (Enterprise Information
  Systems)
• Concern with EAI (Enterprise Application
  Integration)
• Concern with performance
• High availability
• Security
• Reliability
• Scalabiliy

18
Java EE Architecture three (or five!)

tiers ( or layers)
Brown et.al.
Alur et al./Fowler
Presentation


Presentation

Controller/Mediator

Domain

Business/Domain

Data Mapping


Integration/ Data Source

Data Source

19
Five Layers

• Presentation Layer
• Takes care of user interfaces user input
  and output. Typically uses Web browsers and HTML.
  More recently XML/XSLT. Most recently Ajax. All
  this content is typically dynamic, organized in
  server pages (JSP). Alternatives are
  browser-delivered applets or a client-side
  application with its own GUI.
• Controller/Mediator Layer
• Centralized points for handling
  presentation navigation. Separates presentation
  flow from the domain objects. Typically
  implemented as servlets.
• Domain Layer
• Defines and manipulates objects that
  capture the business logic or business
  abstractions. Can be implemented through session
  EJBs or just plain objects. Key to the robustness
  of the implementation (think changes!)

20
Five Layers, contd

• Data Mapping (aka Persistence) Layer
• Separates the domain layer from details of
  the data sources where the data is, what needs
  to be made persistent, where and how. Can be
  implemented through entity EJBs.
• Data Source Layer
• Access to EIS, often RDBMS but sometimes
  legacy. Uses J2EE standards such as JDBC for
  relational sources, JMS for asynchronous access
  to sources with messaging capabilities, and J2C
  (Connector) for synchronous access when
  available. More recently, in the context of
  Enterprise Application Integration (EAI) and
  Service Oriented Architectures (SOA), this layer
  also handles access to external Web Services.
• This five-layer organization is an architectural
  pattern. Design Patterns are everywhere in Java
  EE applications!

21
Where do the layers run?
Java EE application server
Web server
data source
presentation
data mapping
controller
domain
Eg.,
Eg.,
Eg.,
Eg.,
Eg.,
Session EJBs
Entity EJBs
Servlets
JSP
JDBC
browser
DB
22
Software Design Patterns

• Patterns address recurring design problems that
  arise in specific situations. They document
  existing, well-proven design experience.
• Patterns provide a common vocabulary and
  understanding for design principles.
• Patterns are a means of documenting software
  architectures (even better if it is done by using
  some precise notations such as UML (Universal
  Modeling Language)

23
Design Patterns (contd)

• Patterns help with construction of software with
  defined properties, satisfying well-understood
  requirements.
• They help conquer complexity and heterogeneity.
• Aspects of a pattern
• Context
• Problem
• Solution

From Pattern-oriented software architecture by
Buschmann et al., Wiley 1996
24
Links for Design Patterns

• Portland Pattern Repository
  http//c2.com/ppr/
• Hosted by Cunningham Cunningham Inc.
• Maintained by Ward Cunningham (of XP fame), part
  of Wards Wiki.
• Patterns Home Page http//hillside.net/pattern
  s/
• Hosted by The Hillside Group

25
Examples(1)
From Design patterns by Gamma et al.,
AddisonWesley 1995

• Creational Patterns
• Abstract Factory Provide an interface for
  creating families of related or dependent
  objects without specifying their concrete
  classes.
• Builder Separate the construction of a complex
  object from its representation so that the same
  construction process can create
• different representations.
• Factory Method Define an interface for creating
  an object, but let subclasses decide which class
  to instantiate.
• Prototype Specify the kinds of objects to create
  using a prototypical instance, and create new
  objects by copying this prototype.
• Singleton Ensure a class only has one instance,
  and provide a global
• point of access to it.

26
Examples(2)
From Design patterns by Gamma et al.,
AddisonWesley 1995

• Structural Patterns
• Adapter Convert the interface of a class into
  another interface
• clients expect. Adapter lets classes work
  together that couldn't otherwise because of
  incompatible interfaces.
• Bridge Decouple an abstraction from its
  implementation so that the
• two can vary independently.
• Composite Compose objects into tree structures to
  represent
• part-whole hierarchies. Composite lets
  clients treat individual objects
• and compositions of objects uniformly.
• Decorator Attach additional responsibilities to
  an object dynamically. Decorators provide a
  flexible alternative to subclassing for
• extending functionality.

27
Examples(3)
From Design patterns by Gamma et al.,
AddisonWesley 1995

• Structural Patterns (contd)
• Facade Provide a unified interface to a set of
  interfaces in a
• subsystem. Facade defines a higher-level
  interface that makes the
• subsystem easier to use.
• Flyweight Use sharing to support large numbers of
  fine-grained
• objects efficiently.
• Proxy Provide a surrogate or placeholder for
  another object to
• control access to it.

28
Examples(4)
From Design patterns by Gamma et al.,
AddisonWesley 1995

• Behavioral Patterns
• Chain of Responsibility Avoid coupling the
  sender of a request to its receiver by giving
  more than one object a chance to handle the
  request. Chain the receiving objects and pass
  the request along the chain until an object
  handles it.
• Command Encapsulate a request as an object,
  thereby letting you parameterize clients with
  different requests, queue or log requests, and
  support undoable operations.
• Interpreter Given a language, define a
  representation for its grammar along with an
  interpreter that uses the representation to
  interpret sentences in the language.
• Iterator Provide a way to access the elements of
  an aggregate object sequentially without exposing
  its underlying representation.

29
Examples(5)
From Design patterns by Gamma et al.,
AddisonWesley 1995

• Behavioral Patterns (contd)
• Mediator Define an object that encapsulates how a
  set of objects interact. Mediator promotes loose
  coupling by keeping objects from referring to
  each other explicitly, and it lets you vary their
  interaction independently.
• Memento Without violating encapsulation, capture
  and externalize an object's internal state so
  that the object can be restored to this state
  later.
• Observer Define a one-to-many dependency between
  objects so that when one object changes state,
  all its dependents are notified and updated
  automatically.
• State Allow an object to alter its behavior when
  its internal state changes. The object will
  appear to change its class.

30
Examples(6)
From Design patterns by Gamma et al.,
AddisonWesley 1995

• Behavioral Patterns (contd)
• Strategy Define a family of algorithms,
  encapsulate each one, and make them
  interchangeable. Strategy lets the algorithm
  vary independently from clients that use it.
• Template Method Define the skeleton of an
  algorithm in an operation, deferring some steps
  to subclasses. Template Method lets subclasses
  redefine certain steps of an algorithm without
  changing the algorithm's structure.
• Visitor Represent an operation to be performed on
  the elements of an object structure. Visitor
  lets you define a new operation without changing
  the classes of the elements on which it operates.

31
Example Abstract Factory

• This is a creational pattern. We used this idea
  with the ListSpec
• interface for mutable lists.
• Context Working with multiple standards.
• Problem To provide an interface for creating
  families of related or dependent objects without
  specifying their concrete classes.
• Solution Group creation methods in an abstract
  factory class (in Java probably an abstract class
  or an interface). Extend/implement this with
  concrete classes that follow each standard. Write
  generic code using the abstract factory methods
  to create needed objects. This code could also be
  in abstract classes, leaving abstract the use of
  the factory. Then specialize this code for a
  specific standard by implementing the factory
  with a concrete factory.

32
Example Adapter

• This is a structural pattern. It is also called
  Wrapper (the Java
• wrapper classes are adapters for the primitive
  types). We can use
• it, for example, to implement stacks, queues and
  even priority
• queues (as we did!) using ranked sequences.
• Context Many!
• Problem Classes that need to work together
  cannot because of incompatible interfaces.
  Therefore we need to convert the interface of a
  class into another interface clients expect.
• Solution We can make the adaptee a subclass of
  the target (as we did with priority queues and
  ranked sequences) but some do not consider this
  good design. Instead they recommend that the
  adaptee have a private field refering to a target
  object (more like wrapping).

33
Example Iterator

• This is a behavioral pattern. The Java
  Enumeration is an
• approximate example (the methods are a little
  different).
• Context Working with collections of objects.
• Problem Access the objects in a collection
  sequentially without exposing the underlying
  representation of the collection.
• Solution We build the iterators as objects
  associated with the collections, having access to
  their representation. (In Java this suggest
  strongly using inner classes.) The state of an
  iterator is given by a cursor referring to the
  current element of the collection. Iterators
  should have an advance method, a method to access
  the current element, a method to test if the
  whole collection was traversed, and a method to
  restart the traversal. Multiple iterators on the
  same collection are useful. Also useful is
  starting an iterator at some element referred to
  by another iterator.

34
Mutable Lists as an Abstract Factory
public interface ListSpec // Example of
Abstract Factory. List nil()
// Methods that create
products. List sng(Object o)
// In general, the products are of List
list(Object ao) // various kinds
(here all are lists). public interface List
// Interface for Abstract Product.
void addHead(Object o) boolean
isEmpty() Object head() throws
EmptyListException void removeHead() throws
EmptyListException void appendTail(List l)
Iterator iter() //
See Iterator interface.
35
Mutable lists implementation
class LLImpl implements ListSpec static
class Cell static class LinkedList
implements List
// Iterator implementation in
here. See next. public List nil()
public List sng(Object o)
public List list(Object ao)
List rl nil() for (int iao.length-1
igt-1 i--) rl.addHead(aoi)
return rl
36
Iterator specification

public interface Iterator // Example of
Iterator design pattern. boolean hasMore()
// No insert
void next()
// or delete methods. Object
current() void reset()
// Restart at beginning. Iterator
spawn() // Create new iterator,
// initialize it at
same current element.

37
Iterator use

public String toString() // Overriding method
in Object. Iterator i iter()
StringBuffer sb new StringBuffer()
sb.append("\n ") while (i.hasMore())
sb.append(i.current() " ") i.next()
sb.append("") return sb.toString()

This is unrelated, but interesting! Inside class
LinkedList.
38
Iterator implementation

// Inside the class LinkedList (which
implements List). class Iter implements
Iterator // Inner class. Instances tied to
Cell cursor
// enclosing linked list instance.
Iter () cursor first public boolean
hasMore() return (cursor ! null) public
void next() cursor cursor.next public
Object current() return cursor.content
public void reset() cursor first
public Iterator spawn() Iter i new
Iter() i.cursor cursor return i
... public Iterator iter() return new
Iter() // Class LinkedList continues.
39
Adapter implementation

public class ListStack implements Stack
// Example of Adapter design
pattern. private List theList //
Here we wrap a list. public
ListStack(ListSpec I) theList I.nil()
public
void push(Object o) theList.addHead(o)
public void pop() throws EmptyStackException
try theList.removeHead() catch
(EmptyListException e) throw new
EmptyStackException()
We could have also used inheritance.
40
AntiPatterns and Refactoring

• A reaction to the hype over design patterns.
• AntiPatterns identify common mistakes in software
  development mistakes in architectural design,
  detailed design/coding practice, and even process
  management (this not covered by design patterns!)
• AntiPatterns also provide refactoring solutions
  (fixing the mistakes!).
• Refactoring should improve the design and hence
• the reliability,
• the maintainability,
• in the longer term the productivity

41
Aspects of an AntiPattern

• Recall aspects of Design Patterns Context,
  Problem, Solution
• AntiPattern aspects
• Context and Causes
• AntiPattern (bad!) Solution
• Symptoms and Consequences
• Refactored Solution

42
Key Concepts for AntiPatterns

• Root Causes (a.k.a the seven software development
  sins)
• haste apathy narrow-mindedness
  sloth
• avarice ignorance
  pride.
• Primal Forces, eg.,
• meeting the user requirements
• achieving reasonable performance
• defining abstractions/managing complexity
• managing change/controlling evolution
• managing IT resources
• managing the transfer of technology

43
Key Concepts, contd

• Software Design (and Process) Levels
• Global/Industry standards, Internet
• Enterprise infrastructures, policies, reference
  models (local standards)
• System interacting applications, metadata
  (schemas, ontologies)
• Application requirements, interfaces, GUIs
• Macro-component/frameworks (optional) eg., EJB,
  .NET, design patterns
• Component reusability, detailed design patterns
• ObjectsClasses detailed functionality

44
Examples
From AntiPatterns by Brown et al., Wiley 1998

• Management AntiPatterns
• Analysis Paralysis Not knowing when to stop
  worrying about details
• Death by Planning Cant get started until
  complete project plan
• Smoke and Mirrors (Vaporware) Demo system is
  used by sales to make impossible claims and
  promises...
• Intellectual Violence You dont know Lambda
  Calculus?!?
• Viewgraph Engineering Making your Java
  programmers spend too much time on Powerpoint...
• Blowhard Jamboree The expert said But the guru
  may be misinformed or biased...

45
Example Stovepipe Enterprise
From AntiPatterns by Brown et al., Wiley 1998

• This is a software architecture antipattern.
• Context and causes Multiple systems within an
  enterprise, designed independently lack of
  standard reference model lack of incentive for
  cooperation across development groups. Root
  causes haste, apathy, narrow-mindedness.
  Unbalanced primal forces change, IT resources,
  and technology transfer management.
• Antipattern solution Ad-hoc enterprise-level
  architecture.
• Symptoms and Consequences Metal stovepipe
  constantly corroded by wood fumes, constantly
  patched with improvised materials.
• Bad interoperability between systems
  incompatible terminology and approaches.
• Undocumented or incomprehensible architectures.
• Incorrect use of a technology standard.
• Excessive maintenance costs when requirements
  change.
• Employee turnover.

46
Stovepipe Enterprise, contd

• Refactored Solution Enterprise Architecture
  Planning
• Coordination of technologies at several levels
• Ruless in the spirit of building codesand
  zoning laws.
• Common infrastructure of basic services
• Dept/division infrastructure of value-added
  functional services
• For very large enterprises it is becomes
  worthwhile to add
• Open systems reference models (one/enterprise)
• Technology profile (one/enterprise )
• Operating environment (one/enterprise)
• System requirements profile (one/system family)
• Computing facilities architecture (one/system
  family)
• Interoperability specifications (one/key
  interoperability point)
• Development profile (one/system family)

47
Example The Blob
From AntiPatterns by Brown et al., Wiley 1998

• This is a detailed design antipattern.
• Context and causes Many contexts, especially
  with inexperienced programmers, or when non-OO
  legacy design is migrated into OO. Root causes
  sloth, haste, ignorance. Unbalanced primal
  forces meeting user requirements, achieving
  performance, managing complexity and abstraction.
  
• Antipattern solution One part of a component
  (typically a single class) monopolizes the
  processing while the rest just encapsulates data.
• Symptoms and Consequences
• Single class with too many attributes and/or
  operations.
• Unrelated attributes and/or operations in the
  same class.
• Operations with too many parameters and lost of
  code, typically involving many condition tests.
• This is against the spirit of OO design and
  coding.
• Blob classes are too complex for reuse.
• Blob classes are too complex for reliable testing!

48
The Blob, contd

• Refactored Solution Refactoring of UML diagrams
  and code to move behavior away from the blob.
• Identify attributes and operations that are
  related according to functionalities in a more
  abstract view, or in use cases.
• Look for natural homes for groups of related
  attributes and operations. Create new classes if
  necessary.
• Identify unrelated functionality in the behavior
  of each operation. Break-up operations by
  creating auxilliary one in their natural homes.
• Eliminate transient object or variables
  (temporary variables), especially if they
  communicate data within a large operation.

49
Example Poltergeists
From AntiPatterns by Brown et al., Wiley 1998

• This is a detailed design antipattern.
• Context and causes Many contexts, especially
  with large group efforts, also when architects do
  not understand object-orientation. Root causes
  sloth, ignorance, pride. Unbalanced primal
  forces meeting user requirements, managing
  complexity and abstraction.
• Antipattern solution Components or classes with
  limited responsibilities, are made visible
  outside of their useful scope and beyond their
  useful life.
• Symptoms and Consequences
• Cluttered design.
• Poltergeists are hard to understand out of their
  useful context, leads to mistaken use,
  difficulties in maintenance.
• Stateless classes, used just for control.
• Single-operation classes.
• Refactored Solution Remove them! Replace the
  functionality they provided by modifiying/adding
  appropriate operations.

50
The Java Landscape

• Reference implementations freely available from
  Sun
• Platform independence
• Open specifications for powerful extensions like
  EE
• These have made Java the top choice of the open
  source communities!
• Java is the environment of the best plug-ins for
  IDEs (Integrated
  Development Environments) like
• Eclipse (a major player in open-source)
• Recently, Oracle donated the TopLink Java
  Persistence technology to Eclipse!
• NetBeans

51
Open Source Java Projects

• Several succesful and popular open-source
  projects from Apache (another major player in
  open-source) are Java-related
• Tomcat (Java servlet container for the Apache
  Web server)
• Struts (Java servlet implementation framework)
• Jakarta-Cactus (unit testing framework for
  servlets, EJBs etc)
• An open source implementation of Java EE called
  JBoss is now supported by Red Hat, the Linux
  distribution company. JBoss has sprouted
  Hibernate, an open source object-relational
  persistence and query service for Java.
• Another interesting open source implementation of
  Java EE is Spring, dubbed lightweight and
  supported by a company called Interface 21.
• (There are already TOO MANY open source choices
  )

52
The Inevitable

• In 2006, Sun has started two open source
  projects
• GlassFish, an open source development of a Java
  EE application server
• JDK 6, an open source release of Java SE
  (Standard Edition) 6 and an invitation to the
  form a contributing community
• Finally, Sun has stated that the whole Java SDK
  will become open source in Fall 2007 (more likely
  Spring 2008)!