To start, I'll try to introduce some terms and to give some hopefully ;) helpful sort-of-definitions of often used terms in software engineering - and of sadly often overused terms...

But be careful: All I'm going to write on that topic is strongly influenced by my own point of view in architecting software systems - and be warned, I don't follow the theoretical how-to's always - sometimes there are situations you might need to use a more practical solution for a problem... and - I'm not going to give you a lesson in computer science here, I'll try to stay on the road for practical daily use...Let's start with patterns:

In software engineering theory a pattern doesn't have anything to do with real-life code in the first step. It's more of a document (however) which provides and gives an abstract solution for a often upcoming task in building an architecture or an application.

Depending on which development metaphore you're talking about (object-oriented, component-based, functional etc.), a pattern description could contain UML diagrams, abstract class descriptions, object or component definitions etc.

So - a pattern should provide a general approach to solve a problem.

The history of patterns started in the early and mid-ninties of the last century with the famous GOF (Gang of Four - E. Gamma, R. Helm, R. Johnson, and J. Vlissides) providing the book "Design Patterns: Elements of Reusable Object-Oriented Software" - I really recommend you to get a copy of it, it's 100% worth reading.

A famous example for a pattern is MVC (Model-View-Controller) - I'm going to write on that one in one of the next entries.

However, that leads over to pattern frameworks (often just "frameworks"):

A first approach is quite easy - a pattern framework should be a collection of single patterns. But - in my terms - a framework is more of just that. To call something a framework, I'd like to get some sort of methodology with the pattern stuff. That doesn't have to go so far as - for example Fusebox providing a complete software development process like FLiP.

The other important property in my terms for calling something a framework is that it behaves more applicable and more concrete as a pattern.

For example: Fusebox, Mach II, Struts etc. are web development frameworks.

So far - so good. I'm quite sure, that those "definitions" will call up some people to start a discussion - at least I hope so :-) I'm very interested in Martin Heideggers opinion - probably he'll be the first one to beat me up verbally for some too loosely used terms :-)