Weblog

Keep our Pattern Zoo tidy (Part 2)

Gio, 29 Set 2005 00:00:00 +0200

Today I continue with a pattern where business objects can be logically deleted and restored by using the 'restorable' pattern. Different from the 'trash bin' pattern in part 1 this pattern is based on booleans expressing the state of an object, either logically deleted or not. Both patterns are non-historical. In addition Restorable covers also a mechanism to process business class specific logic before an object is logically deleted (trashed).

Keep our Pattern Zoo tidy (Part 1)

Gio, 15 Set 2005 00:00:00 +0200

Recycling objects... trashing them and then restoring them... as often as your users want. Here comes 'trash bin', a pattern for non-historical, logical deletion based on associations. Probably this is the first UML pattern ever protecting our environment. ;-)

Logging animals arrived at the Pattern Zoo

Lun, 08 Ago 2005 00:00:00 +0200

Logging, monitoring and versioning objects in an information system can help to improve both, the usability for its users, and the quality of stored information. While gain in aspects of usability is rather obvious to most people (in particular to the users of such a system), gain in aspects of quality is less known. Despite that the described side-effect can be observed in many cases, where transparency and mechanisms of mutual control can increase the quality of information. This may result from an interesting group dynamic process inside the group of information providers and consumers. This process seems to be driven by the pursuit of acceptation an individual seeks to get from his very close and even very wide social environment.

At information systems this process can be easily observed in teams, small companies, or departments, where users can see which user created, modified or deleted which information, or vice versa. Intranets, knowledge systems, versioning systems in software-development, and many other systems already benefit from this process. There are experiences with this phenomenon also in global scale systems where users can be (more or less theoretically) any human being on our planet. The world-wide success of open-source software development like Linux in dozens of thousands of projects is, not at least, based on the pursuit of acceptation a programmer wants to receive from other programmers with good reputation. These principles have also enabled an overwhelming success of non-software community projects. Wikipedia is not the only proof of this (but maybe one of the most famous examples). Even here this process seems to work, although we can suppose that there is also some kind of philanthropic motive strongly involved, while usually in commercial environments this additional motive is missing.

I made a first pattern on this topic, which covers this issue on a very straight way. The 'Last log' pattern provides only some log information on creation, deletion and the last modification of an object (or of its assocations). I made this pattern for an inquired project to fulfill customer's requirements. After discussing this pattern with the customer (where I stressed that there is no historical logging of past modifications), demand raised for a pattern that covers also the entire history of logged modifications. This 'Historical log' pattern also enables multiple creation and deletion of objects (by a restoring mechanism which I will describe in a seperate paper later). Comments, questions and suggestions are welcome.

Note: More patterns may follow, which not only cover logging, but also versioning and monitoring of information.

Welcome to the Pattern Zoo

Mer, 03 Ago 2005 00:00:00 +0200

Some days ago a former colleague, Biene, stayed in Berlin to get an individual Slow Stroke (a massage technique) course. Today she is a fully-qualified massage-therapist - and as I've been told she is an excellent one. In former days, as I met her at Aeonic, she studied computer sciences in Munich and applied for an internship to get more practical experience in programming. We remembered the old times, which was rather funny, but felt like happened in an earlier life. I'm sure you know this situation, which starts with a spontaneous laughter and an amused 'Do you remember...?' So it did happen that also the 'Elephant' paper was mentioned, and I remembered how I came to object-orientation (OO) and patterns, especially class diagrams. And my interest into both can explain, why I like to work with analysis and design patterns in UML, and why I decided to publish some of them and to discuss them with others. I still learn and have to learn much more, but I feel light-hearted: The physician Newton said that what we already know is a drop of water, and what we don't know is an ocean.

In the late 1990ies, at the peek of the new economy, I wanted to learn more on object-orientation. Several people (really experienced people) tried to explain the concepts, but in my head there was still this picture of procedural programming, and I tried to force OO to fit into this picture. Don't laugh, I've never been a programmer. The first and last program I ever wrote many years before surely contained spaghetti-becoming code like '2540 GOTO 3720' - a program for the legendary Commodore C64 which I wrote in BASIC as I was a teenager. I'm sure, I really hope, this nice guy, boss of a sheltered workshop, uses for plenty of years uses an other software to calculate the products produced there, but at that time he was very happy about this little BASIC cost-calculator). However, I was around 25 years old and wanted to understand OO. So in early 1999 a new colleague at Aeonic, Mick Krippendorf, tried to explain me and some other non-programmers, what OO is about. He tried hard and several attempts were needed. Finally the 'Elephant' paper was born, describing classes, instances, associations, compositions, inheritance, and many other weired terms... and with all these tusks, proboscis, grey and purple elephant skin colors I got a cloudy idea of OO.

Since the 'Elephant' paper I had a lot of software and web projects where OO played an important role, at least in business logic in some cases also in the GUI. But even in the larger IT projects OO wasn't used for database models. In the most cases Entity-relationship models were used for it, which were rather convenient for me since I had a lot more experience with them and earlier versions. But I was unsatisfied because of the break between OO business logic and relational data models. Some years ago I discovered Martin Fowler's 'Analysis Patterns', a book full of interesting patterns. Although I had some problems at the beginning to understand his special notation (he didn't use UML in that edition) I was really very excited and impressed by Fowler's experience and abilities. I smelled the fresh air of a powerful approach to model and re-use good patterns in different applications, where gain of abstraction enables a gain of productivity and quality.

It didn't take a long time until Markus Hillebrand, an old school friend of mine and also former Aeonic colleague, uncovered to me his eos-project idea, an open software laboratory, where software experts could build together engineering technologies and methods. And he already had two technologies he wanted to build in this lab. One of these projects was GenEA, a collection of architecture concepts, generators, interfaces, libraries and so on, based on the rather new Model Driven Architecture (MDA) standard of the OMG (that also unified OO modeling notation by developing the UML standard which is used in many many software tools today). Markus had the goal to implement a MDA technology for enterprise and database applications, divided into CORBA components, and distributed as software services over a local or wide area network. And he asked me to accompany him at these projects because I had some experiences with project management where solutions have been build, that could also have been build with his GenEA technology. It was easy for him to convince me since I seeked new approaches and technologies in order to overcome common software engineering problems and to meet requirements before rising up in the application market and hurting people that are not prepared.

Model-driven software development (MDSD), as the name implies, is (almost) all about models. And with my commitment to these fascinating projects I saw my role to view them from the point of an application customer or someone who is a project manager and wants to build a med-sized or maybe larger application with GenEA. So, in order to unfold the real benefits of MDSD, we were in need of good examples, in meaning of good analysis and design patterns, as well as useful concepts, common code patterns and in a longer term also already implemented solutions. Thus I started in early 2004, as eos-project released the fourth alpha version of GenEA 1.0, to work with GenEA. After the first lousy patterns, I started to get more routine in modeling my own patterns (supervising the requirement engineering processes is something totally different). I also started to learn Python which is really great for anyone who needs to program here and there, who has a general understanding of programming, but isn't paid for remembering complicated syntax or semantics of a programming language. In Python I wrote little scripts for system administration or small web-applications that interact with GenEA services. I even started to learn C++ but failed, nevertheless I was able to use the service implementation in C++ of one project to copy-paste-adopt it for another project where I had replace some specific classes in the origin patterns used for the generation. By the way: if you like patterns, you will love model-driven software development. Most projects are rather young but you will already find very good MDSD tools in the Free Software community which will also allow you to produce with them again Free Software that will run on Free Software.

And for the time being regarding to the issue of Free Software I will only quote the following:

Your software shall grant you these freedoms:00 to run for any purpose01 to study and adapt to your needs02 to redistribute, so you can help others03 to release improvements, so everyone benefits

http://www.fsfe.org/

As soon as I can free myself from the claws of the bureaucratic monster I will publish some of my patterns, hoping that it may be useful for your purpose. Comments and questions welcome.