ppt - Computer & Information Science

quaggahooliganInternet και Εφαρμογές Web

5 Φεβ 2013 (πριν από 4 χρόνια και 8 μήνες)

134 εμφανίσεις

EMTM 600

Software Development

Spring 2011

Lecture Notes 1

http://www.cis.upenn.edu/~val/EMTM600



EMTM 600, Spring 2011 Val Tannen

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):
C
ustomer
R
elationship
M
anagement,
S
upply
C
hain
M
anagement,
S
ales
F
orce
A
utomation,
E
nterprise
R
esource
P
lanning, 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”


S
peed
-
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
Spring
,
dubbed “lightweight” and supported by a company called Interface 21.




EMTM 600, Spring 2011 Val Tannen

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

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)



More Definitions of “Component”

From the Portland Pattern Repository

EMTM 600, Spring 2011 Val Tannen

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)





Even More Definitions of “Component”

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

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.

Component Framework

From the Portland Pattern Repository

EMTM 600, Spring 2011 Val Tannen


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 well
-
defined interfaces:


Are Components Reusable?

Component B1

Component B2

Component A2

Component A1

swap (different versions)

swap (different vendors)




interface

or

or

EMTM 600, Spring 2011 Val Tannen




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!


Reusability in component frameworks

EMTM 600, Spring 2011 Val Tannen

A third kind of reusability?

JavaEE App Server


Vendor UU

Purpose: load
-
balancing

JavaEE App Server


Vendor VV

Web Server


Vendor XYZ

Web Server

Vendor ABC

Edge Network

Dispatcher

Vendor QQ










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
)

Brown et al.

Business / Domain

Integration /
Data Source

Fowler
/

Alur et al.


}

}

Controller/Mediator

Data Sources

Data Mapping

Domain

Presentation

Presentation

EMTM 600, Spring 2011 Val Tannen

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?

JSP

Servlets

JDBC

DB

Session

EJBs

presentation

controller

domain

data mapping

data source


Entity

EJBs

browser

Web server

Java EE application server

Eg.,

Eg.,

Eg.,

Eg.,

Eg.,

EMTM 600, Spring 2011 Val Tannen


Two
design

(super
-
)
patterns
: MVC and ORM

JSP

Servlets

JDBC

DB

Session

EJBs

presentation

controller

domain

data mapping

data source


Entity

EJBs

browser

Web server

Java EE application server

Eg.,

Eg.,

Eg.,

Eg.,

Eg.,

ORM: Object
-
Relational

Mapping

MVC: Model
-
View
-

-
Controller

EMTM 600, Spring 2011 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)


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.

From “Design patterns” by Gamma et al.,
AddisonWesley 1995

EMTM 600, Spring 2011 Val Tannen

Examples(2)


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.

From “Design patterns” by Gamma et al.,
AddisonWesley 1995

EMTM 600, Spring 2011 Val Tannen

Examples(3)


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.


From “Design patterns” by Gamma et al.,
AddisonWesley 1995

EMTM 600, Spring 2011 Val Tannen

Examples(4)


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.

From “Design patterns” by Gamma et al.,
AddisonWesley 1995

EMTM 600, Spring 2011 Val Tannen

Examples(5)


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.

From “Design patterns” by Gamma et al.,
AddisonWesley 1995

EMTM 600, Spring 2011 Val Tannen

Examples(6)


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.


From “Design patterns” by Gamma et al.,
AddisonWesley 1995

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 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.

}

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();


}


sb.append("]");


return sb.toString();

}

This is unrelated, but
interesting! Inside
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();


}


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.

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

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...

From “AntiPatterns” by Brown et al.,
Wiley 1998

EMTM 600, Spring 2011 Val Tannen


Example:

Stovepipe Enterprise

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.

From “AntiPatterns” by Brown et
al., Wiley 1998

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

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!

From “AntiPatterns” by Brown et
al., Wiley 1998

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

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.


From “AntiPatterns” by Brown et
al., Wiley 1998