Approach to some software engineering terms

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 🙂