EMTM 600
Software Development
Spring 2011
Lecture Notes 1
http://www.cis.upenn.edu/~val/EMTM600
Assignments for next time
•
Retrieve “EMTM 601 Anchor Machinery Case Study” and “EMTM 600 Case
Study based on Anchor Machinery” from the course web page
http://www.cis.upenn.edu/~val/EMTM600 From the second
document read about the actors and the use cases. Based on this
example, START DESIGNING YOUR OWN ENTERPRISE APPLICATION:
•
•
•
Give a 1p overview of the context and the need for your application
Give at least 4 use cases, each supported by a user story (3-10 sentences each)
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 from Fowler’s book, chapters 2, 4 and 6 as well as the patterns
“Domain Model” (pp.116-124) and “Model-View Controller” (pp.330-332).
Two days before the next lecture email me THREE QUESTIONS about
things you didn’t understand. Each student.
EMTM 600, Spring 2011
Val Tannen
Bibliography
Patterns of enterprise application architecture
by Fowler, Addison Wesley 2003.
We use it as a textbook, has some excellent discussions, it’s more
general than Java EE.
Core J2EE patterns
by Alur et al., Prentice Hall 2003.
Good outline of enterprise application patterns supported by Java EE.
Enterprise Java Programming with IBM WebSphere, second edition,
by Brown, K. et. al., Addison Wesley 2003.
Very thorough, good discussions, but totally WebSphere-specialized.
EMTM 600, Spring 2011
Val Tannen
Bibliography
Cloud computing and SOA convergence in your enterprise
by Linthicum, Addison Wesley 2009.
We use it as a textbook, my assumption is that cloud computing
solutions will become widespread.
SOA design patterns
by Erl, Prentice Hall 2009.
Collection of good experience with SOA solutions.
Enterprise integration patterns
by Hohpe & Woolf, Addison Wesley 2004.
About messaging solutions. Complements our course to some extent.
EMTM 600, Spring 2011
Val Tannen
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.
Refactoring
by 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.
EMTM 600, Spring 2011
Val Tannen
Bibliography
Planning Extreme Programming
by Beck & Fowler, Addison Wesley 2000.
Simple, clear, very useful also as a management companion.
Test-driven development: By example
by Beck, Addison Wesley 2002.
Also excellent for the developer. Force your programmers to read it!
Software testing in the real world
by Kit, ACM Press/Addison-Wesley 1995.
Not a topic in this course but excellent.
.NET & J2EE Interoperability
by Peltzer. McGraw-Hill 2004
Pretty lame, but the others on this topic are worse…
EMTM 600, Spring 2011
Val Tannen
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.
• Classification:
• Transactional
• Business Intelligence
• Business Planning
• Examples (with overlaps): Customer Relationship Management,
Supply Chain Management, Sales Force Automation, Enterprise
Resource Planning, Customer Profiling, Market Research, Product
Profitability, Inventory Analysis; uses of Data Mining and Machine
Learning, etc.
EMTM 600, Spring 2011
Val Tannen
Enterprise Applications, cont’d
Technological challenges:
•
•
•
•
•
•
Lots (>1GB) of persistent data
Accessed concurrently
Lots (at least 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
EMTM 600, Spring 2011
Val Tannen
Enterprise Applications, cont’d
Solutions
• Mainframe era: CICS-like systems
• Client-server era: CORBA/C++ (late 80’s---> present?)
CORBA/Java (mid 90’s---> present?)
• Web/server-side era:
Java solutions: Java EE, Spring, Hibernate,
(late 90’s--->present)
.NET (early 00’s--->present)
Ruby on Rails,
Python/Zope, Python/Django,
(PHP/mySQL?)
Important remark: CORBA, Java EE 5 (formerly J2EE), .NET are all
component frameworks
EMTM 600, Spring 2011
Val Tannen
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
(but Ruby on Rails and Python/Zope or Django want to change this!)
Java is the environment of the best plug-ins for IDEs
(Integrated Development Environments) like

Eclipse (a major player in open-source, lots of support from IBM)
•

Last year Oracle donated the TopLink Java Persistence technology to Eclipse!
NetBeans (supported by Sun)
EMTM 600, Spring 2011
Val Tannen
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 a “portion” of Java EE is
dubbed “lightweight” and supported by a company called Interface 21.
EMTM 600, Spring 2011
Val Tannen
Spring,
More Open Source
Sun has seeded several open source projects:

GlassFish, an open source development of a Java EE application
server

OpenJDK 6/7, open source releases of Java SE (Standard Edition) 6 and
7 around which contributing communities have formed. Sun has stated
that eventually the whole Java SDK will become open source. Current
status unclear.
Open source projects rely on open specifications of COMPONENTS
EMTM 600, Spring 2011
Val Tannen
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
EMTM 600, Spring 2011
Val Tannen
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
EMTM 600, Spring 2011
Val Tannen
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
EMTM 600, Spring 2011
Val Tannen
I asked EMTM 600 students which one they prefer!
The students liked the following definitions:
•
#4 - 5 votes
•
#8 - 4.5 votes
•
#7 - 2.5 votes
•
#6 and # 2 - 2 votes each
Which one do YOU prefer?
Email me!
The explanation for the half-votes is that one student 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”
EMTM 600, Spring 2011
Val Tannen
Favorite definitions for “Component”
Another student 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!]”.
Yet another student 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.”
Finally, one of the students 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.”
EMTM 600, Spring 2011
Val Tannen
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.
EMTM 600, Spring 2011
Val Tannen
Are Components Reusable?
The short answer is YES! But it’s a question of degree.
Cox’s 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, it’s 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 welldefined interfaces:
Component A1
Component B1
or
or
swap (different vendors)
swap (different versions)
interface
Component A2
EMTM 600, Spring 2011
Val Tannen
Component B2
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. Apache, MS IIS)
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 (i.e.
strongly standardized components) can help!
EMTM 600, Spring 2011
Val Tannen
A third kind of reusability?
Web Server
Vendor ABC
JavaEE App Server
Vendor UU
Edge Network
Dispatcher
Vendor QQ
Web Server
Vendor XYZ
JavaEE App Server
Vendor VV
Purpose: load-balancing
EMTM 600, Spring 2011
Val Tannen
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
EMTM 600, Spring 2011
Val Tannen
Java EE Architecture: three (or five!)
tiers ( or layers)
Fowler / Alur et al.
}
Presentation
Brown et al.
Val Tannen
}
EMTM 600, Spring 2011
Controller/Mediator
Domain
Business / Domain
Integration /
Data Source
Presentation
Data Mapping
Data Sources
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!)
EMTM 600, Spring 2011
Val Tannen
Five Layers, cont’d
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!
EMTM 600, Spring 2011
Val Tannen
Static and Dynamic Web Content
 static: “plain” HTML, just hypertext interaction
 dynamic, on the client side
 Applets (Java)
 Dynamic HTML
scripts (JavaScript/Jscript, VBScript)
forms
 dynamic, on the server side
 CGI (Common Gateway Interface), written in “any” language
 Servlets (Java)
 JSP (Java Server Pages, Sun)
 ASP (Active Server Pages, MS)
EMTM 600, Spring 2011
Val Tannen
Where do the layers run?
Java EE application server
Web server
presentation
controller
Eg.,
Eg.,
JSP
Servlets
browser
EMTM 600, Spring 2011
domain
Eg.,
Session
EJBs
data mapping
data source
Eg.,
Entity
EJBs
Eg.,
JDBC
DB
Val Tannen
Two design (super-)patterns: MVC and ORM
Java EE application server
Web server
presentation
controller
Eg.,
Eg.,
JSP
Servlets
MVC: Model-View-Controller
browser
EMTM 600, Spring 2011
domain
Eg.,
Session
EJBs
data mapping
data source
Eg.,
Entity
EJBs
Eg.,
JDBC
ORM: Object-Relational
Mapping
DB
Val Tannen
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)
EMTM 600, Spring 2011
Val Tannen
Design Patterns (cont’d)
• 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
EMTM 600, Spring 2011
Val Tannen
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 “Ward’s Wiki”.
• Patterns Home Page
http://hillside.net/patterns/
• Hosted by The Hillside Group
EMTM 600, Spring 2011
Val Tannen
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.
EMTM 600, Spring 2011
Val Tannen
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.
EMTM 600, Spring 2011
Val Tannen
Examples(3)
From “Design patterns” by Gamma et al.,
AddisonWesley 1995
 Structural Patterns (cont’d)
 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.
EMTM 600, Spring 2011
Val Tannen
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.
EMTM 600, Spring 2011
Val Tannen
Examples(5)
From “Design patterns” by Gamma et al.,
AddisonWesley 1995
 Behavioral Patterns (cont’d)
 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.
EMTM 600, Spring 2011
Val Tannen
Examples(6)
From “Design patterns” by Gamma et al.,
AddisonWesley 1995
 Behavioral Patterns (cont’d)
 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.
EMTM 600, Spring 2011
Val Tannen
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.
EMTM 600, Spring 2011
Val Tannen
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”).
EMTM 600, Spring 2011
Val Tannen
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.
EMTM 600, Spring 2011
Val Tannen
Mutable Lists
as an Abstract Factory
public
List
List
List
}
interface ListSpec { // Example of Abstract Factory.
nil();
// Methods that create products.
sng(Object o);
// In general, the products are of
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.
}
EMTM 600, Spring 2011
Val Tannen
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 i=ao.length-1; i>-1; i--)
rl.addHead(ao[i]);
return rl; …
EMTM 600, Spring 2011
Val Tannen
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.
}
EMTM 600, Spring 2011
Val Tannen
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();
This is unrelated, but
}
interesting! Inside
sb.append("]");
return sb.toString();
class LinkedList.
}
EMTM 600, Spring 2011
Val Tannen
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.
EMTM 600, Spring 2011
Val Tannen
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();
}
We could have also used
public void push(Object o) {
inheritance.
theList.addHead(o);
}
public void pop() throws EmptyStackException {
try { theList.removeHead();
} catch (EmptyListException e) {
throw new EmptyStackException();
…
EMTM 600, Spring 2011
Val Tannen
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
EMTM 600, Spring 2011
Val Tannen
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
EMTM 600, Spring 2011
Val Tannen
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
EMTM 600, Spring 2011
Val Tannen
Key Concepts, cont’d
• 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
• Objects&Classes: detailed functionality
EMTM 600, Spring 2011
Val Tannen
From “AntiPatterns” by Brown et al.,
Wiley 1998
Examples
 Management AntiPatterns
 Analysis Paralysis Not knowing when to stop worrying about details…
 Death by Planning Can’t 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 don’t 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...
EMTM 600, Spring 2011
Val Tannen
Example: Stovepipe Enterprise
This is a software architecture antipattern.
From “AntiPatterns” by Brown et
al., Wiley 1998
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.
EMTM 600, Spring 2011
Val Tannen
Stovepipe Enterprise, cont’d
Refactored Solution: Enterprise Architecture Planning
 Coordination of technologies at several levels
 Ruless in the spirit of “building codes”and “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)
EMTM 600, Spring 2011
Val Tannen
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!
EMTM 600, Spring 2011
Val Tannen
The Blob, cont’d
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.
EMTM 600, Spring 2011
Val Tannen
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.
EMTM 600, Spring 2011
Val Tannen