emtm 600 software development spring 2011 lecture notes 1 val/emtm600

EMTM 600Software Development

Spring 2011

Lecture Notes 1http://www.cis.upenn.edu/~val/EMTM600

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.

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


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.


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.


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.


Bibliography

Planning Extreme Programmingby 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 Interoperabilityby Peltzer. McGraw-Hill 2004Pretty lame, but the others on this topic are worse…


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.


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


Enterprise Applications, cont’dSolutions

• 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


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)


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.


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


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


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”


http://www-dse.doc.ic.ac.uk/~np2/pubs.html


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”



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”


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

http://www.sei.cmu.edu/

http://www.sabc.co.za/manual/ibm/9agloss.htm


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



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 B2Component A2

Component A1

swap (different versions)swap (different vendors)

interface

or

or


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


A third kind of reusability?

JavaEE App Server Vendor UU

Purpose: load-balancing

JavaEE App Server Vendor VV

Web Server Vendor XYZ

Web ServerVendor ABC

Edge NetworkDispatcherVendor QQ


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


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

PresentationPresentation


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!)


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!


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)


Where do the layers run?

JSP Servlets JDBC

DB

Session EJBs

presentation controller domain data mapping data source

EntityEJBs

browser

Web server Java EE application server

Eg.,Eg.,Eg., Eg.,Eg.,


Two design (super-)patterns: MVC and ORM

JSP Servlets JDBC

DB

Session EJBs

presentation controller domain data mapping data source

EntityEJBs

browser

Web server Java EE application server

Eg.,Eg.,Eg., Eg.,Eg.,

ORM: Object-RelationalMapping

MVC: Model-View--Controller


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)


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


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


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


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.



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.



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.



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.



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.



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.


Example: Adapter

This is a structural pattern. It is also called Wrapper (the Javawrapper classes are adapters for the primitive types). We can useit, for example, to implement stacks, queues and even priorityqueues (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”).


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.


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


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; …


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


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.


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.


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.


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


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


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


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


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


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.



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)


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!



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.


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.


emtm 600 software development spring 2011 lecture notes 1 val/emtm600

Documents

addison wesley

software design patterns

system of patterns

soa design patterns

software development

core j2ee patterns

patterns domain model

val tannen assignments